Votre site met du temps à afficher son contenu ou répond mal sur téléphone ? Pour améliorer sa vitesse, commencez par mesurer une page précise, identifiez une cause et vérifiez le résultat après chaque changement. Accumuler des extensions ou viser un score de 100 sans diagnostic peut ajouter des problèmes au lieu de les résoudre.
Ce guide s’adresse aux propriétaires d’un site, notamment WordPress, qui veulent agir progressivement. Vous apprendrez à lire PageSpeed Insights, alléger les images, comprendre le cache et contrôler que les améliorations préservent les formulaires et les autres fonctions.
1. Définir les pages et les actions à améliorer
Un site rapide doit surtout permettre à vos visiteurs de lire, de naviguer et de vous contacter sans difficulté. Pour commencer, retenez trois pages : l’accueil, une prestation ou un produit important et le contact. Une seule page testée ne représente pas nécessairement tout le site.
Avant une intervention technique, vérifiez la sauvegarde et votre possibilité de revenir à l’état précédent. Travaillez sur une copie de test pour les changements importants. Notez l’adresse de la page, la date, le type d’appareil et les résultats de départ.
2. Tester une page avec PageSpeed Insights
- Ouvrez PageSpeed Insights.
- Collez l’URL complète de la page publique, puis cliquez sur Analyser.
- Commencez par l’onglet Mobile, puis regardez Bureau.
- Enregistrez le lien du rapport et les valeurs utiles.
- Refaites plusieurs tests dans des conditions comparables : les mesures de laboratoire peuvent varier.
Le haut du rapport décrit l’expérience de vrais utilisateurs lorsque les données sont suffisantes. La partie de diagnostic utilise un test de laboratoire. Ces deux lectures peuvent différer ; un site récent ou peu fréquenté peut afficher « Aucune donnée » sans que le test technique ait échoué. Vérifiez aussi si les données concernent cette URL ou l’ensemble de l’origine. Comprendre les données PageSpeed Insights.
Dans ce rapport de démonstration, le LCP de laboratoire est de 3,7 secondes et le CLS de 0,024. Cela donne des pistes à examiner, sans établir l’expérience de tous les visiteurs. Le rapport propose notamment de travailler l’affichage des images et les ressources bloquant le rendu. Ses économies estimées ne sont pas des gains déjà réalisés et ne s’additionnent pas mécaniquement.
3. Comprendre LCP, INP et CLS
Les Core Web Vitals décrivent trois aspects différents de l’expérience. Les seuils ci-dessous correspondent aux repères « bons » des mesures terrain, évaluées au 75e percentile des visites : ils ne sont pas des objectifs de score sur 100.
- LCP, au plus 2,5 secondes : le temps d’apparition du plus grand élément de contenu visible, souvent une image ou un bloc de texte.
- INP, au plus 200 millisecondes : la réactivité de la page aux interactions. Un bouton qui semble ne pas répondre mérite une investigation.
- CLS, au plus 0,1 : la stabilité de la mise en page. Une image qui arrive tard et déplace un bouton peut créer un décalage.
INP a remplacé FID. Le TBT affiché dans un test de chargement Lighthouse n’est pas l’INP de vos visiteurs ; il aide au diagnostic mais ne s’y substitue pas. Définitions des Core Web Vitals.
4. Alléger les images sans dégrader l’information
Commencez par les grandes photos et les images présentes sur les pages d’entrée. Une photo de téléphone en très haute définition n’a pas toujours besoin d’être envoyée intégralement au navigateur pour être affichée dans une petite carte.
- Conservez l’original hors du site pour pouvoir retravailler l’image.
- Choisissez des dimensions adaptées à l’affichage, en tenant compte des écrans à haute densité ; évitez une largeur arbitraire unique pour toutes les images.
- Exportez une version compressée dans un format adapté : WebP ou AVIF peuvent convenir aux photos, selon la prise en charge de votre installation.
- Comparez visuellement le texte, les détails et les couleurs avant de remplacer le fichier.
- Vérifiez les versions réellement servies sur mobile. WordPress peut produire plusieurs tailles ; choisissez la taille pertinente dans l’éditeur.
Il n’existe pas de poids idéal universel pour chaque image. Cherchez la plus petite version qui conserve la qualité nécessaire à son usage. Une capture contenant du texte peut demander une compression différente d’une photo. Repères sur la performance des images.
Attention à l’image visible dès l’arrivée
Le chargement différé est utile pour des images situées plus bas dans la page. Ne l’appliquez pas systématiquement à l’image principale déjà visible à l’ouverture, notamment lorsqu’elle est l’élément LCP : cela peut retarder son apparition. Le navigateur doit également connaître les dimensions des images afin de réserver leur place. Conseils sur le chargement différé.
5. Comprendre et vérifier le cache existant
Le cache conserve des éléments déjà préparés pour éviter de refaire tout le travail à chaque visite. Le cache de page peut servir une version préparée du HTML ; le cache du navigateur permet de réutiliser certaines ressources lors de visites suivantes. Ce ne sont pas exactement les mêmes mécanismes.
Sur WordPress, vérifiez d’abord ce que fournissent votre hébergement et vos outils actuels. Ne superposez pas plusieurs systèmes de cache de page sans comprendre leurs interactions. Après un changement visible, purgez le cache concerné puis testez le site en étant déconnecté.
Les espaces personnels, paniers et commandes demandent des règles particulières : une page personnalisée ne doit pas être servie à la mauvaise personne. Faites confirmer les exclusions par votre solution e-commerce ou votre intervenant technique. Documentation WordPress sur l’optimisation.
Résultat attendu : le site public affiche les bonnes informations et les fonctions personnalisées restent correctes. Un site rapide qui affiche un panier erroné n’est pas une amélioration.
6. Réduire ce qui retarde l’affichage et les interactions
Inventoriez les éléments réellement chargés : vidéo automatique, carte, chat, boutons sociaux, polices et animations. Demandez-vous lesquels sont utiles dès l’ouverture. Un service rarement utilisé peut être chargé à la demande plutôt que sur toutes les pages.
Les outils signalent parfois du CSS ou du JavaScript inutilisé, ou des ressources bloquant le rendu. Cela ne signifie pas qu’il faut supprimer tous ces fichiers. Certains servent au menu, au consentement ou au formulaire. Testez les fonctions avant et après tout report de script, minification ou suppression.
Ne regroupez pas automatiquement tous les fichiers en un seul : le résultat dépend du site et de la façon dont ils sont chargés. Le nombre d’extensions est lui aussi un indice incomplet ; leur travail réel compte davantage qu’un quota arbitraire.
Si le contenu principal apparaît tard, recherchez l’élément LCP et ce qui retarde son chargement ou son affichage. Si les clics répondent mal, l’analyse porte aussi sur le travail exécuté par le navigateur pendant les interactions. Diagnostiquer le LCP · Diagnostiquer l’INP.
7. Stabiliser la page et examiner le serveur si nécessaire
Réservez la place des images, vidéos et contenus intégrés. Vérifiez les blocs qui apparaissent après chargement, les changements de police et les bandeaux : ils ne devraient pas déplacer brutalement ce que le visiteur essaie de lire ou de cliquer. Réduire les décalages de mise en page.
Si l’attente commence avant même l’arrivée du HTML, le diagnostic peut concerner le serveur, les redirections, le cache ou un traitement applicatif. Transmettez les rapports à votre hébergeur ou développeur. Changer de formule, activer un CDN ou ajouter un cache objet n’est pas une réponse automatique à un mauvais score.
Un CDN peut aider certains publics géographiquement éloignés ; il n’enlève pas un script inutile ni une photo surdimensionnée. Choisissez une intervention parce qu’elle répond à un problème observé.
8. Comparer avant et après sans se tromper
Utilisez un journal simple. Pour chaque modification, notez : URL, date, mobile ou bureau, mesure avant, changement effectué, mesure après et test fonctionnel. Conservez les liens de rapports pour pouvoir comprendre les différences.
Exemple de ligne à compléter sur votre propre site : « Page prestation — image principale redimensionnée — LCP avant : … — LCP après : … — menu et formulaire vérifiés : oui/non ». Ce modèle ne prétend pas qu’un gain a déjà été mesuré.
- Rejouez plusieurs tests avec le même outil et le même profil.
- Regardez la tendance et les diagnostics, pas uniquement le meilleur score obtenu.
- Ouvrez le site sur un vrai téléphone et testez navigation, formulaire et, le cas échéant, panier.
- Surveillez ensuite les données terrain lorsqu’elles deviennent disponibles ; une période glissante ne reflète pas immédiatement une correction du jour.
Questions fréquentes
Faut-il absolument atteindre 100 ?
Non. Le score de laboratoire est un indicateur de diagnostic. Priorisez la lisibilité, la réactivité et les actions des visiteurs. Un 100 SEO de Lighthouse n’est pas une promesse de classement Google.
Puis-je tout régler depuis mon hébergement ?
Non. Certaines causes viennent du contenu ou du thème ; d’autres du serveur. Envoyez au support une URL, le rapport, l’appareil testé et les changements déjà tentés. Cela aide à orienter l’intervention.
À quelle fréquence refaire les contrôles ?
Après une modification importante, puis périodiquement selon l’évolution du site. Vérifiez notamment après l’ajout d’un service tiers, d’un nouveau modèle de page ou de nombreuses photos.
Pour replacer la vitesse parmi les autres priorités, suivez notre méthode d’audit SEO. Si vous démarrez, retrouvez aussi le guide pour créer votre premier site. Pour un diagnostic accompagné, contactez iMasterWeb.
Autres références à consulter selon votre besoin
Ces références complètent les ressources du guide. Certaines sont historiques : vérifiez le service, la destination et les conditions avant de les utiliser. Aucun tarif ni résultat n’est garanti.