Comment accélérer son site web en 2026 : Core Web Vitals et outils

Un site lent se voit d'abord sur mobile : la page reste blanche, le texte saute quand l'image arrive, le menu répond avec un temps de retard. Google mesure ces trois défauts avec les Core Web Vitals, et vos visiteurs les ressentent avant même de lire la première ligne.

Dans cet article, on vous donne les seuils à viser en 2026, les outils pour tester la vitesse de votre site (et ce que chacun mesure vraiment), une méthode pour savoir par quoi commencer, et ce qu'on peut régler sur un site Webflow.

Article publié en 2021, entièrement mis à jour le 6 octobre 2026.

Les Core Web Vitals en 2026 : trois seuils à tenir

Les Core Web Vitals sont trois indicateurs, mesurés sur de vraies visites. Une page les respecte quand 75 % des visites (le 75e centile) passent sous le seuil, en distinguant mobile et ordinateur (web.dev).

Seuils : web.dev, LCP, INP, CLS.

L'INP a remplacé le FID le 12 mars 2024 (web.dev). Le FID ne mesurait que le délai avant la première interaction ; l'INP mesure toutes les interactions de la visite. Si un guide vous parle encore du FID, il date d'avant 2024.

Côté SEO, Google écrit que les Core Web Vitals correspondent à ce que ses systèmes de classement cherchent à récompenser, et recommande de les soigner (Google Search Central). Il ne promet pas qu'un bon score fait monter une page : la vitesse départage des pages proches, elle ne remplace pas un contenu pertinent.

Côté visiteurs, une étude Google/SOASTA de 2017, à prendre comme un ordre de grandeur, estimait que la probabilité de rebond sur mobile augmente de 32 % quand le chargement passe d'une à trois secondes (Google, Milliseconds Make Millions).

Tester la vitesse d'un site : quel outil pour quoi

Deux familles d'outils coexistent. Les données terrain viennent de vraies visites sur Chrome, via le Chrome User Experience Report (CrUX). Les données de laboratoire viennent d'un chargement simulé, toujours dans les mêmes conditions. Les premières disent si vous avez un problème, les secondes aident à trouver d'où il vient.

Avant de tirer des conclusions, gardez en tête ce que chaque chiffre mesure :

• Le score de performance sur 100 est un score de laboratoire. Un 99 dans Lighthouse ne garantit pas que vos visiteurs passent les seuils, et l'inverse est vrai aussi. PageSpeed Insights juge les Core Web Vitals sur les données terrain : la page réussit quand les trois indicateurs sont bons au 75e centile (documentation PageSpeed Insights).
• Dans un test de chargement classique, Lighthouse ne mesure pas l'INP. Sans utilisateur qui clique, il n'y a pas d'interaction à mesurer, et Lighthouse affiche le Total Blocking Time (TBT) à la place (web.dev). Pour l'INP, ce sont les données terrain qui comptent.
• Un site à faible trafic peut n'avoir aucune donnée terrain, car CrUX ne couvre que les pages et les sites qui ont assez de visites (Chrome for Developers). C'est fréquent pour un site B2B : PageSpeed Insights n'affiche alors que le laboratoire, et le rapport Search Console reste vide. Dans ce cas, testez vos modèles de pages principaux dans Lighthouse, sur mobile.

Dans Search Console, une correction se valide avec le bouton Commencer le suivi : Google suit alors les pages concernées pendant 28 jours (Aide Search Console). La vitesse fait d'ailleurs partie des points à contrôler dans un audit SEO complet.

Par où commencer : lire ce qui ralentit le LCP

« CDN ou optimisation des images, qu'est-ce qui fait gagner le plus ? » La réponse dépend de votre page, et elle se lit dans le détail du LCP. web.dev le découpe en quatre temps (web.dev, optimiser le LCP) :

1. Le temps de réponse du serveur (TTFB) : avant que le navigateur reçoive le premier octet de la page.
2. Le délai avant chargement : le temps que le navigateur découvre l'image principale et commence à la télécharger.
3. La durée de chargement de cette image.
4. Le délai de rendu : entre la fin du téléchargement et l'affichage.

L'audit LCP breakdown de Lighthouse, repris dans la partie laboratoire de PageSpeed Insights, et le panneau Performance de Chrome DevTools affichent ce découpage (Chrome for Developers). Ensuite, le choix se fait presque tout seul :

