Spoiler : c'était quand même nécessaire.
Il y a des jours où on se réveille et on se dit "tiens, et si mon blog chargeait 20 ms plus vite ?". Personne ne l'a demandé. Aucun utilisateur ne s'est plaint (pro tip : il n'y en a pas). Mais voilà, on l'a fait quand même parce que c'est ça, le web moderne : optimiser des trucs pour des visiteurs qui ne viendront probablement jamais.
Voici le bulletin de guerre.
Google Fonts, dehors
Chaque page faisait un aller-retour chez Google pour demander poliment deux polices. Le navigateur bloquait le rendu en attendant la réponse. Charmant.
On a téléchargé les fichiers woff2, on les héberge nous-mêmes. Deux requêtes réseau en moins, zéro dépendance externe, et Google ne sait plus quelles pages vous lisez. Enfin, il le sait quand même, mais au moins c'est pas de notre faute.
CSS : 55 Ko → 42 Ko
23% de réduction grâce à un script de minification en Python qui supprime les commentaires, les espaces et la dignité du code source. Le fichier reste parfaitement lisible par une machine.
Le navigateur se souvient (enfin)
Avant, chaque visite rechargeait tout depuis zéro. Maintenant, des headers ETag permettent au navigateur de demander "est-ce que ça a changé ?" et au serveur de répondre "non" en 304 sans renvoyer un seul octet de HTML. Le genre de conversation qu'on aimerait avoir plus souvent dans la vie.
Gzip : compresser l'évidence
Tout le HTML et le JSON sont désormais compressés avant d'être envoyés. Le gain typique est de 60 à 70% sur du texte. On envoyait littéralement de l'air entre les balises. C'est fini.
Le hero image n'attend plus
L'image principale de la page d'accueil était chargée en lazy loading. Le LCP — Largest Contentful Paint, la métrique que Google utilise pour juger votre âme — souffrait en silence. Un <link rel="preload"> dans le <head> et le navigateur commence à télécharger l'image avant même d'avoir fini de lire le HTML. Malin.
CSS critique : le rendu instantané
Au lieu de bloquer l'affichage en attendant 42 Ko de CSS (dont 90% concernent le footer, l'admin et le mode sombre), on injecte directement dans le <head> les ~2.5 Ko nécessaires au premier écran : reset, layout, header, hero, grille de cartes. La feuille de style complète se charge en arrière-plan, sans que personne ne s'en aperçoive.
Bilan théorique
- Fonts auto-hébergées : 200 à 400 ms (suppression requête externe)
- CSS minifié : 13 Ko par chargement
- Headers ETag / 304 : 100% du poids HTML sur les revisites
- Gzip : 60 à 70% sur HTML/JSON/CSS
- Preload hero : 100 à 300 ms sur le LCP
- Critical CSS inline : First paint quasi instantané
En cumulé, on passe probablement d'un First Contentful Paint de 0,7s à quelque chose autour de 200 ms sur une connexion correcte. En mobile on passe de 2,6s à 800ms. Le Time to Interactive ne bouge pas vraiment — il n'y a quasiment pas de JavaScript. C'est l'avantage de ne pas avoir de framework : il n'y a rien à optimiser côté client.
Est-ce que ça valait le coup ? Techniquement, oui. Humainement, les trois visiteurs mensuels du blog ne verront probablement aucune différence. Mais le score Lighthouse, lui, sera content. Et au fond, c'est pour lui qu'on fait tout ça. Et aussi par principe. Car en 2026 alors que tout est plus rapide et que la puissance CPU est inégalée, tout est moins optimisé. J'ai la conviction inverse, continuons à optimiser autant que possible.
Commentaires (0)