Core Web Vitals en 2026 : ce que les entreprises britanniques doivent réellement mesurer

Une page peut sembler rapide sur une bonne connexion de bureau et échouer pour la personne qui l'ouvre sur son téléphone, entre deux tâches, avec un signal plus faible. La vitesse n'est pas une seule impression. Un site d'entreprise doit montrer ce que le visiteur est venu chercher, répondre lorsqu'il appuie, et rester stable pendant ce temps. Il doit aussi être utilisable sur un petit écran, et la façon dont il est construit doit rester efficace à mesure que les pages et les scripts s'accumulent.

Les Core Web Vitals sont les trois mesures que Google demande aux propriétaires de sites d'utiliser pour le chargement, la réactivité et la stabilité visuelle. Ce n'est pas une formule qui place une page en première position, et ce n'est pas la seule chose qui vaille d'être mesurée. C'est un langage commun pour un problème qui, sinon, se résume à « le site paraît lent ».

Que sont les Core Web Vitals ?

Les Core Web Vitals sont des mesures de terrain, décrites par Google sur web.dev et dans Google Search Central. Les trois mesures actuelles sont le Largest Contentful Paint, l'Interaction to Next Paint et le Cumulative Layout Shift. Google recommande de juger chacune au 75e centile des pages vues, et de le faire séparément pour le mobile et pour l'ordinateur. Une page est en bon état sur une mesure lorsqu'au moins trois quarts de ces visites atteignent le seuil « bon », pas lorsqu'un seul passage sur la machine d'un développeur a l'air correct.

L'ensemble peut évoluer. Google a indiqué que les définitions sont censées rester stables, avec un préavis avant un changement. Le First Input Delay était auparavant la mesure de réactivité. L'Interaction to Next Paint l'a remplacé comme Core Web Vital en mars 2024. Un conseil qui traite encore le First Input Delay comme la mesure actuelle est dépassé.

LCP : Largest Contentful Paint

Le Largest Contentful Paint mesure le chargement. Il marque le moment où la plus grande image ou le plus grand bloc de texte dans la zone visible a été peint. Sur une page d'accueil d'entreprise, il s'agit souvent de l'image principale ou du titre principal. Le seuil publié par Google pour une bonne expérience est de 2,5 secondes ou moins à partir du début du chargement. Au-dessus de 2,5 secondes, et jusqu'à 4 secondes, le résultat est à améliorer. Au-delà de 4 secondes, il est mauvais.

Cette mesure compte parce qu'elle est proche du moment où un visiteur comprend à quoi sert la page. Un logo qui apparaît tout de suite, suivi d'une longue attente pour l'offre elle-même, peut rester un mauvais résultat sur cet indicateur.

INP : Interaction to Next Paint

L'Interaction to Next Paint mesure la réactivité. Elle observe les clics, les appuis et la saisie clavier pendant la visite, et rapporte une valeur qui représente les interactions les plus lentes, hors valeurs extrêmes. Ce que le visiteur ressent, c'est l'écart entre un appui et le changement suivant qu'il peut voir : un menu qui s'ouvre, un formulaire qui accuse réception, un filtre qui s'applique.

Un bon résultat, selon les seuils publiés par Google, est de 200 millisecondes ou moins. Au-dessus de 200 millisecondes, et jusqu'à 500 millisecondes, le résultat est à améliorer. Au-delà de 500 millisecondes, il est mauvais. Une page peut réussir un contrôle de temps de chargement et sembler pourtant bloquée, ce qui explique que cette mesure soit distincte du Largest Contentful Paint. Elle a remplacé le First Input Delay, qui ne mesurait que le délai avant que le navigateur commence à traiter la première interaction, pas le temps mis par la page à montrer une réponse, ni les interactions suivantes.

CLS : Cumulative Layout Shift

Le Cumulative Layout Shift mesure la stabilité visuelle. Il additionne les déplacements inattendus du contenu visible. Un bon score est de 0,1 ou moins. Au-dessus de 0,1, et jusqu'à 0,25, le résultat est à améliorer. Au-delà de 0,25, il est mauvais. Un score de zéro signifierait que rien n'a bougé. Un léger déplacement peut se voir sans rendre la page inutilisable, ce qui explique que le seuil « bon » ne soit pas zéro.

