[Performance]

8 Jan 2026

-

8 min read time

Pre-Rendering TanStack Start for Blazing-Fast Performance

Unlock blazing-fast performance for your web applications! This article unveils the secrets to using pre-rendering techniques with TanStack Start, transforming your site into an SEO-friendly, user-engaging powerhouse. Discover how to leverage static pre-rendering, selective server-side rendering, and static server functions to achieve unparalleled speed and efficiency.

Mateusz Koncikowski

By Mateusz Koncikowski

Pre-Rendering TanStack Start for Blazing-Fast Performance

Preface

In the world of web development, speed is not just a feature; it's a foundation for a great user experience and strong search engine visibility. Slow-loading websites deter users and perform poorly in search rankings. TanStack Start is a modern meta-framework built for performance, and one of its most powerful tools is pre-rendering. By reading this article, you will learn exactly how to use different pre-rendering techniques in TanStack Start to build applications that are incredibly fast, SEO-friendly, and engaging for your users.

What is Pre-Rendering and Why Does it Matter in TanStack Start?

At its core, pre-rendering is the process of generating a web page's HTML on a server before it's requested by a user's browser. Instead of sending a nearly empty HTML file that relies on JavaScript to build the content on the client's device, the server sends a fully formed, content-rich document. This approach has several substantial benefits.

First, it dramatically improves initial load times. The browser can start rendering the page immediately without waiting for JavaScript bundles to download, parse, and execute. This leads to a much better user experience, as visitors see content almost instantly. Second, pre-rendering is a major advantage for Search Engine Optimization (SEO). Search engine crawlers can easily read and index the content from the pre-rendered HTML, which can be a challenge with client-side rendered applications. TanStack Start is designed from the ground up to leverage these performance benefits, giving you fine-grained control over how and when your pages are rendered.

Diving Deep: Static Prerendering (SSG) in TanStack Start

Static Site Generation (SSG), or static prerendering, is the technique of generating all your site's pages as static HTML files at build time. This method is ideal for content that doesn't change frequently, such as blogs, marketing pages, or documentation. TanStack Start makes enabling this straightforward through its Vite plugin.

You can activate static prerendering by adding the prerender option to your vite.config.ts file. The framework will then crawl your application, starting from the root, and build an HTML file for every discovered link. You can customize this process with options like crawling to enable or disable link discovery and concurrency to control how many pages are built in parallel. For example, "setting prerender: { concurrency: 10 } allows Vite to prerender up to 10 pages in parallel, significantly speeding up the build process."

Here is what a basic configuration looks like:

// vite.config.ts
import { defineConfig } from '@tanstack/start/config'

export default defineConfig({
  plugins: [
    // ... other plugins
    {
      name: 'tanstack-start',
      config: () => ({
        prerender: {
          enabled: true,
          crawling: true, // Automatically find and prerender all links
          concurrency: 5, // Render up to 5 pages at a time
        },
      }),
    },
  ],
})

Once built, these static files can be hosted on any static hosting provider or Content Delivery Network (CDN). To maximize performance, you should configure your CDN to cache these assets aggressively at edge locations close to your users. Cache invalidation can be managed by ensuring your build process generates unique file names for assets (a common practice) or by programmatically purging the CDN cache after each new deployment.

Selective Server-Side Rendering (SSR) for Dynamic Content

While SSG is perfect for static content, many applications have pages that are dynamic or personalized. This is where Selective Server-Side Rendering (SSR) becomes useful. Selective SSR is a feature that allows you to choose a specific rendering strategy for each route . You might want one page to be fully pre-rendered at build time (SSG), another to be rendered on the server for every request (SSR), and a third to be rendered only on the client (CSR).

This flexibility is essential for complex applications. For instance, you would use a client-side only rendering strategy for a dashboard that heavily uses browser-specific APIs. For a page displaying real-time data, like stock prices, rendering on the server with each request ensures the user always gets the most current information. You configure this on a per-route basis using the ssr property in your route file.

For example, here is how you might configure a specific route to always render on the server:

// routes/dashboard.tsx
import { createFileRoute } from '@tanstack/react-router'

export const Route = createFileRoute('/dashboard')({
  // This route will always be server-rendered on each request
  // and will not be pre-rendered at build time.
  ssr: true, 
  component: DashboardComponent,
})

// To force client-side rendering (CSR), you would set `ssr: false`.
// If `ssr` is omitted and global prerendering is on, the route will be 
// pre-rendered as a static page (SSG).

To update content on a pre-rendered page after the initial load, you can use TanStack Router's data-fetching capabilities. The initial view comes from the static HTML, and once the page hydrates (JavaScript takes over), the router can fetch new data and seamlessly update the UI, providing a dynamic experience on top of a static foundation.

"Selective SSR allows you to fine-tune your rendering strategy, balancing the benefits of server-side rendering with the flexibility needed for dynamic content." - LogRocket Blog

Leveraging Static Server Functions for Build-Time Data

