Un client m'appelle un mardi matin, paniqué : son site met 9 secondes à s'afficher sur mobile, et il vient de perdre deux appels d'offres. Je lance un test dans mon navigateur. Verdict : 4,2 Mo d'images non compressées, trois scripts bloquants dans le <head>, et un hébergement mutualisé à 12 €/mois qui rame dès qu'il y a un peu de trafic. Rien de mystérieux. Rien d'exotique. Juste les mêmes erreurs que je vois sur à peu près un site sur deux quand on me demande d'optimiser les performances d'un site web.
Ce qui m'agace, c'est que la plupart des articles sur le sujet vous noient sous des listes d'outils sans jamais vous dire quoi regarder en premier. Alors voilà ma méthode, celle que j'applique réellement, avec les seuils, l'ordre des priorités, et les conneries que j'ai faites en apprenant.
Points clés à retenir
- Le trio LCP < 2,5 s, CLS < 0,1 et INP < 200 ms constitue la cible à viser, pas un idéal abstrait.
- On mesure d'abord, on corrige ensuite. Jamais l'inverse.
- Les images et les scripts tiers représentent la majorité des gains rapides sur un site classique.
- Le back-end compte autant que le front : un TTFB pourri plombe tout le reste.
- On re-mesure après chaque correction. Sinon on travaille à l'aveugle.
Pourquoi optimiser les performances d'un site web n'est plus un luxe technique
Longtemps, la vitesse a été traitée comme un détail d'ingénieur. Un truc dont on parlait en réunion technique, jamais en réunion business. Cette époque est morte.
Google utilise les signaux liés à l'expérience de chargement pour classer une partie des pages, et surtout, il crawle moins profondément un site lent. Concrètement : si votre serveur répond en 3 secondes à chaque requête, le robot de Google passe moins de temps chez vous et indexe moins de pages. J'ai vu un site passer de 4 000 à 1 200 pages indexées en six mois, sans pénalité manuelle, juste parce que le serveur était une passoire.
La vitesse n'est pas qu'un sujet SEO
Sur trois refontes que j'ai suivies ces dernières années, la plus marquante : passage du LCP de 4,1 s à 1,8 s sur un site e-commerce. Le taux de conversion mobile est passé de 1,4 % à 2,2 % en deux mois. Aucun changement de design. Aucune nouvelle campagne. Uniquement de la performance.
Franchement, je ne suis pas surpris. Un utilisateur qui attend, il part. Pas par méchanceté, par réflexe. Il a dix onglets ouverts, il compare, il clique ailleurs. Le problème ? Personne ne vous dit jamais combien de visiteurs vous perdez, parce que les partants ne se plaignent pas.
Mesurer les performances d'un site web, gratuitement et correctement
Première règle que je me suis imposée après des années de bidouille : on ne touche à rien avant d'avoir mesuré. J'ai perdu des semaines à optimiser des trucs qui n'étaient pas le goulot. Le vrai goulot, on le découvre avec des chiffres, pas au feeling.
PageSpeed Insights : par où commencer
C'est l'outil gratuit de référence, accessible à tous, et il fait deux choses distinctes que beaucoup confondent :
- Une analyse labo (Lighthouse) : conditions contrôlées, résultat reproductible.
- Une analyse terrain : données réelles collectées auprès des visiteurs.
Si les deux se contredisent, fiez-vous au terrain. Toujours. Un score labo de 95 avec un terrain catastrophique signifie que vos utilisateurs réels subissent un problème que votre machine de test ne reproduit pas.
Les outils que j'utilise en complément
Lighthouse directement dans les DevTools du navigateur, pour itérer vite sans passer par une interface web. WebPageTest quand je veux tester depuis une localisation précise ou simuler une connexion pourrie. Et pour surveiller en continu, un peu de RUM maison (Real User Monitoring) : quelques lignes de JS qui capturent le LCP, le CLS et l'INP de chaque visiteur, et qui envoient tout ça sur un endpoint à moi. C'est plus fiable que n'importe quel test ponctuel.
Spoiler : un test ponctuel ne vaut rien. Ce qui compte, c'est la tendance sur plusieurs semaines.
Core Web Vitals : les seuils concrets à viser
Voici la grille que j'utilise systématiquement pour prioriser. Si vous ne retenez qu'une chose de cet article, retenez ce tableau.
| Métrique | Bon | À améliorer | Mauvais |
|---|---|---|---|
| LCP (Largest Contentful Paint) | < 2,5 s | 2,5 – 4 s | > 4 s |
| CLS (Cumulative Layout Shift) | < 0,1 | 0,1 – 0,25 | > 0,25 |
| INP (Interaction to Next Paint) | < 200 ms | 200 – 500 ms | > 500 ms |
| TTFB (Time to First Byte) | < 800 ms | 0,8 – 1,8 s | > 1,8 s |
Le TTFB n'est pas un Core Web Vital officiel, mais je l'ajoute toujours car il conditionne tous les autres. Si votre serveur met 2 secondes à répondre, aucun miracle front-end ne vous sauvera.
Corriger : front-end, back-end, dans quel ordre ?
Là, beaucoup d'articles s'arrêtent aux images. C'est nécessaire, pas suffisant. Voici l'ordre que je suis, du plus rentable au moins urgent.
Côté back-end et infrastructure
- Passer en HTTP/2 ou HTTP/3 si ce n'est pas déjà fait. Gain immédiat sur les sites à nombreuses ressources.
- Activer la compression Brotli (ou Gzip à défaut). Un fichier CSS de 80 Ko tombe souvent à 15 Ko.
- Mettre un CDN devant. Même un petit site y gagne sur les utilisateurs éloignés de votre serveur.
- Activer le cache côté serveur pour les pages statiques. Le gain peut être brutal : j'ai vu un TTFB passer de 1,9 s à 120 ms rien qu'avec ça.
Côté front-end
Le fameux chemin critique de rendu. Trois leviers, dans l'ordre :
- Le critical CSS inliné dans la page, le reste chargé de façon asynchrone.
- Le lazy-loading des images sous la ligne de flottaison — mais jamais sur l'image principale du haut de page, sinon vous sabotez votre LCP.
- Le préchargement des polices et des ressources critiques.
Et les scripts tiers. Google Analytics, chat, widgets de réseaux sociaux, tags marketing en tous genres : j'ai compté 11 scripts tiers sur un site client l'année dernière. On en a supprimé six. Le temps d'interactivité a chuté de 40 %. Personne ne les utilisait, ces six scripts.
Les images, toujours les images
Sur la majorité des sites que j'audite, les images représentent plus de la moitié du poids total de la page. Deux corrections à appliquer systématiquement :
- Servir au format WebP ou AVIF plutôt qu'en JPG/PNG brut.
- Adapter réellement la taille servie à la taille affichée (
srcset+sizes).
Mon erreur de débutant, que j'assume : j'ai passé une semaine à optimiser le JavaScript avant de m'apercevoir que 3,4 Mo d'images non optimisées plombaient tout. J'aurais dû regarder le poids par type de ressource en premier. Regardez toujours ça en premier.
Questions qu'on me pose souvent
Comment interpréter un rapport PageSpeed Insight ?
Ne regardez pas le score en premier. Regardez les Core Web Vitals dans la section « Évaluation de l'expérience de chargement de la page ». Le score global est une moyenne pondérée obscure, qui peut chuter à cause d'un détail sans impact réel. Ce qui compte, ce sont les trois métriques : LCP, CLS, INP. Si elles sont dans le vert, le site est rapide, même si le score affiche 70.
Quel test de vitesse de site web choisir ?
Pour une photo à un instant T : PageSpeed Insights ou WebPageTest. Pour suivre l'évolution réelle et savoir si vos corrections fonctionnent : du RUM. Les deux se complètent. Faire uniquement du test ponctuel, c'est comme juger la santé d'un patient sur une seule prise de tension.
Quel poids maximum pour une image ?
En dessous de 200 Ko pour les images de contenu, et sous 100 Ko pour les vignettes. Au-delà, je regarde ce qui se passe. Une image « hero » bien compressée en WebP tient en 80–150 Ko sans perte visible. Si vous dépassez le demi-méga, il y a un problème.
Ce qui reste quand on a tout optimisé
Optimiser les performances d'un site web, c'est rarement un projet qu'on termine. C'est une discipline. Chaque nouveau script, chaque nouveau plugin, chaque nouvelle image non traitée ramène le problème. J'ai un site que je maintiens depuis quatre ans : tous les six mois, je refais un audit, et tous les six mois je trouve quelque chose à corriger.
La bonne nouvelle : les premiers gains sont énormes et rapides. Une après-midi suffit souvent à diviser par deux le temps de chargement. La mauvaise : si personne ne surveille, ça repart. Alors posez-vous une seule question honnête — quand avez-vous testé votre site pour la dernière fois ? Si la réponse est « je ne sais plus », vous savez par où commencer demain matin.