Les déplacements que les gens supportent mal sont ceux qui arrivent au moment où ils vont appuyer. Un bandeau pousse un bouton vers le bas. Une image arrive sans espace réservé. Une police se substitue et le paragraphe se réorganise. Un mouvement demandé par le visiteur, comme l'ouverture d'une section, n'est pas ce que cette mesure cherche à attraper.

Pourquoi la performance compte pour les entreprises britanniques

L'effet direct porte sur la personne qui utilise le site. Une page lente ou instable est plus difficile à lire, plus difficile à croire et plus facile à quitter, surtout sur téléphone, souvent le premier écran sur lequel un site d'entreprise est ouvert. Cela se voit dans des demandes et des paiements qui n'aboutissent pas, même lorsque personne n'a lancé de test formel. C'est aussi une question d'accessibilité. Une page qui saute, ou qui ne répond qu'après un long script, est une moins bonne page pour quelqu'un qui trouve déjà l'interface difficile.

La recherche est l'effet indirect. La documentation de Google sur l'expérience de page indique que ses systèmes de classement utilisent les Core Web Vitals, qu'il n'existe pas un score unique d'expérience de page, et qu'un bon résultat sur ces mesures ne place pas, à lui seul, une page en tête. La recherche peut encore montrer la page la plus pertinente lorsque l'expérience est médiocre. Lorsque de nombreuses pages sont utiles de façon comparable, une meilleure expérience peut contribuer. Traitez la performance comme un soin porté au visiteur, qui peut soutenir la recherche. Ne la traitez pas comme un levier qui attribue la première place.

Le même soin compte si l'on veut que le site soit une source que d'autres systèmes peuvent lire fidèlement. Une page qui ne se charge pas proprement est une page faible en recherche classique, et une page faible pour un outil qui tenterait de la résumer. Ce point plus large est dans l'article sur le SEO et la recherche par IA.

Pourquoi un site devient-il lent ?

La lenteur est en général la somme de plusieurs décisions ordinaires.

• Des images plus grandes que l'espace qu'elles occupent, ou dans un format que le navigateur décode difficilement.
• Trop de JavaScript, y compris du code pour des fonctions que la page n'utilise jamais.
• Des scripts tiers pour le chat, les balises, la publicité ou les médias intégrés, chacun ajoutant une requête et entrant souvent en concurrence avec la page.
• Un cache absent, ou si court que chaque visite reconstruit la même page.
• Une réponse lente du serveur avant l'envoi du premier octet de la page.
• Des polices lourdes, ou qui arrivent tard et déplacent la mise en page.
• Une dépendance appelée pour un seul composant, puis envoyée sur toutes les pages.
• Des composants qui demandent plus de données que l'écran n'en montre, ou qui s'attendent les uns les autres en chaîne.
• Des appels d'API à chaque affichage alors que le résultat aurait pu être préparé plus tôt.

Comment le développement web moderne peut améliorer la performance

Les remèdes relèvent d'une ingénierie ordinaire, appliquée avec retenue plutôt que comme une liste d'outils.

• Optimiser les images : des dimensions raisonnables, un format moderne, et un espace réservé dans la mise en page pour que la page ne saute pas.
• Charger en différé les images et les intégrations situées sous le premier écran. Ne pas différer l'image qui constitue le Largest Contentful Paint.
• Découper le code pour qu'une page ne télécharge pas le JavaScript du reste du site.
• Mettre en cache les pages et les fichiers identiques pour chaque visiteur.
• Servir ces fichiers depuis un réseau de diffusion, pour que la distance pèse moins dans l'attente.
• Faire le rendu côté serveur, ou générer la page à l'avance, lorsque le contenu est connu avant la visite. Un tableau de bord derrière une connexion est un autre cas, et il n'a pas besoin du même traitement.
• Récupérer les données dont cette page a besoin, pas une copie de tout ce que l'entreprise stocke.
• Retirer les scripts qui n'apportent rien.
• Charger les polices de façon à limiter les réorganisations, et ne pas envoyer des graisses que le design n'utilise pas.

