Reflow du navigateur : ce qui le déclenche et comment il affecte les Core Web Vitals

Qu'est-ce que le reflow du navigateur ?

Le reflow est ce qui se produit lorsque le navigateur recalcule la position et la taille des éléments sur la page. Chaque fois que vous modifiez le DOM ou une propriété CSS qui affecte la mise en page, le navigateur doit déterminer à nouveau où tout va. Ce calcul bloque le thread principal. Rien d'autre ne se passe jusqu'à ce qu'il se termine.

Un seul reflow sur une page simple prend des microsecondes. Mais déclenchez-en des centaines pendant une interaction utilisateur et vous vous retrouvez avec des centaines de millisecondes de temps de thread principal bloqué. C'est suffisant pour échouer à l'Interaction to Next Paint.

Dernière révision par Arjen Karel en mars 2026

Le pipeline de rendu

Pour comprendre pourquoi le reflow est coûteux, vous devez savoir comment le navigateur effectue le rendu d'une page. Chaque changement visuel passe par un maximum de cinq étapes :

JavaScript → Style → Layout → Paint → Composite

JavaScript (ou CSS) déclenche un changement visuel. Le navigateur recalcule quels styles s'appliquent. Ensuite, il exécute le layout (reflow) pour calculer la géométrie. Puis il peint (paint) les pixels. Enfin, il compose (composite) les couches ensemble.

Tous les changements ne passent pas par les cinq étapes. C'est l'information clé. Modifiez width ou height et vous déclenchez l'ensemble du pipeline. Modifiez background-color et vous ignorez complètement le layout (paint + composite uniquement). Modifiez transform ou opacity et vous ignorez à la fois le layout et le paint, en passant directement au composite. Le guide web.dev sur les performances de rendu couvre ce pipeline en détail.

Les changements de type composite uniquement sont peu coûteux. Les changements de layout ne le sont pas. À 60 ips, le navigateur dispose de 16,66 ms par image pour tout faire. Après la surcharge du navigateur, vous obtenez environ 10 ms pour votre code. Dépensez cela en reflow et vous obtenez des saccades (jank).

Ce qui déclenche le reflow

Deux catégories de choses causent un reflow : les modifications qui invalident le layout actuel, et les lectures JavaScript qui forcent le navigateur à calculer le layout immédiatement.

Les propriétés CSS qui déclenchent le layout

La modification de l'une de ces propriétés force le navigateur à effectuer un reflow :

• Dimensions : width, height, padding, border, min-height, max-width
• Position : top, right, bottom, left, margin
• Mode de mise en page : display, float, position, flex, grid
• Texte : font-size, font-family, font-weight, line-height, text-align, white-space
• Contenu : overflow, word-wrap

Des propriétés comme color, background-color, visibility et box-shadow déclenchent un repaint mais pas un reflow. Des propriétés comme transform, opacity et filter ne déclenchent aucun des deux. Ce sont les propriétés que vous souhaitez pour les animations et transitions.

Les propriétés JavaScript qui forcent un layout synchrone

C'est ici que cela devient coûteux. Certaines propriétés JavaScript forcent le navigateur à calculer le layout immédiatement, de manière synchrone, bloquant ainsi votre script. Paul Irish maintient une liste exhaustive (plus de 5 000 étoiles sur GitHub). Les plus courantes sont :

• offsetWidth, offsetHeight, offsetTop, offsetLeft
• clientWidth, clientHeight, clientTop, clientLeft
• scrollWidth, scrollHeight, scrollTop, scrollLeft
• getBoundingClientRect()
• getComputedStyle()
• innerText (oui, lire innerText force le layout)
• focus()
• scrollIntoView()

La lecture de l'une de ces propriétés après la modification d'une propriété de layout force un reflow synchrone. Le navigateur ne peut pas retourner la valeur sans calculer d'abord le layout. Les Chrome DevTools signalent les reflows forcés qui dépassent 30 ms comme un goulot d'étranglement des performances.

Layout thrashing : le motif à éviter

Le layout thrashing se produit lorsque votre code alterne entre la lecture et l'écriture de propriétés de layout dans une boucle. Chaque lecture force un reflow car l'écriture précédente a invalidé le layout. Je vois constamment ce motif dans les scripts de carrousel, les plugins d'accordéon et le code d'analyse qui mesure les positions des éléments.

// MAUVAIS : force le reflow à chaque itération
for (const el of elements) {
  el.style.width = box.offsetWidth + 'px'; // lecture + écriture = reflow forcé
}

Chaque itération lit offsetWidth (forçant le layout) puis écrit style.width (invalidant le layout). Avec 100 éléments, cela représente 100 reflows forcés au lieu d'un seul.

// BON : regroupez la lecture, puis regroupez les écritures
const width = box.offsetWidth; // lecture unique
for (const el of elements) {
  el.style.width = width + 'px'; // écritures uniquement, pas de reflows forcés
}

Une lecture, un reflow, c'est fait. Le guide web.dev sur le layout thrashing montre ce motif en détail. Si vous devez lire les tailles individuelles des éléments, collectez d'abord toutes les lectures, puis effectuez toutes les écritures.

Détecter le reflow forcé dans les Chrome DevTools

Ouvrez le panneau de performances (Performance panel) et enregistrez une trace. Les reflows forcés apparaissent sous forme de blocs violets "Layout" dans le graphique de flamme (flame chart). Si Chrome détecte un layout synchrone forcé, il ajoute un avertissement en forme de triangle rouge. Survolez-le et vous verrez exactement quelle ligne JavaScript a déclenché le reflow.

