Next.js uses 4 rendering strategies to build, deliver and render a React Single Page App (SPA):

This is the easiest and most complete cheat sheet to quickly understand how Next.js page rendering strategies works. Moreover, this unique cheat sheet clearly reveals how each strategy influences the Core Web Vitals signals: TTFB, FP, FCP, LCP, TBT and TTI.

Detailed explanations are also included to help you choose the right page rendering strategy for all use cases and thus create speedy Web applications that Google and visitors love.

P.S.: Thanks in advance for including this cheat sheet in your blog articles and mentioning the author with a link back to this cheat sheet like this: 

The Ultimate Cheat Sheet to Page Rendering in Next.js

The 4 page rendering strategies are identified with their respective acronym (SSG, SSR, ISR and CSR) and laid out in columns besides each other in the middle of the infographic.

Completely on the left side of these 4 columns you’ll find the 6 steps involved during the processing flow from the build step on the server side up to the client-side rendering.

Completely on the right side of these 4 columns you’ll find where each step happens in the processing flow which is either server side or client side.

For each strategy column you’ll see where and when a build action (page generation) is executed in the step. You’ll also see the generated content flow (HTML - React/CSS/JS/Data) during each single step.

new page experience ranking factor from Google

, are identified using 3 distinctive background colors, each related to the performance impact on the CWV.

A red color means POOR performance results, an orange color means GOOD performance while a green color means the BEST performance.

You’ll find a live demo with example source code on Github for testing the performance of each page rendering strategies discussed in the cheat sheet:

Static-Site Generation (SSG) is the default strategy offered by Next.js to generate web pages. Next.js recommends this strategy to get the best performance results as static content is distributed faster using CDNs which are closer to your visitors and thus leading to a faster 

: Next.js generates a Single Page App in an .html file along with the .css and .js on the server. This step called pre-rendering is done only once at build time when you run the next build command. That is usually done when you deploy your application. This is during this step that all the page coding (HTML) is generated including the React code, CSS, JavaScript and optionally the data if the page is using any data fetching method such as 

: The client requests the Single Page App from the CDN.

: The client downloads the Single Page App from the CDN.

: The client parses and renders the Single Page App into the browser. This is where the 3 Core Web Vitals signals (First Paint, First Contentful Paint and Largest Contentful Paint) are fired. Because the HTML of the page has been pre-rendered on the server side, the client browser just has to load and render it as is. And because the page is coded in a way that allows the browser to render it with minimum JavaScript code, render-blocking is reduced to its minimum leading to good performance results.

: The React (JavaScript) code is run to (re)Hydrate the page. Even though the page has been pre-built, this extra step is required to allow React to attach or activate the JavaScript events to its Virtual DOM and make the page interactive. Because JavaScript is run at this point, Total Blocking Time is affected by this extra step. Also, because the browser has to wait for the hydration process to complete, Time To Interactive is also affected.

Here is the complete Typescript code of a web page that uses Next.js' Static-Site Generation strategy (SSG):

Server Side Rendering (SSR) is the second strategy offered by Next.js to generate web pages. Next.js recommends to avoid using this strategy as much as possible to get the best performance results as the static content is built (pre-rendered) and distributed per-request only. Because of the extra time required by the build process, the 

 signal is increased and leads to poor results.

: Next.js does not generate (pre-render) any page.

: The client requests the Single Page App from the server. Next.js generates (pre-render) a Single Page App in an .html file along with the .css and .js on the server. This is during this step that all the page coding (HTML) is generated including the React code, CSS, JavaScript and optionally the data if the page is using the 

: The client downloads the Single Page App from the server.

Here is the complete Typescript code of a web page that uses Next.js' Server Side Rendering strategy (SSR):

Incremental Static Regeneration (ISR) is the third strategy offered by Next.js to generate web pages. It is the same as Static Site Generation except that content can be rebuilt when the page is updated.

: The client requests the Single Page App from the CDN. Also, if the page is using the data fetching method getStaticProps() combined with the revalidate option, then the page is regenerated if the data returned from the fetching results has been updated. Next.js recommends using this method for a huge site having over 1,000 pages. Because pre-rendering each page takes time, using this incremental method will pre-render on the first request and when the page content is updated only.

Here is the complete Typescript code of a web page that uses Next.js' Incremental Static Regeneration strategy (ISR):


