Performance d'un site web

La performance d'une page isolée se diagnostique en quelques minutes, et le détail des mesures, des seuils et des corrections tient sur la page vitesse d'affichage et sur celle des Core Web Vitals. Piloter la performance d'un site de cinq cents pages est un autre exercice. La question n'est plus « comment accélérer cette page » mais « par où commencer, pour combien de travail, et comment éviter que tout se dégrade six mois plus tard ».

Un gabarit lent fait quatre cents pages lentes

Sur un site de contenu ou une boutique, les pages ne sont pas indépendantes. Toutes les fiches produit sortent du même modèle, tous les articles partagent le même en-tête, la même barre latérale et les mêmes scripts. Quand une fiche produit charge une image de 900 kilo-octets parce que le thème ne redimensionne rien, les quatre cents autres font pareil.

Cette dépendance est une bonne nouvelle. Une correction appliquée au modèle d'article corrige d'un coup tout ce qui en dérive, alors qu'une correction page par page ne finit jamais. Google raisonne d'ailleurs de la même façon dans la Search Console, où les URL sont rassemblées par groupes de pages similaires plutôt que listées une à une.

Le premier travail consiste donc à inventorier les gabarits, pas les URL. Sur un site classique, on en compte rarement plus de huit : l'accueil, les pages de service, les catégories, les articles, les fiches produit, le panier, les pages de contenu légal. Un exemplaire de chacun, testé sérieusement, donne l'image complète du site.

Où lire les données de son propre site

Trois sources répondent à des questions différentes, et les confondre fait perdre beaucoup de temps.

Quand une URL reçoit trop peu de trafic pour disposer de ses propres données, PageSpeed Insights bascule sur les données de l'origine, donc la moyenne de tout le domaine. La nuance compte. Le rapport affiché ne décrit alors pas la page testée mais le site dans son ensemble, et corriger cette page ne fera pas bouger le chiffre.

Pourquoi une correction met un mois à se voir

Les données de terrain sont calculées sur les 28 derniers jours. Le jour où vous mettez en ligne une correction, la fenêtre contient encore 27 jours de l'ancienne version. Le chiffre bouge donc lentement, et un groupe d'URL ne change d'état qu'une fois la bascule consommée.

Cette inertie explique une bonne partie des malentendus entre un consultant et une équipe technique. Le développeur a livré, le test de laboratoire est au vert, et la Search Console affiche toujours du rouge trois semaines plus tard. Rien n'est cassé, la fenêtre n'a simplement pas fini de tourner. Je préviens toujours de ce délai avant la mise en ligne, faute de quoi la correction est jugée inefficace avant d'avoir eu le temps d'exister.

Une régression met tout autant de temps à apparaître, et c'est la partie désagréable du même mécanisme. Un script ajouté en janvier se voit en février, quand plus personne ne fait le lien.

Choisir les gabarits qui méritent le travail

Toutes les pages lentes ne se valent pas. Un gabarit d'archives mensuelles en rouge, sans trafic organique ni conversion, ne justifie aucune journée de développement. Une fiche produit en rouge qui porte le chiffre d'affaires en justifie plusieurs.

Le croisement qui tranche tient en trois colonnes, construites en une heure à partir d'un export de la Search Console et d'un crawl.

1. Classer les URL par gabarit

   Une règle sur l'adresse suffit le plus souvent, un préfixe ou un segment commun. Le crawl fournit la liste complète, et la colonne du gabarit se remplit par filtre.

2. Ajouter le trafic et la valeur de chaque gabarit

   Clics organiques sur les douze derniers mois depuis la Search Console, et conversions depuis l'outil d'analyse. Le total par gabarit, pas par URL.

3. Reporter l'état de terrain et le coût estimé

   Une ligne par gabarit avec son état, la mesure qui décroche et le temps de développement estimé. L'ordre de traitement se lit alors tout seul.

Ce tableau sert aussi à dire non. Un chantier de performance qui commence par « on refait tout le thème » coûte cher et se justifie rarement, quand trois corrections ciblées sur deux gabarits font passer 80 % du trafic dans le vert.

Écrire un budget de performance

Un budget de performance fixe à l'avance ce qu'un gabarit a le droit de peser. Il s'écrit en une dizaine de lignes et vaut surtout au moment d'une refonte, où il devient une clause du cahier des charges plutôt qu'une réclamation après livraison.

