Eric lives in France and he owns a company named LBKE where he works as a developer and as a RD consultant. He also maintains the framework Vulcan and he More aboutEric

Congratulations On Your New Job

If you think that static rendering is limited to generic public content that is the same for every user of your website you should definitely read this article.

personal-design

Segmented Rendering is a new pattern for the Jamstack that lets you personalize content statically without any sort of client-side rendering or per-request Server-Side Rendering. There are many use cases personalization internationalization theming multi-tenancy A/B tests

Wow you just got promoted You are now Head of Performance at Repairing Magazine the most serious competitor to Smashing Magazine. Repairing Magazine has a very peculiar business model. The witty jokes in each article are only visible to paid users.

Your job for today is to implement this feature with the best possible performances. Lets see how you can do that. Hint we are going to introduce a new pattern named Segmented Rendering.

Web Development Agency

Next.js popularity stems from its mastery of the Triforce of Rendering the ability to combine client-side rendering per-request server-rendering and static rendering in a single framework.

The Many Ways To Render A Web Page With Modern JavaScript Frameworks

Repairing Magazine user interface relies on a modern JavaScript library React. Like other similar UI libraries React provides two ways of rendering content client-side and server-side.

Client-Side Rendering CSR happens in the users browser. In the past we would have used jQuery to do CSR.

Web Design Near Me

Server-side rendering happens on your own server either at request-time SSR or at build-time static or SSG. SSR and SSG also exist outside of the JavaScript ecosystem. Think PHP or Jekyll for instance.

Client-Side Rendering CSR would use JavaScript in the browser to add witty jokes after the page is loaded. We can use fetch to get the jokes content and then insert them in the DOM.

It works but is it the best approach Your server will have to serve witty jokes for each reader. If anything makes the JavaScript code fail the paid user wont have their dose of fun and might get angry. If users have a slow network or a slow computer they will see an ugly loader while their joke is being downloaded. Remember that most visitors browse via a mobile device

Deep-Dive Into Segmented Rendering

This problem only gets worse as the number of API calls increases. Remember that a browser can only run a handful of requests in parallel usually 6 per server/proxy. Server-side rendering is not subject to this limitation and will be faster when it comes to fetching data from your own internal services.

Per-request Server-Side Rendering SSR generates the content on demand on the server. If the user is paid the server returns the full article directly as HTML. Otherwise it returns the bland article without any fun in it.

We dont rely on client-side JavaScript anymore. However its not energy-efficient to render the article for each and every request. The Time To First Byte TTFB is also increased because we have to wait for the server to finish its work before we start seeing some content.

Weve replaced the ugly client-side loader with an even uglier blank screen And now we even pay for it

The stale-while-revalidate cache control strategy can reduce the TTFB issue by serving a cached version of the page until its updated. But it wont work out-of-the-box for personalized content as it can cache only one version of the page per URL without taking cookies into account and cannot handle the security checks needed for serving paid content.

Whats Next Even More Performance

At this point you are hitting what I call the rich guest/poor customer problem your premium users get the worst performance instead of getting the best.

By design client-side rendering and per-request server-side rendering involve the most computations compared to static rendering which happens only once at build time.

99 of the websites I know will pick either CSR or SSR and suffer from the rich guest/poor customer problem.

Meet Smashing Email Newsletter with useful tips on front-end design UX. Subscribe and get Smart Interface Design Checklists a free PDF deck with 150 questions to ask yourself when designing and building almost anything.

Segmented Rendering is just a smarter way to do static rendering. Once you understand that its all about caching renders and then getting the right cached render for each request everything will click into place.

Static Site Generation SSG generates the content at build-time. Thats the most performant approach because we render the article once for all. It is then served as pure HTML.

This explains why pre-rendering at build-time is one of the cornerstones of the Jamstack philosophy. As a newly promoted Head of Performance thats definitely what you want

Result of the first step of static rendering computing a bunch of URLs that you will prerender. For a blog its usually a list of all your articles. In step 2 you simply render each article one per URL.

