Performance web

Pourquoi c’est un sujet de vente, pas de confort

Sur mobile, chaque seconde d’attente supplémentaire fait partir une part des visiteurs. Sur une boutique, cela se lit directement dans le nombre de commandes. La vitesse n’est pas une coquetterie de développeur.

Ce que je mesure

• LCP : le temps avant que le contenu principal soit visible. Cible : moins de 1,5 s.
• CLS : les éléments qui bougent pendant le chargement. Cible : moins de 0,05.
• INP : le délai avant que le site réagisse à un clic.
• Le poids réel de la page et le nombre de requêtes.

Les mesures sont faites sur vos pages réelles, en conditions mobiles, pas sur la page d’accueil, dans un navigateur de bureau, avec la fibre.

Les causes que je trouve le plus souvent

• Des images en pleine définition redimensionnées par le navigateur.
• Un constructeur de pages qui charge l’intégralité de ses ressources sur chaque page.
• Des polices distantes qui bloquent l’affichage du texte.
• Quinze extensions qui chargent leur code partout, même là où c’est inutile.
• Un cache mal réglé, ou pas de cache du tout.
• Une base de données jamais nettoyée depuis huit ans.

Ce que je livre

Les mesures avant, les corrections faites, les mesures après. Si le gain n’est pas visible dans les chiffres, il n’existe pas.

Un cache suffit‑il

Non, et c’est le malentendu le plus coûteux du sujet. Un cache évite de recalculer la page à chaque visite : il ne réduit pas son poids. Une page de six mégaoctets mise en cache reste une page de six mégaoctets à télécharger.

Le cache masque le symptôme. Installé sur un site alourdi, il donne surtout l’illusion que le problème est réglé, et il rend le diagnostic plus difficile. Il est utile après avoir allégé, jamais à la place.

Combien de temps prend une remise en état

Sur un site vitrine ordinaire, l’essentiel du gain s’obtient en une journée : compression des images, retrait de ce qui ne sert plus, chargement conditionnel des scripts. On passe couramment de cinq secondes à moins de deux.

Sur une boutique, comptez deux à trois jours, parce qu’il faut vérifier qu’aucun allègement ne casse le tunnel de commande. La refonte du thème ou le changement d’hébergement ne se justifient que si ce premier passage n’a pas suffi.

Ce que vous pouvez vérifier vous‑même

Trois contrôles, sans compétence technique et sans rien casser :

• Le poids de vos images. Clic droit sur une image du site, « Ouvrir l’image dans un nouvel onglet », et regardez ses dimensions réelles. Au‑delà de 1 600 pixels de large, elle est trop grande.
• Le nombre d’extensions actives. Au‑dessus de vingt, il y a du ménage à faire.
• La version de PHP, chez votre hébergeur. En dessous de 8.1, vous perdez de la vitesse et vous ne recevez plus de correctifs.

Si ces trois points sont sains et que le site traîne quand même, la cause est ailleurs, et il faut mesurer.

Ce que je ne promets pas

Je ne promets pas cent sur cent à un outil de mesure. Ces notes récompensent des réglages qui n’ont parfois aucun effet sur ce que voit un visiteur, et courir après le score conduit à dégrader le site pour gagner des points.

Ce que je livre, ce sont les mesures avant, les corrections faites, et les mesures après, sur vos pages réelles. Si le gain n’est pas visible dans les chiffres, il n’existe pas.

La première cause, presque toujours la même

Une photo sortie d’un téléphone fait quatre mille pixels de large et pèse trois mégaoctets. Affichée dans un cadre de huit cents pixels, elle est téléchargée en entier avant d’être réduite à l’écran : le visiteur paie les trois mégaoctets pour voir l’équivalent de cent cinquante kilooctets.

Redimensionner les images avant de les déposer fait gagner davantage que tous les réglages d’optimisation réunis. C’est aussi la correction la plus rapide, et elle ne casse rien.