Next.js, utilisé avec React et TypeScript, peut aider sur plusieurs de ces points : le traitement des images, le découpage du code par route, et le choix d'un rendu serveur ou d'une génération statique pour chaque page. Il ne rend pas un site rapide parce qu'il figure sur une facture. Un site Next.js avec une image d'accueil trop lourde, un widget de chat sur chaque modèle et un composant client qui embarque une grosse bibliothèque manquera les mêmes seuils. La comparaison entre React et Next.js porte sur ce point de départ. Ce n'est pas la promesse d'un score particulier.

Comment mesurer correctement la performance

Il faut regarder au-delà de la page d'accueil, et au-delà d'un seul outil.

• Les Core Web Vitals pour le chargement, la réactivité et la stabilité visuelle, au 75e centile, sur mobile et sur ordinateur.
• Les données de terrain, lorsqu'il y a assez de trafic pour en avoir. Le rapport Core Web Vitals de la Search Console, et la partie terrain de PageSpeed Insights, reflètent de vrais utilisateurs de Chrome. Une page peu visitée peut ne pas avoir encore de données de terrain. C'est une limite des données, pas une réussite.
• Des tests en laboratoire, comme Lighthouse, pour reproduire un défaut et voir quelle requête ou quel script est en cause. Un résultat de laboratoire est un passage contrôlé. Il ne remplace pas le rapport de terrain.
• La réponse du serveur, le poids de la page, et le temps d'exécution du JavaScript. Ces éléments expliquent un mauvais résultat. Ce ne sont pas eux-mêmes des Core Web Vitals.
• Les pages qui portent l'activité : pages de services, pages d'atterrissage de campagnes, parcours de devis ou de paiement, et articles importants. Une page d'accueil rapide avec une page de service lente est un site lent pour la personne venue faire une demande.

Il faut retester après un changement, sur un écran de la taille d'un téléphone comme sur un écran de bureau. Un correctif qui n'apparaît qu'en laboratoire, sur un ordinateur puissant, n'a pas démontré qu'il aide les visiteurs.

Core Web Vitals et recherche

L'enchaînement honnête va de la qualité technique à la sensation d'usage, puis à la possibilité que cette expérience soutienne le référencement. La documentation de Google indique que les systèmes de classement regardent des signaux variés, que les Core Web Vitals font partie des signaux que ces systèmes utilisent, et qu'un score fort n'est pas une promesse de première place. La pertinence passe encore devant.

Ce que l'on peut maîtriser, c'est la page. Faire apparaître le contenu principal sans tarder, répondre vite à un appui et garder la mise en page stable. Donner à chaque service important une URL qui correspond à la recherche, avec un texte qu'un robot peut lire. C'est la même discipline que le reste du SEO technique, pas une astuce à part. Si un nouveau design est en discussion, il faut vérifier si le problème de performance vient des fichiers et de la mise en page, ou de l'architecture. L'article sur la refonte ou la reconstruction est la décision qui suit. Une refonte visuelle peut améliorer les mesures lorsque la cause est un média lourd ou une mise en page instable. Elle ne retire pas une attente structurelle.

Comment Web Works Rise aborde la performance

La performance fait partie du développement web, pas d'un rapport écrit une fois le site déjà en ligne. Les sites publics sont construits avec React, Next.js et TypeScript, en portant attention à ce que chaque page envoie au navigateur. La structure technique, les métadonnées et les liens internes font partie de la même réalisation. L'hébergement cloud et la maintenance sont ce qui permet à cette performance de survivre au prochain script de campagne et à la prochaine série de contenus. Rien dans cette pile ne garantit un score de laboratoire particulier.

Web Works Rise est une équipe dirigée depuis le Royaume-Uni, basée à Birmingham, avec un pôle de développement en Tunisie qui appuie la livraison. Si une page importante est lente, ou si une reconstruction est envisagée parce que le site actuel ne peut pas être rendu rapide, contactez l'équipe avec l'URL. Une mesure de la page qui compte est un meilleur départ qu'une promesse de score.