This means that one URL strictly equals one version of the page. You cannot have a paid and a free version of the article on the same URL even for different users. The URL /how-to-repair-a-smashed-magazine will deliver the same HTML content to everyone without any personalization option. Its not possible to take request cookies into account.

Segmented Rendering can go a step further and render different variations for the same URL. Lets learn how.

The most naive solution to allow personalized content is to add a new route parameter to the URL for instance with-jokes versus bland.

The first function computes 2 URLs for the same article a fun one and a bland one. The second function gets the joke but only for the paid version.

Great you have 2 versions of your articles. We can start seeing the Segments in Segmented Rendering paid users versus free users with one rendered version for each segment.

But now you have a new problem how to redirect users to the right page Easy redirect users to the right page literally With a server and all

It may sound weird at first that you need a web server to achieve efficient static rendering. But trust me on this the only way to achieve the best performances for a static website is by doing some server optimization.

If you come from the Jamstack ecosystem you may be in love with static hosting. Whats a better feeling than pushing a few files and getting your website up and running on GitHub Pages Or hosting a full-fledged application directly on a Content Delivery Network CDN

Yet static hosting doesnt mean that there is no server. It means that you cannot control the server. There is still a server in charge of pointing each URL to the right static file.

Static hosting should be seen as a limited but cheap and performant option to host a personal website or a company landing page. If you want to go beyond that you will need to take control over the server at least to handle things such as redirection based on the request cookies or headers.

No need to call a backend expert though. We dont need any kind of fancy computation. A very basic redirection server that can check if the user is paid will do.

Great news modern hosts such as Vercel or Netlify implements Edge Handlers which are exactly what we need here. Next.js implements those Edge Handlers as middlewares so you can code them in JavaScript.

The Edge means that the computations happen as close as possible to the end-user as opposed to having a few big centralized servers. You can see them as the outer walls of your core infrastructure. They are great for personalization which is often related to the actual geographical location of the user.

Next.js middlewares are dead fast and dead simple to code. Contrary to cloud proxies such as AWS Gateway or open source tools such as Nginx middlewares are written in JavaScript using Web standards namely the fetch API.

In the Segmented Rendering architecture middlewares are simply in charge of pointing each user request to the right version of the page

Well thats it. Your first day as a Head of Performance is over. You have everything you need to achieve the best possible performances for your weird business model

Of course you can apply this pattern to many other use cases internationalized content A/B tests light/dark mode personalization Each variation of your page makes up a new Segment French users people who prefer the dark theme or paid users.

But hey you are the Head of Performance not the Average of Performance You want your web app to be perfect not just good Your website is certainly very fast on all metrics but now your article URLs look like this

Thats not really good-looking Segmented Rendering is great but the end-user doesnt have to be aware of its own segments. The punishment for good work is more work so lets add a final touch instead of using URL redirects use URL rewrites. They are exactly the same thing except that you wont see parameters in the URL.

The URL /how-to-make-an-url-shorter without any route parameter will now display the right version of the page depending on the users cookies. The route parameter still exists in your app but the end-user cannot see it and the URL stays clean. Perfect.

Now you can have as many variations of the same page as you want. You solved your issue with paid users elegantly. Better you implemented a new pattern Segmented Rendering that brings personalization to the Jamstack without sacrificing performances.

Final question what happens if you have a lot of possible combinations Like 5 parameters with 10 values each You cannot render an infinite number of pages at build-time that would take too long. And maybe you dont actually have any paid users in France that picked the light theme and belong to bucket B for A/B testing. Some variations are not even worth rendering.

Hopefully modern frontend frameworks got you covered. You can use an intermediate pattern such as Incremental Static Regeneration from Next or Deferred Static Generation from Gatsby to render variations only on demand.

Website personalization is a hot topic sadly adversarial to performance and energy consumption. Segmented Rendering resolves this conflict elegantly and lets you statically render any content be it public or personalized for each user segment.