Un site vitrine qui met six secondes à s'afficher : où ça coince

Six secondes, ce n’est jamais une seule cause. C’est une addition : un serveur qui répond lentement, des photos publiées à leur taille d’origine, une vingtaine d’extensions qui chargent chacune leurs fichiers, deux ou trois scripts hébergés ailleurs. Le travail consiste à mesurer chaque poste séparément, puis à les traiter dans l’ordre de leur poids réel.

Ce que contient réellement un temps d’affichage

Trois phases se succèdent, et elles ne se corrigent pas avec les mêmes outils.

Le temps de réponse du serveur, souvent appelé TTFB pour time to first byte — le délai entre la demande du navigateur et le premier octet reçu en retour. Sur un site WordPress sans cache, ce délai contient l’exécution de PHP et les requêtes à la base de données.

Le téléchargement et l’analyse du document HTML, très rapide sur un site vitrine, sauf si le HTML lui-même est gonflé par un constructeur de page.

Le chargement des ressources : images, feuilles de style, scripts, polices. C’est là que se joue l’essentiel sur un site vitrine, parce que ces fichiers sont nombreux et parfois très lourds.

Poste	Ordre de grandeur visé	Ce qui l’aggrave
Réponse serveur	moins de 600 ms	mutualisé saturé, absence de cache, PHP ancien
Document HTML	moins de 100 ko	constructeur de page, contenu injecté
Images d’une page	moins de 1 Mo au total	photos non redimensionnées
Nombre de requêtes	30 à 60	extensions empilées, scripts tiers

Ces repères sont des ordres de grandeur pour situer un diagnostic, pas des mesures faites sur votre site. Les vôtres se relèvent en quelques minutes dans l’onglet réseau du navigateur.

Les images : presque toujours le premier poste

Une photo sortie d’un smartphone récent fait couramment 3 à 6 Mo pour 4 000 pixels de large. Sur une page vitrine, elle sera affichée sur 800 pixels. Le navigateur télécharge donc l’intégralité du fichier, puis en jette les neuf dixièmes à l’affichage.

Trois gestes règlent la question, dans cet ordre.

• Redimensionner à la largeur réelle d’affichage, doublée au maximum pour les écrans à forte densité de pixels. Une image de bandeau dépasse rarement le besoin de 1 600 pixels de large.
• Recompresser entre 75 et 82 de qualité. Au-delà, on ajoute du poids sans différence visible ; en dessous, les aplats se salissent.
• Convertir en WebP, un format d’image compressé lu par tous les navigateurs actuels. À qualité perçue équivalente, un WebP pèse couramment 25 à 35 % de moins qu’un JPEG. L’AVIF fait encore mieux, avec un support plus récent.

Deux réglages complètent le tout. L’attribut loading="lazy" diffère le chargement des images situées sous la ligne de flottaison — mais jamais celui de l’image principale du haut de page, qui est presque toujours l’élément mesuré par le LCP : la différer revient à retarder volontairement l’indicateur qu’on cherche à améliorer. Et chaque balise image doit porter ses attributs width et height, faute de quoi le texte saute au moment où l’image arrive.

Les extensions et le nombre de requêtes

Une requête, c’est un aller-retour entre le navigateur et un serveur pour aller chercher un fichier. Chaque extension WordPress ajoute les siens, sur toutes les pages, y compris celles où elle ne sert à rien. Un formulaire de contact charge son script sur la page d’accueil ; un carrousel charge sa bibliothèque sur la page mentions légales.

Sur un site vitrine ayant accumulé les extensions au fil des années, le compteur dépasse facilement la centaine de requêtes pour six pages de contenu. Les responsables habituels sont les constructeurs de page, qui chargent une base CSS et JavaScript volumineuse, les carrousels, les doublons — deux extensions de référencement, deux systèmes de cache — et les extensions abandonnées par leur auteur, qui pèsent autant qu’avant tout en devenant un risque de sécurité et de compatibilité.

La méthode est ingrate mais sûre : inventorier, désactiver une extension, remesurer la même page, recommencer. Faites-le sur une copie ou après une sauvegarde complète du site, parce qu’une désactivation peut casser un affichage sans prévenir.

