I’ve been using SvelteKit for a variety of projects and working on building a Vite plugin—domco (inspired by SvelteKit) to learn more about Vite. I’ve found it challenging to keep all of the different rendering strategies straight, here’s a few things I’ve learned about different methods and use cases for each.
Web applications execute code at different points of the development lifecycle. Grasping when each step happens, and optimizing these processes, ensures your code meets each user’s needs effectively. This article provides an overview of how these stages occur and how to maximize their advantages for a seamless user experience.
Also known as “pre-rendering” in some frameworks. In SvelteKit, you can set a page to be rendered at build time in a
build script found in
./package.json, which could be anything—for example in SvelteKit this is
This can take place locally on your machine, or services like Vercel can perform this step on one of their servers when certain events take place—like whenever you commit to a repository.
Using the example above, the
load function in a file with
prerender set to
true will only run once at build time, instead of on each request.
The build step runs once, this brings advantages in comparison to rendering on the server or the client, you can perform tasks once at build time, instead of during each request.
Consider a scenario where you consistently fetch content from a CMS to display on your page. You can make a singular fetch request at build-time rather than making individual requests for every client or server request.
Rendering frequently updated data or providing user-specific content at build-time can be somewhat impractical or impossible due to the frequency of changes.
After the build stage, server-side rendering (SSR) occurs with each server request and precedes the response. This is the default behavior for SvelteKit.
With SSR, each request by the user triggers a server-side render of the content, ensuring updated information displays for each request.
Rendering Time and HTML Size
Rendering on the server for each request can potentially increase response times. Various strategies like caching network requests can be leveraged to mitigate this, however, the HTML typically still needs to be rendered for every request.
With modern frameworks like React or Svelte, the time it takes to render HTML is usually negligible, but it’s important to recognize the potential for server-side rendering to be slower in certain situations. For example, consider a script that generates 10,000 HTML elements. The script is small, but the produced code is over 10,000 lines of HTML. In this case, the user has to wait for both the rendering process on the server and then the larger payload to be transferred over the network.
In comparison, performing the script at build time does away with the rendering duration, and executing the script on the client side reduces the amount of data that is transported across the network.
The Cost of Hydration
Client-side rendering happens after receiving an HTML request. Check out this visual from Wes Bos showing how different script tags can be executed at different times.
SvelteKit components are also rendered on the client by default,
onMount can be used to encapsulate code that runs exclusively on the client.
Search Engine Optimization
Incremental Static Regeneration
Another option offered by hosting providers such as Vercel and Netlify is incremental static regeneration (ISR). ISR combines the some of the advantages of build-time and server-side rendering. ISR is similar to server-side rendering, but instead of running the rendering function on each request it is run once in a configured time frame. The result of the function is then cached as static content to be served to the user.
ISR provides a way to have dynamic content served as static assets. Instead of having to rebuild your entire application whenever your data changes, ISR allows you to just run the rendering function again instead. This creates a fast experience for users and a nice developer experience as well.
Understanding when and where to render HTML is important for efficient content delivery and providing a good user experience. Drawing on the strengths of different rendering methods can impact your application’s performance and usability. Ensuring your user’s needs align with your chosen rendering strategy is an important step towards building robust and high-performing web applications.