La performance web est l’un des rares leviers de référencement que l’on peut mesurer, corriger et vérifier soi-même. Sur www.patrickligeron.fr, cette exigence se traduit par une configuration précise, que je détaille ici couche par couche : l’hébergement, le proxy, le socle WordPress, le cache et le traitement des images. Vous y trouverez les réglages qui comptent vraiment, la contribution de chaque brique, et le résultat mesuré au 6 juillet 2026. L’objectif n’est pas d’exhiber un score, mais de montrer une méthode reproductible sur votre propre site.
Table des matières
Ce que mesure réellement la performance web en 2026
Avant de parler de réglages, il faut savoir ce que l’on mesure. Deux notions se cachent derrière un score de performance, et les confondre conduit à de mauvaises décisions.
Score Lighthouse en laboratoire et Core Web Vitals sur le terrain : deux mesures distinctes
Un outil comme PageSpeed Insights affiche deux types de données. La première est une mesure de laboratoire, produite par Lighthouse : le navigateur simule un appareil et une connexion, charge la page une fois et calcule un score de 0 à 100. La seconde est une mesure de terrain, issue des visites réelles des utilisateurs Chrome, et c’est celle-là que Google utilise pour évaluer l’expérience sur la page. La capture présentée plus bas est une mesure de laboratoire : un instantané dans des conditions contrôlées, précieux pour diagnostiquer, mais qui ne remplace pas le suivi des utilisateurs réels. Les deux sont utiles, à condition de ne pas prendre l’un pour l’autre.
Les trois Core Web Vitals et leurs seuils
Les Core Web Vitals sont les trois indicateurs de référence de Google pour l’expérience de chargement. Le LCP (Largest Contentful Paint) mesure le temps d’affichage du plus grand élément visible ; le seuil « bon » est de 2,5 secondes ou moins. L’INP (Interaction to Next Paint) mesure la réactivité de la page aux interactions ; il a remplacé le FID en mars 2024, et son seuil « bon » est de 200 millisecondes ou moins. Le CLS (Cumulative Layout Shift) mesure la stabilité visuelle, c’est-à-dire l’absence de décalages inattendus pendant le chargement ; son seuil « bon » est de 0,1 ou moins. Ces trois seuils sont publiés par Google et s’évaluent au 75e centile des visites réelles.
Les résultats mesurés sur mon propre site
Voici l’état atteint par www.patrickligeron.fr, relevé le 6 juillet 2026 sur PageSpeed Insights, en version mobile (émulation d’un Moto G Power sur connexion 4G lente). Les quatre catégories principales affichent : 100 en performance, 97 en accessibilité, 96 en bonnes pratiques et 100 en SEO. La catégorie « Navigation agentique » valide les trois contrôles sur trois. Côtés métriques : First Contentful Paint à 0,9 seconde, Largest Contentful Paint à 0,9 seconde, Total Blocking Time à 20 millisecondes, Cumulative Layout Shift à 0 et Speed Index à 1,9 seconde. Le Total Blocking Time est la mesure de laboratoire qui sert à anticiper les problèmes de réactivité que l’INP capte sur le terrain. Ces valeurs proviennent d’un test sur une seule page et peuvent varier d’une exécution à l’autre, comme l’indique l’outil lui-même.
La couche infrastructure : hébergement OVH et proxy Cloudflare
La performance se construit du serveur vers le navigateur. Aucune optimisation logicielle ne compense un serveur lent : c’est la fondation.
Un hébergement à ressources dédiées (OVH hosting-performance-1)
Mon site est hébergé chez OVH sur une offre hosting-performance-1, à ressources dédiées. L’intérêt d’une offre à ressources dédiées est d’éviter le « voisinage bruyant » d’un mutualisé d’entrée de gamme, où l’activité d’autres sites peut ralentir le vôtre. Le premier chiffre à surveiller ici est le temps de réponse du serveur : il conditionne le moment où le navigateur commence à recevoir la page, donc directement le LCP. Dans le test présenté, l’outil relève un serveur qui répond rapidement.
Cloudflare en frontal : proxy, cache et distribution
Devant l’hébergement, Cloudflare agit comme proxy inverse. Concrètement, les requêtes des visiteurs passent d’abord par le réseau de Cloudflare, qui assure la terminaison du chiffrement HTTPS, un cache en périphérie et la distribution du contenu au plus près du visiteur. Cette couche réduit la latence pour les internautes éloignés et absorbe une partie de la charge avant qu’elle n’atteigne le serveur d’origine. Sur mon site, Cloudflare est utilisé pour ce rôle de proxy et de cache frontal.
La couche WordPress : un socle sain avant toute optimisation
Le site tourne sous WordPress 7, sorti en avril 2026, avec le thème GeneratePress, réputé léger. Ce choix n’est pas anodin : aucune extension de cache ne rattrape un thème lourd ou une accumulation d’extensions superflues. Un socle propre, un thème sobre et un nombre d’extensions maîtrisé constituent le point de départ. L’optimisation vient ensuite, pour tirer le meilleur d’une base déjà saine, pas pour masquer ses défauts.
La couche cache et optimisation : WP Rocket réglé finement
Le cache et l’optimisation reposent sur WP Rocket, en version 3.22.0.3. L’extension n’agit pas par magie : ce sont les réglages qui font la différence. Voici les principaux, tels qu’ils sont configurés sur mon site.
Cache, préchargement des liens et polices hébergées localement
Les pages sont mises en cache et servies en version statique, y compris sur mobile et en HTTPS. Le préchargement est activé, et les liens sont préchargés au survol : la page suivante commence à se charger avant même le clic, ce qui rend la navigation quasi instantanée. Les polices sont hébergées localement et préchargées, et les polices Google sont optimisées. Résultat : aucune requête vers un serveur de polices tiers, et pas de décalage d’affichage du texte au chargement.
Minification et livraison optimisée du CSS
Le CSS est minifié, et le CSS inutilisé est supprimé page par page, avec une liste de sécurité qui préserve les sélecteurs critiques : en-tête, navigation, contenu principal, blocs de mise en page. La livraison du CSS est optimisée pour réduire la part de CSS bloquant le rendu. C’est un levier direct sur le LCP, car moins de ressources bloquantes signifie un affichage plus rapide du contenu principal.
Chargement différé et retardé du JavaScript, avec exclusions ciblées
Le JavaScript est minifié, différé, puis retardé jusqu’à la première interaction de l’utilisateur. Le fil d’exécution principal est ainsi libéré pendant le chargement, ce qui fait chuter le Total Blocking Time. Ce réglage puissant demande des garde-fous : certains scripts sont explicitement exclus du différé ou du retard pour ne pas casser des fonctionnalités sensibles, comme la mesure d’audience, les formulaires ou la gestion du consentement. C’est cet équilibrage, script par script, qui distingue une configuration robuste d’un réglage agressif qui casse des pages.
Lazy-loading des images et iframes, dimensions d’images ajoutées
Les images, les iframes et les vidéos YouTube sont chargées de façon différée : seules les ressources visibles à l’écran sont téléchargées d’emblée, le reste se charge à mesure que l’on fait défiler la page. En parallèle, les dimensions manquantes des images sont ajoutées automatiquement. Cette précaution réserve l’espace de chaque image avant son chargement et évite les décalages de mise en page : c’est l’une des raisons pour lesquelles le CLS reste à 0 sur mon site.
Nettoyage de base de données et contrôle du Heartbeat
Un nettoyage de la base de données est programmé chaque semaine : révisions d’articles, brouillons automatiques, contenus en corbeille, commentaires indésirables et données temporaires. Une base plus légère, ce sont des requêtes plus rapides. Enfin, l’API Heartbeat de WordPress, qui envoie des requêtes en arrière-plan, est ralentie pour réduire la charge serveur inutile. Ces réglages ne se voient pas dans un score, mais ils entretiennent la performance dans la durée.
La couche images : Imagify et les formats nouvelle génération
Les images sont traitées par Imagify, en version 2.2.9. L’extension compresse chaque image et sert des formats modernes comme le WebP et l’AVIF, plus légers que le JPEG ou le PNG à qualité visuelle équivalente. C’est un levier majeur : sur une page classique, les images sont souvent l’élément le plus lourd, et donc fréquemment le plus grand élément visible mesuré par le LCP. Alléger les images, c’est agir au cœur de l’indicateur de chargement.
Un site aussi lisible pour les agents IA : le score de navigation agentique
La capture fait apparaître une catégorie inhabituelle : « Navigation agentique », intégrée à Lighthouse en mai 2026. Elle évalue, par des contrôles déterministes, la capacité d’un site à être compris et manipulé par des agents IA : qualité de l’arborescence d’accessibilité, HTML sémantique, libellés des éléments interactifs, stabilité visuelle. Mon site y valide les trois contrôles sur trois. Cette catégorie ne produit pas encore de score pondéré de 0 à 100 : elle est pensée comme un signal d’observation d’un web encore émergent, pas comme un facteur de classement. L’enseignement reste concret : un site propre pour les agents est aussi un site lisible par les systèmes de recherche par IA, ce que je développe dans mon article sur les agents IA comme canal d’audience. Webperformance et GEO se rejoignent ici sur les mêmes fondations, le HTML sémantique et l’accessibilité.
Ce que cette configuration apporte, et ses limites
Cette configuration apporte trois bénéfices vérifiables : un site qui répond aux critères techniques que Google attend, une expérience réelle plus fluide (chargement rapide, pas de décalage) et une meilleure lisibilité par les agents. Elle a aussi des limites qu’il serait malhonnête de taire. De bons Core Web Vitals sont un signal parmi beaucoup d’autres : Google indique clairement que de bonnes métriques ne sont pas synonymes de bon classement, et qu’un contenu pertinent peut se classer malgré une expérience décevante. La performance ne remplace ni la qualité du contenu, ni l’autorité du site. Enfin, une mesure de laboratoire n’est pas une mesure de terrain : seul le suivi des Core Web Vitals sur données réelles, dans la Google Search Console, confirme l’expérience réellement vécue par vos visiteurs. Cette configuration est le fruit d’un travail d’arbitrage accumulé au fil de 20 ans de pratique depuis 2004, pas d’une recette universelle à appliquer telle quelle.
Comment auditer et améliorer la performance de votre site
Vous pouvez engager cette démarche sur votre propre site, dans cet ordre.
- Mesurer l’existant avec PageSpeed Insights, en laboratoire et en terrain, et suivre les Core Web Vitals sur données réelles dans la Google Search Console.
- Commencer par la fondation : le temps de réponse du serveur, donc la qualité de l’hébergement, puis la mise en place d’un proxy et d’un cache frontal.
- Assainir le socle : thème léger, nombre d’extensions maîtrisé, base de données propre.
- Régler le cache finement : cache de page, suppression du CSS inutilisé, différé et retard du JavaScript avec exclusions, polices en local, lazy-loading, dimensions d’images.
- Traiter les images : compression et formats modernes comme le WebP et l’AVIF.
- Remesurer après chaque changement, sur mobile et sur ordinateur, puis surveiller la tendance dans le temps.
La performance web n’est qu’un des chantiers techniques d’un site ; j’en aborde d’autres, comme le HTTPS et le balisage, dans mon article sur les cinq erreurs SEO les plus fréquentes sur les sites TPE/PME.
Si vous voulez un regard extérieur sur la performance technique de votre site, je réalise ce type de diagnostic à distance, dans le cadre de mes prestations SEO. Écrivez-moi à contact@patrickligeron.fr, passez par la page de contact ou réservez un créneau d’échange. Si une prestation est pertinente, je vous adresse une proposition sous 5 jours ouvrés.
Questions fréquentes
Ces scores sont-ils les mêmes sur mobile et sur ordinateur ?
Non. PageSpeed Insights teste séparément les deux versions. Les résultats présentés ici sont ceux de la version mobile, historiquement la plus exigeante, car elle simule un appareil et un réseau contraints. La version ordinateur, testée dans des conditions plus favorables, donne généralement des valeurs au moins équivalentes. Il faut donc toujours vérifier les deux, d’autant que Google indexe en priorité la version mobile.
Un hébergement mutualisé peut-il atteindre ces résultats ?
Oui, à condition de disposer de ressources garanties ou dédiées et d’un temps de réponse serveur maîtrisé. Le type d’offre compte moins que la régularité du temps de réponse et l’absence de voisinage bruyant. Un mutualisé d’entrée de gamme surchargé plafonnera malgré de bons réglages logiciels, car la fondation reste le maillon limitant.
Sources
Google Search Central – Comprendre les Core Web Vitals et les résultats de recherche Google – https://developers.google.com/search/docs/appearance/core-web-vitals?hl=fr
web.dev – Web Vitals – https://web.dev/articles/vitals
Google Search Central – Comprendre l’expérience sur la page dans Google – https://developers.google.com/search/docs/appearance/page-experience?hl=fr
Chrome for Developers – Lighthouse agentic browsing scoring – https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring
