Comment accélérer un site web grâce aux Core Web Vitals et aux données réelles

Les sites web sont souvent accélérés dans le mauvais ordre : quelqu’un installe un plugin d’optimisation, active toutes les options, puis cherche pourquoi le formulaire ne fonctionne plus. Le bon ordre consiste à mesurer, formuler une hypothèse, effectuer une modification, vérifier les fonctionnalités, puis mesurer à nouveau.

Dans une version précédente, j’avais également décrit des approches que je ne recommande plus, comme l’hébergement local des scripts d’autres personnes ou le déploiement généralisé d’AMP et de PWA. Elles apportaient des améliorations partielles en laboratoire, mais augmentaient les risques liés au code obsolète, aux mises à jour défaillantes et à une maintenance plus complexe. Un site web moderne doit être rapide dans sa version principale.

Que mesurer aujourd’hui

Pour les Core Web Vitals, Google utilise trois indicateurs stables :

• LCP: chargement du contenu principal ; une bonne valeur est inférieure ou égale à 2.5 secondes.
• INP: réponse aux interactions ; une bonne valeur est inférieure à 200 millisecondes.
• CLS: déplacements inattendus de la mise en page ; une bonne valeur est inférieure ou égale à 0.1.

Les seuils s’appliquent au 75e percentile et sont résumés dans la présentation officielle Core Web Vitals pour la recherche Google. Les résultats issus de visiteurs réels dans la Search Console ou CrUX sont prioritaires par rapport à un seul test en laboratoire effectué sur mon ordinateur portable.

Les outils de laboratoire restent importants : ils montrent la cascade réseau, le thread principal, le code inutilisé et les réparations concrètes possibles. Les données réelles indiquent qu’un problème existe ; le laboratoire aide à expliquer pourquoi.

Commencez par définir l’étendue du problème

1. Comparez les appareils mobiles et les ordinateurs de bureau.
2. Séparez les modèles : page d’accueil, article, service, page de listing, formulaire et boutique en ligne.
3. Vérifiez les pays, les appareils et les sources de trafic rapides et lents.
4. Trouvez les groupes d’URL dont les données réelles sont mauvaises.
5. Enregistrez une trace de laboratoire reproductible pour une page représentative.

Une page d’accueil rapide ne signifie pas que le site web est rapide. Une visite lente sur un ancien téléphone ne signifie pas qu’il faut réécrire tout le système.

Les interventions ayant le plus souvent d’impact

1. Serveur et HTML

Mesurez le délai avant le premier octet et décomposez-le entre DNS, connexion, attente du serveur et redirections. Les longues attentes peuvent venir de l’hébergement, de la base de données, d’une page non mise en cache, d’une API lente ou de chaînes de redirections. Activez un cache de pages adapté pour les contenus publics et un cache d’objets lorsque cela est pertinent. Excluez correctement du cache les utilisateurs connectés, les paniers et la personnalisation.

2. Image principale

Le LCP correspond souvent à l’image principale. Diffusez une taille adaptée à son affichage, utilisez srcset, la compression et les formats modernes WebP ou AVIF avec un fallback pertinent. N’appliquez pas le chargement différé à l’image principale ; appliquez-le aux images situées sous le premier écran. Définissez la largeur et la hauteur des images afin que le navigateur réserve l’espace nécessaire et que le CLS reste faible.

3. CSS et polices

Supprimez prudemment les styles inutilisés et gardez le CSS critique compact. Limitez les polices aux graisses et jeux de caractères nécessaires, mettez les fichiers locaux en cache pendant longtemps et préchargez uniquement une police réellement nécessaire dès le début. Précharger dix polices ne fait que créer une file d’attente supplémentaire.

4. JavaScript et interactions

Fractionnez les bundles volumineux, différez le code non critique et ne chargez les services tiers que lorsque cela est nécessaire et autorisé par le consentement. async et defer ne sont pas magiques ; testez l’ordre et les dépendances des scripts. Réduisez les longues tâches du thread principal et ne faites pas attendre un clic pour l’analytique.

5. Services tiers

Les chats, heatmaps, pixels publicitaires, vidéos et outils A/B ajoutent des requêtes réseau et sollicitent le processeur. Chaque script doit avoir un responsable et une raison métier. Ne le chargez pas de manière synchrone dans l’en-tête simplement parce que le guide d’installation est plus court. L’analytique peut être gérée via Google Tag Manager, mais le conteneur lui-même ne peut pas sauver les performances.

WordPress : moins de couches, plus de contrôle

La documentation WordPress recommande d’aborder les performances par l’hébergement, la quantité et la qualité des plugins, les images, le cache et un réseau de diffusion. Consultez sa présentation de l’optimisation ainsi que son explication distincte du cache.

• Mettez d’abord à jour WordPress, PHP, le thème et les plugins sur un environnement de préproduction.
• Supprimez les plugins inutilisés ainsi que les outils de cache ou de minification qui se chevauchent.
• Analysez les requêtes de base de données et les appels externes lents.
• Planifiez la maintenance de la base de données, mais ne supprimez pas aveuglément les révisions ou les métadonnées.
• Après chaque optimisation, testez les formulaires, la recherche, la connexion et le parcours d’achat.

Je parle de la sélection pertinente des extensions dans les meilleurs plugins WordPress.

Ce qu’il ne faut pas faire

• Ne téléchargez pas les scripts d’analytique ou de publicité d’autres personnes sur votre serveur uniquement pour améliorer un score ; vous pourriez perdre les mises à jour de sécurité et de fonctionnement.
• Ne définissez pas un cache d’un an pour un fichier qui change sans versionner son nom.
• Ne supprimez pas de CSS ou de JavaScript à partir d’un rapport automatisé sans tester chaque modèle.
• Ne jugez pas la réussite uniquement avec Lighthouse. Google indique explicitement que de bons Core Web Vitals ne garantissent à eux seuls ni un classement élevé ni une excellente expérience utilisateur.
• N’accélérez pas un site web en masquant un contenu ou une fonctionnalité dont le client a besoin.

Un plan sur quatre semaines

1. Semaine 1 : référence des données réelles, mesures en laboratoire et liste des modèles.
2. Semaine 2 : serveur, cache, redirections et ressources LCP les plus volumineuses.
3. Semaine 3 : images, polices, CSS, JavaScript et services tiers.
4. Semaine 4 : test de régression, nouvelles mesures, surveillance et documentation.

Pour chaque modification, notez la date, l’URL, l’indicateur avant et après, l’impact fonctionnel et l’option de retour en arrière. Suivez également le taux de conversion, le remplissage des formulaires et les erreurs ; une page plus rapide qui vend moins n’est pas une optimisation terminée.

Commencez par vérifier les fondations techniques et l’analytique du site web dans un audit technique et GA4. Si vous devez prioriser les réparations selon leur impact et leur coût, contactez-moi via la page contact.