Supprimer le CSS bloquant le rendu dans Next.js pour de meilleurs Core Web Vitals
Supprimer le CSS bloquant le rendu dans Next.js pour des Core Web Vitals plus rapides
Supprimer le CSS bloquant le rendu dans Next.js
Le CSS bloque le rendu. Le navigateur ne peindra pas un seul pixel tant qu'il n'aura pas téléchargé et analysé chaque feuille de style dans le <head>. Dans une application Next.js, cela signifie deux fichiers CSS externes par défaut : une feuille de style globale et une feuille de style spécifique à la page. Sur une connexion 3G rapide, le téléchargement de ces deux fichiers vous coûte 600 ms avant même que le navigateur ne commence le rendu. Ce sont 600 ms ajoutées directement à votre First Contentful Paint et Largest Contentful Paint.
Dernière révision par Arjen Karel en mars 2026
Table of Contents!
- Supprimer le CSS bloquant le rendu dans Next.js
- App Router vs Pages Router
- Option 1 : Générer le CSS critique (Pages Router)
- Option 2 : Intégrer tout le CSS en ligne dans le head (Pages Router)
- Option 3 : Styled Components (Pages Router)
- Option 4 : Intégrer le CSS en ligne avec inlineCss (App Router, Next.js 15+)
- Une note sur les modules CSS et Tailwind CSS
- Quelle option dois-je utiliser ?
En moyenne, sur tous mes clients et tous les appareils, je mesure environ 200 ms de délai causé par le CSS bloquant le rendu. Selon le Web Almanac 2025, 85 % des pages mobiles échouent toujours à l'audit des ressources bloquant le rendu. La page médiane charge 8 fichiers CSS totalisant 79 Ko. Sur des connexions mobiles lentes, le délai de rendu peut représenter 69 % du temps total du LCP. Il est temps de régler ce problème.
App Router vs Pages Router
La solution dépend du routeur Next.js que vous utilisez. Le Pages Router (utilisant _document.tsx) et l'App Router (utilisant app/layout.tsx) gèrent la livraison du CSS différemment. L'intégration (inlining) du CSS critique via critters ne fonctionne pas avec l'App Router car le streaming est incompatible avec la façon dont critters traite le HTML. Si vous utilisez l'App Router, passez à l'Option 4.
L'App Router est la valeur par défaut depuis Next.js 13.4. Mais de nombreuses applications en production exécutent toujours le Pages Router, et les trois premières options ci-dessous restent valables pour celles-ci.
Option 1 : Générer le CSS critique (Pages Router)
L'option la plus rapide est de générer du CSS critique. Le CSS critique est un ensemble de règles CSS nécessaires pour rendre la partie visible de la page. Ces règles sont placées en ligne (inline) dans le <head>. Ensuite, en parallèle, les fichiers CSS originaux sont téléchargés pendant que le navigateur continue le rendu. Une fois les fichiers CSS originaux téléchargés, ils sont injectés dans la page.
Le CSS critique est disponible dans Next.js en tant que fonctionnalité expérimentale. Ajoutez experimental: { optimizeCss: true } à votre next.config.js. Next.js intègre la bibliothèque critters en interne, vous n'avez donc pas besoin de l'installer séparément. Notez que le paquet critters original est obsolète (remplacé par le fork beasties), mais Next.js n'a pas encore fait la transition.
const nextConfig = {
reactStrictMode: true,
experimental: { optimizeCss: true }
}
Cette option fonctionne uniquement avec le Pages Router. Elle ne prend pas en charge l'App Router car critters a besoin du HTML rendu complet, ce qui est incompatible avec le streaming.
Option 2 : Intégrer tout le CSS en ligne dans le head (Pages Router)
Si vous ne souhaitez pas activer de fonctionnalités expérimentales dans votre application Next.js, vous pouvez envisager d'intégrer manuellement votre CSS en ligne. Créez une section head personnalisée et référencez-la dans votre _document.tsx.
L'inconvénient est que le CSS en ligne sera plus volumineux qu'avec la première méthode car vous intégrez tout, pas seulement les règles critiques. Cependant, si vous gardez vos feuilles de style propres et légères, cela améliorera considérablement les Core Web Vitals de votre application Next.js.
import { Html, Head, Main, NextScript } from "next/document";
import { readFileSync } from "fs";
import { join } from "path";
class InlineStylesHead extends Head {
getCssLinks: Head["getCssLinks"] = ({ allFiles }) => {
const { assetPrefix } = this.context;
if (!allFiles || allFiles.length === 0) return null;
return allFiles
.filter((file: any) => /\.css$/.test(file))
.map((file: any) => (
<style
key={file}
nonce={this.props.nonce}
data-href={`${assetPrefix}/_next/${file}`}
dangerouslySetInnerHTML={{
__html: readFileSync(join(process.cwd(), ".next", file), "utf-8"),
}}
/>
));
};
}
export default function Document() {
return (
<Html>
<InlineStylesHead />
<body>
<Main />
<NextScript />
</body>
</Html>
);
}
Option 3 : Styled Components (Pages Router)
Styled Components est un outil CSS-in-JS qui vous permet d'écrire du CSS dans des fichiers JavaScript. Vous pouvez limiter la portée des noms de classe, supprimer automatiquement le CSS inutilisé et gérer les styles à côté de vos composants. Pour les Core Web Vitals, cela signifie que seuls les styles nécessaires sur cette page sont injectés.
Ajoutez compiler: { styledComponents: true } à votre next.config.js, installez styled-components (yarn add styled-components et yarn add -D @types/styled-components), puis mettez à jour _document.js pour prendre en charge le rendu côté serveur (SSR) pour styled components.
const nextConfig = {
reactStrictMode: true,
compiler: {
styledComponents: true,
}
}
import Document, { DocumentContext } from "next/document";
import { ServerStyleSheet } from "styled-components";
export default class MyDocument extends Document {
static async getInitialProps(ctx: DocumentContext) {
const sheet = new ServerStyleSheet();
const originalRenderPage = ctx.renderPage;
try {
ctx.renderPage = () =>
originalRenderPage({
enhanceApp: (App) => (props) =>
sheet.collectStyles(<App {...props} />),
});
const initialProps = await Document.getInitialProps(ctx);
return {
...initialProps,
styles: (
<>
{initialProps.styles}
{sheet.getStyleElement()}
</>
),
};
} finally {
sheet.seal();
}
}
}
Si vous utilisez l'App Router avec styled-components, vous avez besoin d'une configuration différente. Créez un composant client registre de styles en utilisant useServerInsertedHTML et enveloppez votre layout racine avec celui-ci. Les styled components ne fonctionnent que dans les composants clients (Client Components) dans l'App Router. Consultez le guide CSS-in-JS de Next.js pour le modèle complet.
Option 4 : Intégrer le CSS en ligne avec inlineCss (App Router, Next.js 15+)
Pour l'App Router, Next.js 15 a introduit experimental.inlineCss. Cela remplace toutes les balises de feuille de style <link> par des balises <style> en ligne, éliminant entièrement la cascade (waterfall) bloquant le rendu.
const nextConfig = {
experimental: {
inlineCss: true,
}
}
Ceci est toujours expérimental et l'équipe Next.js ne le recommande pas encore pour la production. Cela intègre tout le CSS en ligne (pas seulement le CSS critique), ce qui augmente la taille du HTML. Pour les sites utilisant Tailwind CSS, ce compromis fonctionne bien car Tailwind génère de petits bundles CSS atomiques. Pour les sites avec de grandes feuilles de style, le gonflement du HTML peut nuire au Time to First Byte.
Une note sur les modules CSS et Tailwind CSS
Les modules CSS (CSS Modules) et Tailwind CSS sont les deux approches de style les plus populaires dans Next.js aujourd'hui. Les deux sont compilés en fichiers CSS standard au moment de la compilation et sont servis sous forme de balises <link>. Cela signifie qu'ils bloquent le rendu par défaut.
Tailwind a un avantage : comme il purge les classes inutilisées, la sortie est généralement très petite (souvent moins de 10 Ko gzippés). L'impact bloquant le rendu d'un fichier de 10 Ko est minime. Les modules CSS peuvent devenir plus volumineux si vous ne faites pas attention aux styles inutilisés.
Dans les deux cas, toutes les options ci-dessus s'appliquent. Si vous souhaitez éliminer entièrement le CSS bloquant le rendu, combinez votre approche de style préférée avec optimizeCss (Pages Router) ou inlineCss (App Router).
Quelle option dois-je utiliser ?
Cela dépend de votre routeur et de votre stratégie CSS :
- App Router + Tailwind : Utilisez
inlineCss. Les petits bundles CSS rendent l'intégration en ligne pratique. - App Router + gros CSS : Attendez que
inlineCssse stabilise, ou utilisez une configuration beasties personnalisée. - Pages Router : Utilisez
optimizeCss(Option 1). C'est la solution la plus simple et n'intègre en ligne que ce qui est critique. - Pages Router + CSS-in-JS : Utilisez styled-components ou Emotion avec les modèles SSR présentés ci-dessus.
Parmi les sites Next.js surveillés par CoreDash, ceux qui utilisent du CSS critique en ligne montrent une amélioration médiane du FCP de 400 ms par rapport à la livraison de CSS par défaut. C'est la différence entre un bon et un médiocre score FCP.
Quelle que soit l'option que vous choisissez, vérifiez les résultats avec le Real User Monitoring (RUM). Les scores de laboratoire vous disent ce qui pourrait arriver. Les données de terrain vous disent ce qui s'est réellement passé.
Pour en savoir plus sur la façon dont le CSS et le JavaScript interagissent avec le pipeline de rendu, consultez le guide complet pour corriger les ressources bloquant le rendu. Si vous optimisez une application Next.js, consultez également les guides sur la correction des scripts tiers et la mesure des Core Web Vitals dans Next.js. Pour un aperçu plus large de la stratégie de chargement, le guide de priorisation des ressources explique comment les navigateurs décident quoi récupérer en premier.
17 years of fixing PageSpeed.
I have optimized platforms for some of the largest publishers and e-commerce sites in Europe. I provide the strategy, the code, and the RUM verification. Usually in 1 to 2 sprints.
View Services
