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.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

 module (jquery-migrate.min.js) is a javascript library that allows you to preserve the compatibility of your jQuery code developed for versions of jQuery older than 1.9. 

 also allows developers to detect deprecated code that is no longer supported by the latest jQuery libraries and to adapt it according to the newest versions of jQuery 1.9 and higher.

 file has a size of 11 K that requires a download and an additional DNS request from the client side. If your jQuery code and plugins are compatible with the latest versions of the jQuery library, you do not need to use this module and it is best to disable it to avoid downloading it from the client side unnecessarily And thus improve the SEO performance of your web pages.

Here is the PHP code that allows you to disable 

 in WordPress. Simply copy and paste this PHP code into the 

 file of your WordPress theme and you're done.

 action hook, the step where jQuery Migrate is loaded among other javascript codes.

: Using an anonymous function rather than a named function, saves memory in the Global Namespace, which is already heavily loaded by WordPress and third-party plugins. WordPress itself loads thousands of functions and PHP variables for processing each single Web request. And since this function needs to be executed only once during the client's request processing, why keep it in memory?

 instruction to remove from memory our dynamically created anonymous function. By saving our anonymous function in a global variable $af, allows us to delete it at a later step since anonymous functions are not eliminated immediately after their usage by the PHP Garbage Collection system.

You may not need to use the jQuery Migrate module and it is best to disable it to avoid unnecessarily downloading it from the client side and thus improve the SEO performance of your web pages

Disable jQuery Migrate in WordPress

What is jQuery Migrate?

Why disable jQuery Migrate?

PHP code to disable jQuery Migrate

PHP Code Features

Comments:

Share:

More Stories

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

Next.js: The Ultimate Cheat Sheet To Page Rendering