Nous avons pris un cas réel : un site vitrine WordPress de 9 pages, hébergé sur une mutualisée d’entrée de gamme, thème premium acheté sur une marketplace, 27 plugins actifs. Score PageSpeed Insights mobile de départ : 31/100. LCP à 6,4 s, INP à 310 ms, CLS à 0,24. Autrement dit : un site que Google considère comme lent et que la moitié des visiteurs mobiles abandonne avant l’affichage du premier titre.
Nous avons appliqué les optimisations une par une, en remesurant après chacune. L’objectif de cet article n’est pas de vous donner une liste de 40 bonnes pratiques théoriques, mais de vous montrer quelles actions font réellement gagner des secondes, et lesquelles ne servent presque à rien sur un site vitrine classique. Résultat final : LCP à 1,6 s, score mobile 92/100.
Avant de toucher à quoi que ce soit : mesurer correctement
La plus grosse erreur consiste à optimiser à l’aveugle. Trois outils suffisent, et ils ne disent pas la même chose :
- PageSpeed Insights : donne les données de laboratoire (test simulé) et, si votre site a assez de trafic, les données terrain du rapport d’expérience utilisateur Chrome. Ce sont ces données terrain qui comptent pour Google.
- WebPageTest : pour comprendre l’ordre de chargement des ressources via la cascade (waterfall). C’est là qu’on repère les scripts bloquants et les requêtes en série.
- La console Chrome (onglet Performances + Lighthouse) : pour identifier précisément quel élément constitue votre LCP.
Testez toujours en mobile d’abord, avec un throttling 4G lent. Un site qui charge en 1,2 s sur votre fibre au bureau peut mettre 7 s sur un smartphone milieu de gamme en 4G dans un train.
Les trois métriques Core Web Vitals à connaître
| Métrique | Ce qu’elle mesure | Seuil « bon » |
|---|---|---|
| LCP (Largest Contentful Paint) | Temps d’affichage du plus gros élément visible (souvent l’image de bannière) | < 2,5 s |
| INP (Interaction to Next Paint) | Réactivité de la page quand on clique ou tape | < 200 ms |
| CLS (Cumulative Layout Shift) | Stabilité visuelle : les éléments qui sautent pendant le chargement | < 0,1 |
Notez bien : le score sur 100 de PageSpeed Insights n’est pas un critère de classement Google. Ce sont les Core Web Vitals mesurés sur vos vrais visiteurs qui pèsent. Un score de 78 avec de bons Core Web Vitals vaut mieux qu’un score de 95 obtenu par des astuces qui dégradent l’expérience réelle.
Les 12 actions, classées par rentabilité
Voici le tableau de synthèse de nos mesures sur le site test. Le gain indiqué est le gain sur le LCP mobile, cumulatif dans l’ordre d’application.
| # | Action | Gain LCP | Effort technique |
|---|---|---|---|
| 1 | Compression et conversion des images en WebP | -1,7 s | Faible |
| 2 | Suppression / report des scripts tiers | -1,1 s | Faible |
| 3 | Mise en cache de pages (cache serveur) | -0,9 s | Faible |
| 4 | Changement d’hébergement (mutualisé bas de gamme vers offre performante) | -0,8 s | Moyen |
| 5 | Lazy loading correctement configuré | -0,5 s | Faible |
| 6 | Nettoyage des plugins | -0,4 s | Moyen |
| 7 | Chargement optimisé des polices | -0,3 s | Faible |
| 8 | Élimination du CSS/JS bloquant | -0,3 s | Élevé |
| 9 | Compression Brotli / GZIP | -0,2 s | Faible |
| 10 | CDN | -0,2 s | Faible |
| 11 | Minification et regroupement | -0,1 s | Faible |
| 12 | Réservation des espaces (impact CLS) | 0 s (CLS 0,24 → 0,03) | Faible |
La lecture est sans ambiguïté : les trois premières actions représentent à elles seules 3,7 secondes de gain, soit environ 77 % du total, pour un effort technique faible. C’est là qu’il faut commencer.
1. Compresser et convertir les images en WebP
Gain mesuré : -1,7 s sur le LCP. Le meilleur rapport effort/résultat, de très loin.
Sur notre site test, la page d’accueil pesait 4,8 Mo. À elles seules, les images représentaient 4,1 Mo. L’image de bannière était un JPEG de 2 400 px de large, 1,3 Mo, affiché dans un conteneur de 1 200 px maximum.
Ce qu’il faut faire concrètement
- Redimensionner avant d’envoyer. Aucune image n’a besoin de dépasser 2 000 px de large sur un site vitrine. Pour une vignette d’article, 800 px suffisent.
- Convertir en WebP. Le format est supporté par tous les navigateurs modernes et fait gagner 25 à 40 % de poids à qualité visuelle équivalente. L’AVIF va encore plus loin (jusqu’à 50 %) mais son encodage est plus lent et le support un peu moins universel.
- Servir des images responsives. Les attributs
srcsetetsizespermettent au navigateur de télécharger la version adaptée à l’écran. WordPress le fait nativement si vos tailles d’images sont bien configurées. - Compresser à 75-82 % de qualité. En dessous de 70 %, les artefacts deviennent visibles sur les dégradés. Au-dessus de 85 %, vous payez du poids pour rien.
Après conversion, la page d’accueil est passée de 4,8 Mo à 1,1 Mo. L’image LCP est descendue de 1,3 Mo à 168 Ko.
Sur WordPress, des extensions comme Imagify, ShortPixel ou Converter for Media automatisent la conversion et la livraison conditionnelle. Si vous préférez éviter un plugin de plus, faites la conversion en amont avec Squoosh ou un script cwebp.
Le piège à éviter
N’appliquez jamais de lazy loading à votre image LCP (voir point 5). Nous avons vu des sites perdre 800 ms uniquement parce que l’image de bannière était en loading="lazy".
2. Réduire et différer les scripts tiers
Gain mesuré : -1,1 s sur le LCP, et -140 ms sur l’INP.
C’est le poste le plus souvent sous-estimé. Sur notre site test, l’audit a révélé 11 domaines tiers chargés au démarrage :
- Google Tag Manager (qui chargeait lui-même 4 balises)
- Google Analytics 4
- Meta Pixel
- Un widget de chat en ligne (312 Ko de JavaScript, pour un site qui recevait 3 conversations par mois)
- Un carrousel d’avis clients chargé depuis un service externe
- Google Fonts en direct
- Une carte Google Maps intégrée sur la page d’accueil
- Deux polices d’icônes différentes
La méthode en trois questions
Pour chaque script tiers, posez-vous ces questions dans l’ordre :
- Est-il indispensable ? Le chat à 3 conversations par mois a été remplacé par un bouton d’appel et un lien WhatsApp. 312 Ko économisés, zéro perte commerciale.
- Peut-il être différé ? Le pixel publicitaire, le chat, le widget d’avis n’ont aucune raison de se charger avant l’interaction utilisateur. Un chargement au premier scroll ou après 3 secondes ne change rien à leur utilité.
- Peut-il être remplacé par une version locale ou plus légère ? Google Maps a été remplacé par une image statique cliquable qui charge la carte au clic. Google Fonts a été hébergé en local (bonus : conformité RGPD).
Résultat : de 11 domaines tiers à 3, et de 1,4 Mo de JavaScript à 340 Ko.
Cas particulier : le consentement cookies
Beaucoup de bandeaux de consentement (CMP) sont des scripts bloquants de 100 à 200 Ko qui s’exécutent avant tout le reste. Vérifiez que le vôtre se charge en mode asynchrone et qu’il n’introduit pas de décalage de mise en page. C’est une cause fréquente de mauvais CLS.
3. Mettre en place un cache de pages sérieux
Gain mesuré : -0,9 s sur le LCP, dont l’essentiel sur le TTFB (de 810 ms à 190 ms).
Sans cache, chaque visite d’une page WordPress déclenche l’exécution de PHP, plusieurs dizaines de requêtes MySQL, puis la génération du HTML. Avec un cache de pages, le serveur renvoie directement un fichier HTML statique déjà prêt.
Sur un site vitrine dont le contenu change une fois par mois, il n’y a aucune raison de régénérer les pages à chaque visite.
Les trois niveaux de cache à distinguer
- Cache de pages (page cache) : le plus efficace. WP Rocket, LiteSpeed Cache, WP Super Cache, ou le cache serveur intégré chez certains hébergeurs.
- Cache d’objets (object cache) : Redis ou Memcached, utile surtout sur les sites à requêtes complexes (e-commerce, gros catalogues). Impact quasi nul sur un site vitrine de 9 pages.
- Cache navigateur : via les en-têtes HTTP
Cache-Control. Ne change rien à la première visite, mais accélère fortement les visites suivantes. Réglez une durée longue (1 an) sur les ressources statiques versionnées.
Petit conseil de terrain : n’empilez pas plusieurs plugins de cache. Ils se marchent dessus et créent des bugs d’affichage difficiles à diagnostiquer. Un seul, bien configuré.
4. Choisir un hébergement à la hauteur
Gain mesuré : -0,8 s. Le TTFB est passé de 190 ms à 95 ms, et surtout la variabilité a disparu.
Ce point mérite une nuance importante. Avec le cache activé, l’écart d’hébergement se réduit fortement. Mais deux problèmes subsistent sur les offres mutualisées bas de gamme :
- La variabilité. Sur l’ancien hébergement, le TTFB oscillait entre 180 ms et 2 100 ms selon l’heure, parce que des centaines de sites se partageaient la même machine. C’est cette variabilité qui dégrade les Core Web Vitals mesurés sur le terrain, même si vos tests ponctuels semblent corrects.
- L’administration. Un back-office WordPress lent vous fait perdre du temps chaque semaine.
Ce qu’il faut vérifier avant de souscrire
- Version de PHP : 8.3 ou 8.4 minimum. Le passage de PHP 7.4 à 8.x apporte à lui seul 20 à 30 % de gain sur le temps d’exécution.
- HTTP/2 ou HTTP/3 activé.
- Serveur en France ou en Europe de l’Ouest si votre audience est française. Un serveur au Texas ajoute mécaniquement 100 à 150 ms de latence.
- Stockage NVMe et non disque mécanique.
- Compression Brotli disponible.
- Certificat SSL et HSTS inclus sans surcoût.
Budget réaliste pour un site vitrine professionnel : entre 10 et 30 € par mois. En dessous de 5 € par mois, vous achetez de la lenteur.
5. Configurer le lazy loading intelligemment
Gain mesuré : -0,5 s, mais attention aux effets de bord.
Le lazy loading consiste à ne charger les images et iframes qu’au moment où elles approchent de la zone visible. C’est natif depuis longtemps dans les navigateurs avec l’attribut loading="lazy", et WordPress l’applique automatiquement. Cette référence vaut la peine d’être gardée sous la main.
Le problème : appliqué sans discernement, il ralentit l’affichage initial.
Les règles à respecter
| Élément | Traitement recommandé |
|---|---|
| Image de bannière / élément LCP | loading="eager" + fetchpriority="high" + preload |
| Logo et images du header | Chargement immédiat, pas de lazy |
| Images sous la ligne de flottaison | loading="lazy" |
| Vidéos YouTube / Vimeo intégrées | Facade cliquable (miniature + chargement au clic) |
| Cartes, iframes tierces | Chargement au clic ou au scroll |
Le cas des vidéos intégrées mérite qu’on s’y attarde. Un simple embed YouTube ajoute environ 900 Ko et une dizaine de requêtes, même si le visiteur ne lance jamais la vidéo. Remplacer l’iframe par une miniature qui charge le lecteur au clic est l’une des optimisations les plus rentables sur les pages qui contiennent des vidéos. Plus de détails sur https://opuslab.tn.
6. Faire le tri dans les plugins et le thème
Gain mesuré : -0,4 s, et une baisse de 380 Ko sur le poids total.
Sur 27 plugins actifs, nous en avons désactivé 9 : un constructeur de pages redondant avec l’éditeur de blocs, deux plugins de partage social, un plugin de galerie utilisé sur une seule page, un plugin de statistiques doublonnant Analytics, et divers résidus d’anciennes configurations.
Comment identifier les plugins coûteux
L’extension Query Monitor affiche pour chaque page le nombre de requêtes SQL, le temps d’exécution PHP et les scripts chargés, plugin par plugin. C’est l’outil de diagnostic le plus direct.
Points d’attention fréquents :
- Les constructeurs de pages (Elementor, WPBakery, Divi) génèrent un HTML verbeux et chargent leur CSS/JS sur toutes les pages. Ils ne sont pas éliminatoires, mais demandent une configuration soignée (chargement conditionnel des widgets, désactivation des polices et icônes non utilisées).
- Les plugins de sliders sont systématiquement lourds. Un carrousel en CSS pur ou une image fixe fait souvent aussi bien commercialement.
- Les plugins qui chargent leurs assets sur toutes les pages alors qu’ils ne servent que sur une seule. Un plugin comme Asset CleanUp ou Perfmatters permet de désactiver ces chargements page par page.
7. Optimiser le chargement des polices
Gain mesuré : -0,3 s, et suppression du flash de texte invisible.
- Hébergez vos polices localement plutôt que de les appeler depuis Google Fonts. Vous supprimez une connexion à un domaine externe et vous réglez au passage la question RGPD.
- Limitez-vous à 2 familles et 3 ou 4 graisses. Chaque graisse supplémentaire est un fichier à télécharger.
- Utilisez le format WOFF2 uniquement. Tous les navigateurs actuels le supportent.
- Ajoutez
font-display: swapdans votre déclaration@font-facepour afficher immédiatement le texte avec une police de secours. - Préchargez la police utilisée dans les titres visibles au chargement :
<link rel="preload" as="font" type="font/woff2" crossorigin>.
Astuce complémentaire : choisissez une police de secours dont les métriques sont proches de votre police finale, ou utilisez size-adjust. Cela évite le décalage de mise en page au moment de la substitution.
8. Traiter le CSS et le JavaScript bloquants
Gain mesuré : -0,3 s, mais c’est l’action la plus risquée du lot. Un décryptage comparable se trouve sur cloudflare.com.
Un fichier CSS placé dans le <head> bloque le rendu de la page jusqu’à son téléchargement complet. Les techniques classiques :
- CSS critique en ligne : extraire les règles nécessaires à l’affichage de la partie visible et les injecter directement dans le HTML, en chargeant le reste de façon asynchrone.
- Suppression du CSS inutilisé : sur notre site test, 68 % du CSS chargé n’était utilisé sur aucune page.
- Attributs
deferetasyncsur les scripts non essentiels.
Pourquoi c’est risqué : ces optimisations sont celles qui cassent le plus souvent l’affichage. Un CSS critique mal généré donne une page qui clignote ou s’affiche de travers pendant une seconde. Un defer mal placé casse un script qui dépendait de l’ordre d’exécution.
Notre recommandation : activez ces options une par une, testez chaque page importante sur mobile et desktop, et gardez une sauvegarde. Sur un site vitrine, le gain de 0,3 s ne justifie pas de prendre le risque si vous n’êtes pas à l’aise techniquement. Faites d’abord les points 1 à 7.
9. Activer la compression Brotli ou GZIP
Gain mesuré : -0,2 s.
La compression réduit le poids des fichiers texte (HTML, CSS, JS, SVG, JSON) de 60 à 80 % pendant le transfert. Brotli fait 15 à 20 % mieux que GZIP sur ces mêmes fichiers.
C’est généralement une case à cocher chez votre hébergeur ou dans votre plugin de cache. Pour vérifier si c’est actif : ouvrez l’onglet Réseau de votre navigateur, cliquez sur le document HTML et cherchez content-encoding: br ou gzip dans les en-têtes de réponse.
Attention : ne compressez pas les images (JPEG, PNG, WebP sont déjà compressés), vous gagneriez zéro octet en consommant du CPU.
10. Mettre en place un CDN
Gain mesuré : -0,2 s sur une audience 100 % française. Bien plus si votre audience est internationale.
Un CDN (Content Delivery Network) réplique vos fichiers statiques sur un réseau de serveurs répartis géographiquement. Un visiteur à Marseille récupère les images depuis un point de présence proche plutôt que depuis votre serveur.
Pour un site vitrine dont 95 % du trafic est français et dont le serveur est en France, le gain est modeste. Il devient significatif si :
- Vous avez du trafic hors d’Europe
- Votre site sert beaucoup de médias lourds
- Vous voulez une protection contre les pics de trafic et les attaques
Cloudflare en version gratuite couvre déjà l’essentiel des besoins d’un site vitrine, avec en bonus la mise en cache des ressources statiques et l’optimisation automatique de certains formats.
11. Minifier et regrouper les fichiers
Gain mesuré : -0,1 s. L’action la plus surestimée de la liste.
La minification supprime les espaces, retours à la ligne et commentaires des fichiers CSS et JS. Elle fait gagner quelques kilo-octets, ce qui était significatif en 2012 et l’est beaucoup moins aujourd’hui, surtout combinée à Brotli qui compresse déjà très bien ces caractères. On retrouve la même logique chez un studio de design qui vaut le détour.
Quant au regroupement (concaténation) des fichiers, il était pertinent en HTTP/1.1 où chaque requête coûtait cher. En HTTP/2 et HTTP/3, les requêtes sont multiplexées et le regroupement peut même être contre-productif : un gros fichier invalidé annule tout le cache, là où plusieurs petits fichiers restent partiellement valides.
Activez la minification, elle ne coûte rien. Mais ne comptez pas dessus pour sauver un site lent, et méfiez-vous du regroupement si votre serveur est en HTTP/2 ou HTTP/3.
12. Réserver les espaces pour stabiliser la mise en page
Gain mesuré : 0 s sur le LCP, mais CLS passé de 0,24 à 0,03.
Cette action ne fait pas gagner de temps de chargement, mais elle corrige une métrique Core Web Vitals à part entière, et surtout un vrai irritant utilisateur : le contenu qui saute pendant qu’on essaie de cliquer.
Les corrections à appliquer :
- Toujours indiquer
widthetheight(ou unaspect-ratioen CSS) sur les images et iframes. - Réserver la hauteur des bandeaux, bannières et bandeaux de cookies avec un conteneur de dimensions fixes.
- Éviter les insertions dynamiques au-dessus du contenu déjà affiché.
- Précharger la police des titres et utiliser une police de secours aux métriques proches, pour limiter le décalage à la substitution.
Bilan : de 6,4 s à 1,6 s
| Indicateur | Avant | Après |
|---|---|---|
| Score PageSpeed mobile | 31/100 | 92/100 |
| LCP mobile | 6,4 s | 1,6 s |
| INP | 310 ms | 85 ms |
| CLS | 0,24 | 0,03 |
| TTFB | 810 ms | 95 ms |
| Poids page d’accueil | 4,8 Mo | 640 Ko |
| Nombre de requêtes | 137 | 41 |
Le temps de travail total a été d’environ une journée et demie, dont la moitié consacrée aux points 1, 2 et 3.
Si vous n’avez qu’une demi-journée
Voici l’ordre exact à suivre pour obtenir 70 à 80 % du résultat en quelques heures :
- Mesurez votre page d’accueil et vos deux pages les plus visitées sur PageSpeed Insights, en mobile. Notez le LCP et identifiez l’élément LCP.
- Traitez vos images : redimensionnez, convertissez en WebP, compressez. Vérifiez que l’image LCP n’est pas en lazy loading.
- Listez vos scripts tiers et supprimez ou différez tout ce qui n’est pas indispensable au premier affichage.
- Activez un plugin de cache avec le cache de pages, la compression et le cache navigateur. Un seul plugin.
- Remesurez et comparez.
Si après ces quatre étapes votre LCP reste au-dessus de 3 secondes avec un TTFB élevé, le problème vient de votre hébergement, et aucune optimisation front-end ne le compensera.
Pourquoi c’est un enjeu business, pas seulement technique
Deux raisons de ne pas traiter la vitesse comme un sujet de confort :
- Le référencement. Les Core Web Vitals font partie des signaux d’expérience de page utilisés par Google. À contenu équivalent, un site rapide est favorisé. Et un site lent est aussi un site moins bien crawlé.
- La conversion. Les études sectorielles convergent : chaque seconde supplémentaire de chargement fait chuter le taux de conversion. Sur mobile, le taux d’abandon grimpe fortement au-delà de 3 secondes. Sur un site vitrine, cela se traduit directement par des demandes de devis perdues.
FAQ
Quelle est une bonne vitesse de chargement pour un site web en 2026 ?
Visez un LCP inférieur à 2,5 secondes sur mobile en conditions réelles, et idéalement sous les 2 secondes. Le TTFB devrait rester sous 200 ms avec un cache actif. Un site vitrine bien optimisé peut descendre à 1,2-1,5 s de LCP sans acrobaties techniques.
Pourquoi mon site est-il long à charger alors que mon score PageSpeed est correct ?
Trois causes fréquentes. D’abord, vous regardez peut-être le score desktop alors que la majorité de votre trafic est mobile. Ensuite, les données de laboratoire (test simulé) diffèrent des données terrain : votre site peut être testé à un moment où le serveur est disponible, alors que vos visiteurs tombent sur des pics de charge. Enfin, vous testez sans doute une page déjà en cache. Testez en navigation privée, à différentes heures, et regardez la section données terrain de PageSpeed Insights.
Le score PageSpeed Insights sur 100 influence-t-il directement le référencement ?
Non. Ce score est un indicateur de synthèse pratique, mais Google utilise les Core Web Vitals mesurés sur vos visiteurs réels. Un score de 75 avec des Core Web Vitals dans le vert vaut mieux qu’un score de 95 obtenu artificiellement. Concentrez-vous sur le LCP, l’INP et le CLS terrain.
Faut-il forcément passer au WebP, ou l’AVIF est-il préférable ?
Le WebP est le bon compromis par défaut : support universel, gain de 25 à 40 % sur le JPEG, encodage rapide. L’AVIF compresse mieux (jusqu’à 50 %) mais son encodage est plus lent et certains outils le gèrent mal. La bonne pratique consiste à servir l’AVIF quand le navigateur le supporte, avec un repli en WebP puis en JPEG, ce que gèrent la plupart des plugins d’optimisation d’images.
Combien de plugins WordPress est-ce trop ?
Le nombre importe moins que le poids. Un site avec 30 plugins légers et bien codés peut être plus rapide qu’un site avec 8 plugins qui chargent chacun leur framework JavaScript. La bonne question n’est pas « combien » mais « combien de kilo-octets et de requêtes SQL chacun ajoute-t-il », ce que Query Monitor vous dira.
Un CDN suffit-il à rendre mon site rapide ?
Non. Un CDN réduit la latence de distribution des fichiers statiques, mais il ne diminue ni le poids de vos images non optimisées, ni le temps d’exécution de vos scripts tiers, ni la lourdeur de votre thème. C’est une couche d’accélération utile après avoir traité les fondamentaux, pas un remplacement.
Le lazy loading peut-il nuire au référencement ?
Mal configuré, oui. Si vos images ne sont chargées que par un script JavaScript maison que Googlebot n’exécute pas correctement, elles risquent de ne pas être indexées. Utilisez l’attribut natif loading="lazy", gardez une balise <img> avec un src valide, et vérifiez le rendu dans l’outil d’inspection d’URL de la Search Console.
Faut-il refaire son site quand il est trop lent ?
Rarement nécessaire. Dans la grande majorité des cas, les optimisations décrites ici suffisent. La refonte devient pertinente si le thème est abandonné par son éditeur, si le site repose sur un empilement de constructeurs de pages incompatibles, ou si la structure du contenu doit de toute façon évoluer. Commencez toujours par mesurer et optimiser : c’est dix fois moins cher.
Besoin d’un diagnostic sur votre site ?
Chez Div Studio, nous auditons et optimisons les performances de sites vitrines et e-commerce avec cette méthode : mesure d’abord, priorisation par rapport effort/gain ensuite, et un rapport avant/après chiffré sur les Core Web Vitals. Contactez-nous pour un audit de vitesse de votre site.