Client Side Rendering (CSR) is the fourth strategy offered by Next.js to generate web pages. It is the same as Static Site Generation except that parts of the content can be built on the client side.

: Same as STEP 1 in SSG except that the content (data) is not pre-rendered nor included in the static bunch. Which results in a smaller file size thus leading to shorter download time.

: Same as STEP 2 in SSG but without content (data).

: Same as STEP 3 in SSG but without content (data).

: Same as STEP 5 in SSG but without content (data).

: The client fetches the content (data) and React updates the UI. This method is useful, for example, when you want to show up a skeleton page with static content and then progressively inject the data in a page requiring a long wait time for data fetching.

Here is the complete Typescript code of a web page that uses Next.js' Client Side Rendering strategy (CSR):


Next.js offers 4 rendering strategies to generate, deliver and render a React Single Page App on the client side: SSG, SSR, ISR and CSR.

Next.js: The Ultimate Cheat Sheet To Page Rendering

 which is slated to launch in May 2021, will be the next strong ranking signal that will influence how your search results rank.

Google's next major algorithm update relies primarily on three clusters of signals from a visitor's experience when viewing a webpage on your website. But even though this new ranking signal, called Page Experience, will be seen as a strong signal, it will not replace the hundreds of other ranking signals like user intent and content relevance as Google is still looking to rank pages with the best information overall. In other words, even the best page experience won't replace having great page content.

However, in cases where many pages can have similar relevance, the page experience can be much more important to search rankings. So, from now on, it's best to start incorporating Core Web Vitals into your SEO strategy to maintain your competitive edge in search results.

After reading this article, you will have a better understanding of what a page experience is and how to improve it on your website to get ready for Google's next major algorithm update.

According to Google, the page experience is a set of signals that measure how users perceive the experience of interacting with a web page beyond its purely informative value. In other words, it is all about how a user perceives the speed of a web page. To do this, Google uses three groups of signals which help evaluate the user’s experience:

As shown in the infographic below, that you can download for future reference by simply clicking on the image, you can see that Core Web Vitals stands on top, being the latest, of many other updates and signals.

Let’s first quickly look at each of the Core Web Vitals scores that compose the Page Experience signal before using the tools which helps figure out and pinpoint problems about these signals.

To gauge how quickly a page loads, Google uses a metric called

. In short, LCP indicates the time it takes for the largest element of a web page to appear in the visible part (viewport) of the browser. This is the best way until now to evaluate the user’s perception of the page loading speed. 

To be considered good by Google, a web page's LCP score must be less than 2.5 seconds.

 An LCP score between 2.5 and 4 seconds is considered adequate, but needs further improvement. Any LCP score beyond 4 seconds is considered poor for user experience and should be fixed as soon as possible.

To improve LCP you need to look among four main factors that affect it:

Here is a screenshot from a Lighthouse report about one of my website pages, where you can clearly see where the LCP has occurred over time:

The second user-centric metric used by Google to judge the page experience is the

. Briefly, FID tells Google how much time it takes for a web page to get ready for responding to user’s interaction such as scrolling, clicking and typing.

A good web page’s FID must be under 100ms according to Google.

 An FID score between 100 and 300 milliseconds is still ok but needs improvement whenever possible. Any FID score beyond 300 milliseconds is considered poor for user experience and should be fixed accordingly.

There are many factors that can influence the FID. Here are some of them that can help improve the FID of a web page:

Break-up large Javascript files into smaller using Code-Splitting

Use Progressive Web Application (PWA) with caching strategy

Here's another screenshot coming from the same Lighthouse report, where you can see the Parse HTML operation taking nearly 60ms. Web.dev recommend to keep these long running tasks below 50ms whenever possible:

The last metric of the Page Experience signal is called the 

. It is used to evaluate the stability of the visual elements in a web page. What we mean by stability is about the way components appear in the browser's viewport while loading the page without moving around.

For example, a clickable button appears on top of the page but a few seconds later moves down under an image which has just been downloaded. This is bad, very bad at the experience user level. For a good user experience, it is better to avoid as much as possible any parts of your web page moving around, at least at the initial load stage in the viewport.

 about a bad UI design which affects the CLS. 

Web.dev is the official website from the Google Chrome Developer Relations team

A good CLS score must be under 0.1 according to Google’s recommendations