L’hébergement : ce qui se joue avant le premier octet

Si le temps de réponse serveur dépasse 600 ms de façon régulière, aucune optimisation d’image n’y changera rien. Sur un hébergement mutualisé, des centaines de sites partagent la même machine et se disputent le processeur et les accès disque. Un voisin bruyant ralentit tout le monde.

Trois vérifications, dans l’ordre du rapport effet sur effort.

• La version de PHP. Une branche ancienne est plus lente et n’est plus corrigée. La bascule se fait en général depuis le panneau de l’hébergeur, en quelques secondes, avec un retour arrière possible.
• Le cache de page. Il génère le HTML une fois et le sert ensuite tel quel, ce qui sort PHP et la base de données du chemin critique. C’est le levier le plus efficace sur une vitrine, dont les pages ne changent presque jamais.
• L’offre elle-même. Les fourchettes constatées sur les grilles publiques des hébergeurs français en août 2026 vont de 3 à 8 € par mois pour un mutualisé d’entrée de gamme, et de 15 à 40 € par mois pour un mutualisé haut de gamme ou une offre WordPress infogérée. La différence porte surtout sur le nombre de sites par machine et sur le cache serveur inclus. Le sujet est traité en détail dans notre page sur le nom de domaine et l’hébergement.

Les polices et les scripts tiers

Une police web est un fichier à télécharger, de 20 à 80 ko en WOFF2 selon les caractères inclus. Deux familles en trois graisses font six fichiers. Limitez-vous à deux familles et à deux ou trois graisses, hébergez-les sur votre propre serveur plutôt que d’appeler un service extérieur, et déclarez font-display: swap pour que le texte s’affiche immédiatement dans une police de substitution.

Les scripts tiers sont l’angle mort le plus fréquent : bulle de discussion, gestionnaire de balises, mesure d’audience, carte interactive, vidéo intégrée, widget d’avis, bandeau de consentement. Chacun impose au navigateur une résolution DNS, une négociation sécurisée et un téléchargement sur un domaine que vous ne contrôlez pas. Quand ce domaine est lent, votre page est lente, et vous n’y pouvez rien.

Trois substitutions règlent la plupart des cas : remplacer une carte intégrée par une image fixe cliquable qui ouvre l’application de cartes, remplacer une vidéo intégrée par sa vignette qui ne charge le lecteur qu’au clic, et ne charger la bulle de discussion que sur la page de contact.

Les trois indicateurs à regarder, et dans quel ordre s’y prendre

Les Core Web Vitals sont les trois mesures publiques que Google utilise pour décrire l’expérience de chargement. Elles sont relevées sur des visites réelles, au 75e centile, séparément sur mobile et sur ordinateur.

Indicateur	Ce qu’il mesure	Seuil considéré comme bon
LCP	Le délai avant l’affichage du plus grand élément visible dans la fenêtre	2,5 s ou moins
INP	Le délai entre une interaction et la mise à jour visuelle qui la suit	200 ms ou moins
CLS	La somme des décalages de mise en page imprévus	0,1 ou moins

Sur un site vitrine, la répartition est assez stable. Le LCP est presque toujours l’image de bandeau ou le fond du haut de page. L’INP pose rarement problème, faute d’interactivité. Le CLS vient de trois sources : des images sans dimensions déclarées, un bandeau de consentement injecté après coup, et une police de substitution aux proportions trop éloignées de la police finale.

Attention à ne pas confondre les deux familles d’outils. Un test en laboratoire simule une visite sur une connexion type et donne un score reproductible, utile pour comparer avant et après. Les données de terrain, elles, décrivent vos visiteurs réels et mettent plusieurs semaines à refléter un changement. Les deux se lisent, mais pas de la même façon.

Traitez d’abord les images, puis le cache et la version de PHP, puis les extensions, puis les scripts tiers, et enfin les polices. C’est l’ordre décroissant du gain habituel sur un site vitrine, et c’est aussi l’ordre croissant de la difficulté.

Une seule règle de méthode, mais elle est décisive : un changement à la fois, remesuré sur la même page avec le même outil. Sans cela, on empile des réglages dont on ne sait plus lequel a servi, et le premier problème réapparaît sans qu’on puisse dire d’où il vient.