Si c'est le CLS qui échoue, cherchez une image sans dimensions, une police qui change la taille du texte en arrivant, ou un bandeau (cookies, publicité, widget) qui s'insère au-dessus du contenu (web.dev). Si c'est l'INP, regardez du côté du JavaScript : scripts tiers, tâches longues, page trop chargée en éléments (web.dev, optimiser l'INP).

Les images : le poste le plus fréquent

Sur un site vitrine ou un site marketing, l'élément LCP est souvent une image. Quatre réglages couvrent l'essentiel :

• Le format : WebP ou AVIF pour les photos, SVG pour les logos et les icônes. Les deux formats sont lus par plus de 96 % des navigateurs (Can I use : AVIF, WebP).
• Les dimensions : servir l'image à la taille où elle s'affiche, en srcset pour laisser le navigateur choisir. Indiquez toujours une largeur et une hauteur, sinon la page se décale à l'arrivée de l'image.
• Le chargement différé : le lazy loading est utile pour les images situées plus bas dans la page, jamais pour l'image principale. web.dev le dit sans détour : ne pas mettre loading="lazy" sur l'élément LCP.
• La priorité : l'attribut fetchpriority="high" sur l'image principale demande au navigateur de la télécharger en premier.

Les dimensions recommandées pour chaque usage (pleine largeur, article, Open Graph, favicon) sont détaillées dans notre guide tailles et formats d'image pour un site web.

Polices, scripts tiers, animations

Les polices

Chaque police, chaque graisse est un fichier de plus à télécharger avant que le texte s'affiche dans sa forme finale. web.dev recommande le format WOFF2, un nombre de polices réduit (une police variable remplace plusieurs graisses) et un réglage font-display explicite : swap affiche tout de suite le texte dans une police système, optional privilégie la performance et peut garder la police système si la police web arrive trop tard (web.dev). On détaille le sujet dans Font Display : optimisez votre site sur Google.

Les scripts tiers

Analytics, gestionnaire de balises, chat, bandeau cookies, carte de chaleur, vidéo intégrée : chaque outil ajouté par une équipe marketing charge son propre JavaScript, et c'est souvent lui qui dégrade l'INP. Trois questions à se poser pour chaque script :

• Est-il encore utilisé ? Les balises d'une campagne terminée restent souvent en place des mois.
• Peut-il se charger plus tard ? Un script qui n'est pas nécessaire au premier affichage se charge avec defer ou async, en fin de page.
• Peut-on le remplacer par plus léger ? Une vidéo YouTube peut s'afficher sous forme d'image cliquable et ne charger le lecteur qu'au clic.

Les animations

Une animation bien faite ne coûte presque rien. web.dev recommande d'animer transform et opacity plutôt que la largeur, la hauteur ou la position, qui forcent le navigateur à recalculer la mise en page et provoquent des décalages (web.dev).

Un piège fréquent concerne l'animation d'entrée du haut de page. Un élément d'opacité 0 n'est pas pris en compte pour le LCP (web.dev) : si le titre ou l'image principale apparaissent en fondu après le chargement, le LCP n'est compté qu'à la fin du fondu.

Serveur et CDN : ce qu'un CDN change vraiment

Un CDN (Content Delivery Network) garde des copies de vos fichiers dans des serveurs répartis dans le monde. Le visiteur les reçoit depuis le serveur le plus proche au lieu de les faire venir de votre hébergement d'origine. Le gain porte sur le temps de réponse du serveur et sur le téléchargement des fichiers : c'est l'une des pistes que web.dev cite pour améliorer le LCP (web.dev).

Le temps de réponse du serveur n'est pas une Core Web Vital, mais web.dev conseille de viser 0,8 seconde ou moins (web.dev). Au-delà, c'est l'hébergement qu'il faut regarder avant de compresser une image de plus. Sans CDN, l'emplacement du serveur compte : un site dont l'audience est en France gagne à être hébergé en Europe. Avec un CDN, cette question pèse beaucoup moins.

Si votre hébergement n'inclut pas de CDN, deux options courantes :

Un CDN ne règle pas tout. Il accélère la livraison d'une image de 3 Mo, il ne la rend pas plus légère. Et il n'a presque aucun effet sur l'INP ou le CLS, qui se jouent dans le navigateur.

Sur Webflow : ce qui est inclus, ce que vous réglez

Ce qui est inclus

L'hébergement Webflow repose sur l'infrastructure d'AWS et le CDN de Cloudflare ; Webflow annonce atteindre 95 % de la population mondiale en moins de 50 millisecondes (Webflow, hébergement). Le certificat SSL, les images responsives et la conversion en WebP ou AVIF sont compris dans les plans de site. Vous n'avez donc ni CDN à brancher, ni serveur à choisir, ni cache à configurer.

Ce que vous réglez

• Côté images, les nouvelles images sont en lazy par défaut (Webflow) : passez l'image principale de chaque page en Eager dans les réglages de l'élément. Le chargement différé ne s'applique pas aux images de fond : une grande image de fond en haut de page peut être l'élément LCP, et le navigateur ne la découvre qu'en lisant le CSS. Convertissez vos images dans le panneau Assets, en gardant en tête que Webflow ne génère pas de variantes responsives pour l'AVIF (détails dans notre guide des images).
• Pour les polices, le réglage font-display est disponible pour les polices personnalisées importées dans Site settings, pas pour les polices Google ou Adobe ajoutées par l'intégration native. Pour le régler sur ces polices, il faut télécharger les fichiers et les importer comme police personnalisée (Webflow).
• Pour le code, tout se règle dans Site settings → Publishing → Advanced publishing options : minification du HTML, du CSS et du JavaScript ; chargement asynchrone du JavaScript, lancé le 18 février 2025 et réservé aux plans payants (Webflow) ; CSS par page, lancé le 27 mai 2025 et désactivé par défaut (Webflow). Ces deux dernières options peuvent casser du code personnalisé : testez sur le domaine de staging avant de publier.
• Les scripts tiers : le code ajouté dans les réglages du site s'exécute sur toutes les pages. Placez dans la zone Footer code (avant </body>) ce qui n'a pas besoin d'être en <head>, et ajoutez le code propre à une page dans les réglages de cette page plutôt que sur tout le site.
• Pour les interactions, depuis le 30 septembre 2025, les Interactions with GSAP permettent de limiter une interaction à certaines pages et de respecter le réglage « réduire les animations » du visiteur (Webflow). Évitez les entrées en fondu sur le titre et l'image du haut de page.

Notre avis

Sur un site marketing hébergé correctement, la lenteur vient rarement du serveur. Elle vient d'une image principale trop lourde, d'une animation d'entrée sur le titre, ou d'une dizaine de scripts tiers ajoutés au fil des campagnes. Autrement dit, de décisions de design et de marketing, qui se corrigent sans changer d'hébergeur.

Regardez donc les données terrain avant le score sur 100. Un 99 dans Lighthouse fait plaisir en réunion ; ce qui compte, c'est le LCP mesuré sur le téléphone de vos visiteurs. Et la vitesse se maintient plus qu'elle ne s'obtient une fois pour toutes : chaque nouvelle page, chaque nouvel outil peut la dégrader. Si vous voulez qu'une équipe suive votre site dans la durée (SEO, visibilité IA, CRO, évolutions), c'est l'objet de notre offre Growth & Performances.

Questions fréquentes

Comment rendre son site internet plus rapide ?

Commencez par mesurer : PageSpeed Insights sur votre page d'accueil et vos pages clés, sur mobile. Regardez ensuite lequel des trois indicateurs échoue. Le plus souvent, les gains viennent de l'image principale (format, poids, chargement immédiat), des scripts tiers inutiles et des animations d'entrée. L'hébergement et le CDN viennent ensuite, si le temps de réponse du serveur dépasse 0,8 seconde.

Quel est un bon temps de chargement pour un site web ?

Google ne fixe pas de « temps de chargement total ». Le repère officiel est le LCP : 2,5 secondes ou moins pour au moins 75 % des visites. Pour la réactivité, un INP de 200 ms ou moins, et pour la stabilité, un CLS de 0,1 ou moins.

Comment un CDN améliore-t-il la vitesse d'un site ?

Il sert vos fichiers depuis un serveur proche du visiteur au lieu de votre hébergement d'origine. Le temps de réponse et le téléchargement des fichiers baissent, surtout pour une audience éloignée de votre serveur. Il n'allège pas les fichiers et n'améliore ni l'INP ni le CLS.

CDN ou optimisation des images : par quoi commencer ?

Regardez le détail du LCP dans la partie laboratoire de PageSpeed Insights. Si le temps de réponse du serveur domine, le CDN ou l'hébergement passent en premier. Si c'est le chargement de l'image, travaillez l'image. Sur un site Webflow, la question ne se pose pas : le CDN est déjà là, il reste les images.

Comment tester la vitesse d'un site web gratuitement ?

PageSpeed Insights pour une page, le rapport Core Web Vitals de Search Console pour tout le site, Lighthouse dans Chrome pour le diagnostic. WebPageTest propose une offre gratuite de 150 tests par mois pour tester depuis d'autres pays ou sur une connexion lente.

Pourquoi PageSpeed Insights n'affiche pas de données terrain pour mon site ?

Parce que votre page ou votre site n'a pas assez de visites Chrome pour figurer dans CrUX. Vous n'avez alors que les données de laboratoire : testez vos principaux modèles de pages sur mobile et corrigez ce que Lighthouse signale.

La vitesse du site influence-t-elle le SEO ?

Oui, mais comme un critère parmi d'autres. Google indique que les Core Web Vitals correspondent à ce que ses systèmes de classement cherchent à récompenser, sans promettre de gain de position. Un site rapide avec un contenu faible ne passera pas devant un contenu plus utile.

Sources

• web.dev : Core Web Vitals · LCP · INP · CLS · TTFB
• web.dev : optimiser le LCP · optimiser l'INP · bonnes pratiques pour les polices · INP devient une Core Web Vital
• Google Search Central : Core Web Vitals et résultats de recherche · Aide Search Console : rapport Core Web Vitals
• PageSpeed Insights : documentation · CrUX · Lighthouse · WebPageTest : offres
• Cloudflare : offres · Bunny CDN : tarifs
• Webflow : hébergement · JavaScript par page · CSS par page · font-display · Interactions with GSAP
• Google/SOASTA, 2017, dans Milliseconds Make Millions