La console enregistre également un avertissement : "Forced reflow while executing JavaScript took Xms". Tout ce qui dépasse 30 ms est un problème. J'ai vu des sites où un seul gestionnaire d'événements de défilement déclenche 40 ms de travail de layout à chaque image.

Lighthouse le signale également. Recherchez le diagnostic "Avoid forced reflow" dans la catégorie Performance.

Comment le reflow affecte les Core Web Vitals

Interaction to Next Paint (INP)

Le reflow impacte directement l'INP de deux manières. Si un reflow forcé est déjà en cours d'exécution lorsque l'utilisateur clique, l'input delay augmente car le thread principal est bloqué. Si le gestionnaire de clic lui-même déclenche un travail de layout, le processing time augmente. Dans tous les cas, le presentation delay s'allonge également car le navigateur doit terminer le layout avant de pouvoir peindre la réponse.

Le seuil "bon" de l'INP est de 200 ms. Un seul reflow forcé de 30 ms consomme déjà 15 % de ce budget. Le layout thrashing dans un gestionnaire d'événements peut facilement pousser l'INP au-delà de 500 ms.

Sur l'ensemble des sites surveillés par CoreDash, les pages qui regroupent les lectures et écritures du DOM affichent des scores INP d'environ 18 % supérieurs par rapport aux pages présentant des motifs de layout thrashing.

Largest Contentful Paint (LCP)

Pendant le chargement de la page, le reflow entre en compétition pour le temps du thread principal. Le chargement des polices en est une source courante : lorsqu'une police web arrive et remplace le texte de fallback, le navigateur effectue un reflow de chaque élément utilisant cette police. Sur une page contenant beaucoup de texte, ce reflow peut repousser le LCP de 100 ms ou plus.

Les images sans attributs width et height explicites posent le même problème. Selon le Web Almanac 2025, 62 % des pages mobiles ont encore au moins une image sans dimensions. Lorsque cette image se charge, le navigateur effectue un reflow de la page pour s'adapter à la taille réelle.

Cumulative Layout Shift (CLS)

Le reflow en lui-même ne cause pas de CLS. Le CLS se produit lorsque des éléments visibles se déplacent après que l'utilisateur les a vus. Mais le reflow provenant d'un contenu chargé tardivement (publicités injectées, images sans taille, éléments insérés dynamiquement) est le mécanisme à l'origine de la plupart des décalages de mise en page. Corrigez le déclencheur de reflow et le décalage de mise en page disparaît.

Les transitions CSS qui animent les propriétés de layout en sont une autre source. La transition de height ou margin provoque un reflow à chaque image d'animation.

Prévenir le reflow avec du CSS moderne

Animations de type composite uniquement

Animez transform et opacity au lieu de width, height, top ou left. Ceux-ci s'exécutent sur le thread de composition du GPU et ignorent complètement le layout. Vous voulez déplacer un élément ? Utilisez transform: translateX(). Vous voulez le redimensionner visuellement ? Utilisez transform: scale(). Le Web Almanac 2025 a révélé que 40 % des pages mobiles utilisent encore des animations non composites. Cela représente 40 % des pages effectuant un travail de layout inutile à chaque image.

Le confinement CSS (containment)

La propriété contain indique au navigateur que les éléments internes d'un élément sont indépendants du reste de la page. Lorsque quelque chose change à l'intérieur d'un élément confiné, le navigateur effectue uniquement le reflow de ce sous-arbre au lieu de l'ensemble du document.

article {
  contain: content;
}

Cela est particulièrement utile pour les pages avec un grand DOM. Plus le navigateur doit vérifier d'éléments lors du reflow, plus cela prend de temps. Le confinement limite le rayon d'impact.

content-visibility

content-visibility: auto indique au navigateur d'ignorer les calculs de layout, de paint et de style pour les éléments qui sont hors écran. Lorsque Google a testé cela sur une démo de blog de voyage, le temps de rendu a chuté de 232 ms à 30 ms. Une amélioration par 7.

.section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

La propriété contain-intrinsic-size donne au navigateur une hauteur fictive afin que les calculs de la barre de défilement restent corrects. Cette propriété est devenue Baseline Newly Available en septembre 2025, ce qui signifie qu'elle fonctionne dans tous les navigateurs majeurs.

Check-list pratique

1. Regroupez les lectures du DOM avant les écritures. N'alternez jamais entre la lecture des propriétés de layout et l'écriture de modifications de style.
2. Définissez des dimensions explicites sur les images et les éléments intégrés. Cela empêche le reflow lors du chargement de la ressource.
3. Animez uniquement avec transform et opacity. Ceux-ci ignorent complètement le layout et le paint.
4. Utilisez contain: content sur des sections indépendantes. Cela limite le reflow au sous-arbre modifié.
5. Ajoutez content-visibility: auto aux sections situées sous la ligne de flottaison. Cela ignore le layout pour le contenu hors écran.
6. Préférez flexbox aux floats. La mise en page Flexbox est environ 4 fois plus rapide que la mise en page float pour le même nombre d'éléments.
7. Faites un yield au thread principal entre les opérations DOM coûteuses pour garder la page réactive.
8. Différez les scripts qui modifient le DOM jusqu'à ce que le rendu initial soit terminé.

Surveillez l'impact réel de ces changements avec le Real User Monitoring (RUM). Les outils de laboratoire comme Lighthouse vous montrent le coût du layout de manière isolée, mais les données de terrain montrent si vos utilisateurs expérimentent réellement l'amélioration.