Optimisation Serveur et Infrastructure
TTFB, compression, cache, CDN
1) Comprendre le TTFB (Time To First Byte)
Le TTFB mesure le temps entre la demande de l'utilisateur et la réception du premier octet de réponse. C'est le point de départ de tout chargement : tant que le serveur n'a pas répondu, rien ne peut commencer.
Le TTFB n'est pas une seule chose : c'est la somme de plusieurs étapes. Comprendre ces étapes permet de savoir où agir.
Traduire le nom de domaine en adresse IP
Établir la connexion avec le serveur (handshake)
Sécuriser la connexion HTTPS (certificat)
Backend, base de données, génération de la page
Diagnostiquer un TTFB lent
Dans les DevTools (onglet Network), clique sur la requête principale (le document HTML) et regarde l'onglet Timing. Tu verras le détail de chaque phase.
Red flags à surveiller
- Waiting (TTFB) > 500ms : le serveur est trop lent
- DNS > 100ms : utiliser un DNS plus rapide (Cloudflare DNS)
- SSL > 100ms : vérifier la configuration TLS
- Temps variable : problème de cache serveur
Solutions courantes
- Cache serveur : évite de régénérer les pages
- CDN : rapproche le contenu des utilisateurs
- Meilleur hébergeur : SSD, plus de RAM, CPU dédié
- Optimiser le backend : requêtes DB, code PHP/Node
Astuce : pour tester le TTFB sans le biais de ta connexion, utilise KeyCDN Performance Test ou WebPageTest depuis différentes localisations.
2) Compression des fichiers
La compression réduit la taille des fichiers avant le transfert. Le navigateur les décompresse automatiquement. C'est transparent pour l'utilisateur, mais ça peut diviser la taille des fichiers par 3 à 5.
Vérifier que la compression est active
Dans DevTools → Network, compare les colonnes Size (taille réelle) et Transferred (taille transférée). Si elles sont identiques, la compression n'est pas active !
Response Headers: content-encoding: br (ou gzip) Activer Brotli/Gzip selon ton hébergement
| Type d'hébergement | Comment activer |
|---|---|
| CDN (Cloudflare, Vercel, Netlify) | Activé par défaut, Brotli inclus |
| Apache (.htaccess) | AddOutputFilterByType DEFLATE text/html text/css application/javascript |
| Nginx | gzip on; et brotli on; dans la config |
| WordPress | Plugin cache (WP Rocket, LiteSpeed Cache) l'active automatiquement |
Important : ne compresse pas les images avec Gzip/Brotli ! Les formats WebP, AVIF, JPEG sont déjà compressés. Gzip ne ferait que perdre du temps CPU sans gain de taille.
3) Mise en cache : navigateur et serveur
Le cache est ton meilleur allié. Bien configuré, il évite de retélécharger ce qui n'a pas changé et de recalculer ce qui est identique.
max-age=31536000, immutable Assets versionnés (app.a1b2c3.js) 1 an, jamais revalidé max-age=3600, must-revalidate Pages HTML 1h puis vérification no-cache Contenu dynamique (panier, profil) Toujours revalidé Cache navigateur : les headers HTTP
Le serveur indique au navigateur combien de temps garder chaque fichier en cache via le header Cache-Control.
Stratégie recommandée :
- Assets avec hash (app.a1b2c3.js) :
max-age=31536000, immutable— cache 1 an, jamais revalidé - HTML :
max-age=0, must-revalidateouno-cache— toujours vérifier la fraîcheur - Images/fonts sans hash :
max-age=86400— 24h puis revalidation
Cache serveur : pré-générer les pages
Pour les sites dynamiques (WordPress, Next.js, etc.), le cache serveur stocke les pages HTML déjà générées. Au lieu de :
Requête → PHP → Base de données → Template → HTML → Réponse Tu as simplement :
Requête → HTML (depuis RAM) → Réponse La différence ? De 300-500ms à 20-50ms. C'est 10x plus rapide.
Attention au cache pour le contenu dynamique : un panier d'achat, un espace membre ou un dashboard ne doivent pas être mis en cache ! Sinon un utilisateur pourrait voir les données d'un autre. Configure des exclusions pour les pages avec authentification.
4) CDN : rapprocher le contenu des utilisateurs
Un CDN (Content Delivery Network) est un réseau de serveurs répartis dans le monde. Quand un utilisateur visite ton site, il télécharge depuis le serveur le plus proche, pas depuis ton serveur d'origine.
Ce que fait un CDN
- Cache les fichiers statiques : CSS, JS, images, polices
- Cache le HTML (selon configuration) : pages entières
- Optimise automatiquement : compression, HTTP/2, minification
- Protège contre les attaques : DDoS, bots malveillants
Quel CDN choisir ?
| CDN | Prix | Points forts |
|---|---|---|
| Cloudflare | Gratuit | Le plus populaire, excellent plan gratuit, facile à configurer |
| Vercel / Netlify Edge | Inclus | Intégré si tu déploies dessus, zero config |
| AWS CloudFront | Pay-as-you-go | Très performant, intégration AWS |
| Fastly | Premium | Le plus rapide, purge instantanée, edge computing |
Conseil : pour 90% des sites, Cloudflare gratuit suffit largement. En 10 minutes de configuration, tu gagnes un CDN mondial, la compression Brotli, HTTP/3, et une protection DDoS.
5) HTTP/2 et HTTP/3
Les versions modernes du protocole HTTP améliorent significativement les performances :
HTTP/2 (supporté partout)
- Multiplexage : plusieurs fichiers en parallèle sur une connexion
- Compression des headers : moins d'overhead
- Server Push : envoyer des ressources avant qu'elles soient demandées
HTTP/3 (le futur, déjà dispo)
- QUIC : basé sur UDP, plus rapide
- 0-RTT : connexion quasi-instantanée pour les retours
- Meilleur sur mobile : gère mieux les changements de réseau
La bonne nouvelle : si tu utilises un CDN moderne (Cloudflare, Vercel, Fastly), HTTP/2 et HTTP/3 sont activés automatiquement. Pas besoin de configuration.
6) Cas WordPress
WordPress représente 40%+ du web. C'est puissant mais peut être lent sans optimisation. Voici une configuration optimale :
Choix de l'hébergeur
Évite les hébergeurs mutualisés bas de gamme (OVH Perso, 1&1 basique). Préfère :
- WordPress managé : Kinsta, WP Engine, Cloudways — optimisés pour WordPress, cache intégré
- VPS avec LiteSpeed : o2switch, Infomaniak — excellent rapport qualité/prix
- Headless / Static : Générer un site statique avec des outils comme Astro ou Eleventy
Stack de plugins recommandée
| Besoin | Plugin recommandé | Alternative gratuite |
|---|---|---|
| Cache | WP Rocket (payant, le meilleur) | LiteSpeed Cache, W3 Total Cache |
| Images | Imagify, ShortPixel | Smush (limité), EWWW |
| Minification | WP Rocket (inclus) | Autoptimize |
| Lazy loading | Natif WordPress 5.5+ | — |
| Nettoyage | Perfmatters (payant) | Asset CleanUp |
Piège classique : installer 3 plugins qui font la même chose (cache + minification + optimisation). Ils entrent en conflit ! Choisis un plugin tout-en-un (WP Rocket ou LiteSpeed Cache) et désactive les fonctions redondantes.
Checklist WordPress
- Thème léger : GeneratePress, Astra, Kadence (pas Divi, pas Elementor pour le thème)
- Limiter les plugins : chaque plugin = du code. 10-15 max, bien choisis
- PHP 8.x : vérifie ta version, PHP 8 est 2-3x plus rapide que PHP 7.x
- Base de données : nettoyer les révisions, transients, spam (WP-Optimize)
- Désactiver ce qui ne sert pas : emojis WordPress, embeds, XML-RPC si non utilisé
7) Checklist serveur & infra
Récapitulatif des optimisations côté serveur :
- TTFB < 200ms : vérifier avec WebPageTest ou KeyCDN
- Compression Brotli/Gzip : vérifier le header
content-encoding - Cache navigateur : configurer les headers
Cache-Control - Cache serveur : activer le cache page pour le contenu statique
- CDN : Cloudflare gratuit minimum, ou celui de ton hébergeur
- HTTP/2 ou HTTP/3 : généralement activé par défaut avec HTTPS
- SSL/TLS moderne : TLS 1.3, certificat valide, OCSP stapling
Objectif réaliste : avec ces optimisations, un site WordPress peut passer de 2-3s de chargement à moins de 1s. Un site statique (Astro, Next.js, Hugo) peut atteindre 200-400ms de chargement total.
Que mesure le TTFB (Time To First Byte) ?
Le TTFB mesure le temps entre la requete et la reception du premier octet. C'est le point de depart de tout chargement.