Performance

Pourquoi votre site est lent, et ce que ça vous coûte

Les causes réelles de la lenteur d'un site, ce que Google mesure avec les Core Web Vitals, et pourquoi la vitesse est une décision d'architecture, pas un réglage.

7 min de lecture

La lenteur d’un site n’est presque jamais un problème d’hébergement. C’est ce qu’on vous dira pourtant en premier, parce que c’est ce qu’on peut vous vendre le plus vite.

Ce que Google mesure réellement

Trois indicateurs, relevés sur vos visiteurs réels — pas en laboratoire.

Le LCP mesure le temps au bout duquel le plus gros élément visible s’affiche : en général votre image ou votre titre principal. L’objectif est de rester sous 2,5 secondes.

L’INP mesure le délai entre une action du visiteur et la réaction visible de la page. C’est l’indicateur qui a remplacé le FID en 2024, et il est nettement plus sévère : il regarde toutes les interactions, pas seulement la première. Objectif : sous 200 millisecondes.

Le CLS mesure les sauts de mise en page. Vous connaissez la sensation : vous allez cliquer, une bannière se charge au-dessus, tout descend, vous cliquez sur autre chose. Objectif : sous 0,1.

Ces trois mesures entrent dans le classement. Elles ne suffisent pas à faire monter un mauvais contenu, mais elles départagent deux pages équivalentes — c’est-à-dire la situation la plus courante.

Les causes réelles, dans l’ordre

Le JavaScript. C’est la première cause, de très loin. Un site moderne charge couramment 500 ko à 2 Mo de JavaScript, que le navigateur doit télécharger, analyser et exécuter avant que la page réagisse. Sur un téléphone de milieu de gamme — la réalité de la majorité de vos visiteurs — cela représente plusieurs secondes.

Les traceurs et les régies. Chaque outil de mesure, chaque bouton de partage, chaque discussion en direct ajoute des requêtes vers des serveurs que vous ne maîtrisez pas. Un site avec douze traceurs dépend de douze services distincts pour s’afficher correctement.

Les images non préparées. Une photo de 4 Mo redimensionnée en CSS reste une photo de 4 Mo à télécharger. Et sans dimensions déclarées dans le HTML, elle provoque un saut de mise en page à son arrivée.

Les polices. Trois familles, six graisses, format ancien : plusieurs centaines de kilo-octets, et un texte invisible pendant leur chargement si rien n’est prévu.

La base de données. Elle arrive loin derrière, mais elle existe : chaque visite d’un site sous CMS déclenche des dizaines de requêtes pour reconstruire une page qui n’a pas changé depuis trois mois.

Ce que ça coûte, en chiffres

Les études du secteur convergent : au-delà de trois secondes de chargement, une part importante des visiteurs mobiles abandonne avant même d’avoir vu la page. Et l’effet est cumulatif — ils ne reviennent pas.

Ramené à votre activité : si votre site reçoit 2 000 visites par mois et convertit 2 % en demandes, chaque tranche de visiteurs perdue avant l’affichage est une demande qui n’arrivera jamais. Le calcul se fait vite, et il est rarement agréable.

Pourquoi c’est une décision d’architecture

Un site lent se répare rarement. Il se refait.

La raison est simple : la vitesse dépend de choix pris avant la première ligne de code — que met-on dans la page, qui calcule quoi, à quel moment. Un site conçu pour tout exécuter dans le navigateur ne redeviendra pas rapide en changeant d’hébergeur.

C’est pourquoi nous construisons en priorité des sites statiques. La page est calculée une fois, à la mise en ligne, puis servie telle quelle. Il n’y a ni base de données à interroger, ni code à exécuter à chaque visite. Le JavaScript n’est envoyé que là où il sert réellement à quelque chose.

Ce site en est un exemple : il envoie environ deux kilo-octets de JavaScript, pour la parallaxe de la page d’accueil et le formulaire de contact. C’est deux cents à mille fois moins que ce que charge un site vitrine ordinaire.

Ce que vous pouvez vérifier vous-même, aujourd’hui

Ouvrez PageSpeed Insights, entrez votre adresse, et regardez l’onglet mobile, pas l’onglet ordinateur. C’est celui qui correspond à vos visiteurs.

Regardez ensuite les données de terrain en haut du rapport si elles sont disponibles : elles proviennent de vos vrais visiteurs. Le score de laboratoire en dessous est utile pour diagnostiquer, mais c’est le terrain qui compte pour le classement.

Si le LCP dépasse quatre secondes sur mobile, le problème est structurel. Un audit vous dira lequel — et s’il faut réparer ou refaire.

Nous auditons les sites existants et rendons une liste hiérarchisée : ce qui bloque, ce qui rapporte le plus vite, ce qui peut attendre. Elle est à vous, et vous pouvez la faire exécuter par qui vous voulez. Demander un audit.

Parlons-en

Un projet qui ressemble à ça ?

Le cadrage est gratuit et sans engagement. Réponse sous 48 heures ouvrées.