Static Server Functions are another powerful performance tool in TanStack Start. These are special functions that run exclusively at build time , with their results being cached and embedded directly into the client-side code. This is extremely efficient for data that is needed across the application but doesn't change with every user request.

A great use case for this is fetching global data from a headless CMS. For example, "imagine a blog with a global author list. Using a Static Server Function, you can fetch this list at build time and make it instantly available on every pre-rendered page." This prevents redundant API calls from the client and ensures the data is available immediately on page load. When handling pre-rendering for pages that require authentication, you can adopt a hybrid approach. Pre-render the public "shell" of the page using static data, and then, after the user logs in, fetch and render their private, user-specific data on the client side.

Here's how you might define one:

// src/authors.ts
import { createServerFn } from '@tanstack/start'

export const fetchAuthors = createServerFn('GET', async () => {
  // This code only runs on the server at build-time
  const response = await fetch('https://my-cms.com/api/authors');
  return response.json();
});

To use this function, you call it within your component. During the build process, TanStack Start executes fetchAuthors, and its JSON result is embedded into the page's data.

// A component that displays the author list
import { fetchAuthors } from '../authors.ts'

function AuthorListComponent() {
  const authors = fetchAuthors.use();
  
  if (authors.isPending) return <div>Loading authors...</div>;
  if (authors.error) return <div>Error fetching authors!</div>;

  return (
    <ul>
      {authors.data.map(author => (
        <li key={author.id}>{author.name}</li>
      ))}
    </ul>
  );
}

By pre-calculating and embedding data directly into the client-side code, Static Server Functions contribute significantly to faster page load times and improved Core Web Vitals, which we will explore next.

Pre-rendering's Impact on Core Web Vitals

Implementing pre-rendering with TanStack Start has a direct and positive impact on your site's Core Web Vitals, the metrics Google uses to measure user experience.

  • Largest Contentful Paint (LCP): Because the server sends fully rendered HTML, the browser can paint the largest and most meaningful content block on the screen much faster. This directly lowers your LCP time.

  • First Input Delay (FID): Pre-rendering reduces the amount of JavaScript the browser has to process to display the initial view. This means the main thread is blocked for less time, allowing it to respond more quickly to the user's first interaction, improving your FID score.

  • Cumulative Layout Shift (CLS): With pre-rendered HTML, the page's structure and layout are defined from the start. This prevents content from jumping around as resources load, which is a common cause of high CLS scores.

Improving these metrics is not just for search rankings; it directly affects user behavior. Faster, more stable pages lead to higher engagement and better conversion rates. According to research, a mere "1-second delay in page load time can result in a 7% reduction in conversions ."

Accessibility Considerations When Pre-rendering

Pre-rendering can significantly improve web accessibility when done correctly. By sending complete and structured HTML from the server, you ensure that assistive technologies like screen readers have meaningful content to parse right away, without waiting for client-side JavaScript to execute.

To maximize this benefit, it's crucial that your pre-rendered output uses semantic HTML. Using tags like <main>, <nav>, <header>, and <article> provides essential context for screen readers. Any accessibility-related attributes, such as ARIA roles and properties, must also be included in the server-rendered markup. For instance, if you're using TanStack Start's Link component for navigation, ensure that it renders accessible link elements with appropriate aria-current attributes to indicate the active page to screen readers. This focus on a solid HTML foundation makes pre-rendered sites inherently more accessible than many client-rendered alternatives.

Beyond the Basics: Edge Computing and A/B Testing

You can push the performance of your pre-rendered TanStack Start application even further with advanced techniques like edge computing and A/B testing.

Edge computing involves deploying your static assets and serverless functions to a global network of servers. When a user requests your site, the content is served from the location physically closest to them. Serving pre-rendered static files from the edge significantly reduces latency, resulting in much faster load times for users, especially those geographically distant from the origin server. With platforms like Vercel or Netlify, you can deploy TanStack Start applications alongside edge functions that can modify the response. For example, an edge function could rewrite a request to serve a language-specific version of a pre-rendered page based on the user's Accept-Language header.

Furthermore, TanStack Start's flexible rendering allows you to A/B test different strategies. Using edge middleware, you can inspect a user's cookie or header and serve different versions of a page. For instance, you could serve a fully static, pre-rendered marketing page to one group of users while serving a server-rendered version with personalized content to another. By analyzing engagement and conversion metrics for each group, you can make data-driven decisions to optimize your rendering approach for maximum impact.

The Lightning-Fast Future with TanStack Start

Pre-rendering is a foundational strategy for building high-performance web applications, and TanStack Start provides a comprehensive and flexible toolkit to implement it effectively. By mastering static prerendering (SSG), Selective SSR, and Static Server Functions, you can create websites that load instantly, rank higher in search results, and offer a superior user experience. The key is to analyze the needs of each page and apply the right strategy. Now is the time to experiment with these configurations in your projects and unlock a new level of performance.

Mateusz Koncikowski

By Mateusz Koncikowski

More from our Blog

Keep reading