• Temps de réponse du serveur sous 0,8 seconde sur une page non mise en cache
• Poids total de la page d'accueil et d'un article sous une valeur fixée, images comprises
• Nombre de fichiers JavaScript chargés au premier rendu, et liste nominative des scripts tiers autorisés
• Les trois seuils Core Web Vitals atteints sur mobile, mesurés sur un exemplaire de chaque gabarit avant la recette
• Dimensions déclarées sur toutes les images et tous les cadres intégrés

La liste nominative des scripts tiers est la ligne la plus utile, et celle qu'on oublie le plus souvent. C'est elle qui permet de refuser proprement le quatrième outil de suivi installé dans l'année.

Le cas WordPress

La plupart des sites lents que l'on me montre tournent sous WordPress, et presque toujours pour les mêmes raisons. Les extensions chargent leurs fichiers sur toutes les pages, y compris celles qui n'utilisent pas leur fonctionnalité. Les thèmes à constructeur de pages produisent un CSS et un JavaScript prévus pour tous les usages possibles. Les images partent en ligne à la taille où elles ont été téléversées.

• Un cache de page complète, fourni par l'hébergeur ou par une extension dédiée, règle à lui seul le temps de réponse serveur sur la grande majorité des sites.
• La compression des images au téléversement évite d'avoir à reprendre la médiathèque plus tard. Installée après coup, elle demande un retraitement de l'existant.
• La suppression des extensions inutilisées, plutôt que leur désactivation, parce qu'une extension désactivée qui reste installée continue d'occuper la base et d'exposer une surface de mise à jour.
• Le retrait des fonctionnalités dupliquées, comme deux extensions de formulaire ou deux outils de statistiques, qui chargent chacun leur propre JavaScript.

Les extensions d'optimisation demandent une précaution supplémentaire. Leurs options de concaténation et de report du JavaScript cassent régulièrement un menu, un formulaire ou un carrousel, sans erreur visible dans l'administration. Chaque option activée se vérifie sur un gabarit de chaque type, y compris le tunnel de commande, avant d'être laissée en production.

Tenir la performance dans la durée

Un site optimisé se dégrade tout seul. Une vidéo intégrée dans un article, un pixel publicitaire ajouté pour une campagne, une mise à jour de thème, un plugin installé pour un besoin ponctuel et jamais retiré, et le gabarit ressort du vert six mois plus tard.

Un relevé mensuel de trois pages, une par gabarit important, suffit à repérer la dérive avant qu'elle ne devienne un chantier. Sur les sites où plusieurs personnes peuvent publier ou installer, il vaut la peine d'ajouter une vérification automatique à chaque mise en production, avec un outil d'intégration continue qui fait échouer la livraison quand le budget est dépassé.

Dans un audit, je regarde toujours l'évolution sur douze mois plutôt que l'état du jour. Un site stable au orange se traite calmement. Un site qui était au vert il y a trois mois pose une question différente, et la réponse se trouve presque toujours dans l'historique des mises en ligne.

Questions fréquentes

Comment savoir quelles pages d'un site sont lentes ?

Le rapport Core Web Vitals de la Search Console regroupe les URL du site par état et par type de page, et donne des exemples pour chaque groupe. Un site sans assez de trafic pour figurer dans les données de Chrome n'y apparaît pas, et il faut alors installer une mesure sur le site lui-même avec la bibliothèque web-vitals, ou tester manuellement un exemplaire de chaque gabarit.

Pourquoi mes corrections n'apparaissent pas dans la Search Console ?

Les données de terrain sont calculées sur une fenêtre glissante de 28 jours. Une correction mise en ligne aujourd'hui commence à peser dès le lendemain, mais elle n'est complètement reflétée qu'au bout de quatre semaines, et l'état d'un groupe d'URL ne change qu'une fois ce basculement acquis. Pour vérifier qu'une correction fonctionne le jour même, il faut une mesure de laboratoire ou une mesure installée sur le site.

Faut-il corriger toutes les pages en rouge ?

Non, et la question se pose rarement en ces termes puisque les pages en rouge partagent presque toujours un gabarit. Commencez par le gabarit qui porte le plus de trafic et le plus de conversions, corrigez-le une fois, et des centaines d'URL passent ensemble. Une page ancienne sans trafic ni lien ne justifie pas une journée de développement.

Un site rapide peut-il redevenir lent sans qu'on y touche ?

Oui, et c'est le cas le plus fréquent. Un script de suivi ajouté par le service marketing, une extension installée pour un besoin ponctuel, une vidéo intégrée dans un article ou une mise à jour de thème suffisent à faire ressortir un gabarit du vert. C'est la raison pour laquelle une mesure mensuelle vaut mieux qu'un grand chantier tous les deux ans.