. A CLS score between 0.1 and .25 is still acceptable but should be improved whenever possible. Again, any CLS score beyond 0.25 is considered poor for user experience and should be fixed.

There are a lot of factors that can influence the CLS of a web page and often it is coming from missing width and height image attributes. Here are some important places where you should investigate to help improve the CLS of a web page:

Include image width and height attributes to all your images.

Include video width and height attributes to all your videos.

Resize slots with CSS using min-width and min-height.

Now that you have a better understanding about Page Experience, let's 

the online tools I regularly use to analyze web pages performance that will help you figure out potential page speed problems.

Lighthouse is my best tool to help pinpoint poor page performance culprits. To evaluate a page performance, go at 

 button. After a few seconds you should get a summary report similar to this one:

As you can see, the page is getting pretty good scores but we see that some improvements are still needed at the FID level (Time to interactive and Total Blocking Time). Usually, FID performance problems are coming from Javascript, so let's look in more details the report.

 link and scroll down the report page to get more details about what and where the performance weaknesses are:

As shown above, the Hydration process is taking a bit too much time and also I have 11 requests coming from Third-party libraries. This is where I should investigate to improve the page performance. But I'll leave it for now since I'm getting an overall score over 90% which is good enough for now.

Another one of my best tools to help identify performance problems in a page is 

 from Catchpoint. I particularly like the Filmstrip view where you clearly see the viewport elements getting laid out over time with a complete list of downloaded files. Pretty useful to detect LCP and CLS bugs.

One tool that I’m using since almost the beginning of its availability is 

 which offer a clear and easy to understand report about the Core Web Vitals scores of your pages:

My guess is that many web pages that appear in search results will be affected by the new page experience update, while others will not. How big of a penalty will it be? No one knows precisely, but personally, I think that those with quality content will be less affected, while those with poor user interface coding will be penalized.



Overall, what's important to keep in mind is that the new "Page Experience" signal is just one signal among many others. Existing search signals including 

 are still very strong signals. Thus, a poor Page Experience score will not systematically penalize content that gives the user exactly what they want in the first place, as relevance and intent remain very strong signals.

That said, only time will tell, but it's best to prepare now and the only way to minimize negative impacts is to test the performance of your web pages using the right tools that will help you assess and pinpoint problems at the source and then fix them.

In hope this article has been helpful, feel free to leave me your feedback or any question about improving your web vitals scores in the comment box below.

Google's Page Experience Update, also known as the Core Web Vitals Update which is slated to launch in May 2021, will be the next strong ranking signal that will influence how your search results rank.

Ready for the Google Page Experience Update?

Based on the most comprehensive study to date from Google, 95% of real-world Content Security Policy (CSP) deployments are bypassed and 99.34% of hosts with CSP use policies that offer no benefit against XSS.

This is why Google suggests that the model of designating trust by specifying URL whitelists from which scripts can execute should be replaced with an approach based on nonces and hashes, already defined by the CSP specification and available in major browser implementations. Hence the name strict CSP.

In the context of a Single Page App (SPA) such as the Next.js React framework, we need to use a Hash-based CSP in order to properly integrate a strict CSP which will offer real protection against CSS attacks.

Depending on the complexity of your application, the integration of a hash-based Content Security Policy could be trivial and require a lot of code manipulation. That’s why I’ve come to build a package on NPM specifically designed for Next.js to allow developers to integrate strict CSP in a snap with just a few lines of code.

 is a hash-based Strict Content Security Policy generator for Next.js that is easily integrated in the 

 file of your Next.js application. Once in production, it will automatically inject the hashes into the content security policy meta tag and protect against XSS once deployed and cached on CDN.

Here is an example of _document.tsx with basic integration of next-strict-csp:


Once put live in production, you'll get a content security policy meta tag that looks like this:


With a strict CSP, you need to hash your inline scripts as well. This could be easily achieved with next-strict-csp by integrating your inline scripts in an array like this in _document.tsx:


Once live, your inline scripts hashes will be injected into the content security policy meta tag like this:

Hope you enjoyed next-strict-csp and don't hesitate to leave a comment to let me know what you think about it. 

Thanks for reading, see you!


How to deploy a strict Content Security Policy (CSP) with Next.js

next-strict-csp

Last word

Comments:

Share:

More Stories

Next.js: The Ultimate Cheat Sheet To Page Rendering

Ready for the Google Page Experience Update?