Accélérer un site web

Un site qui met trois secondes à afficher sa première ligne perd des visiteurs avant même d'avoir montré son contenu. La bonne méthode consiste à mesurer, corriger le levier le plus rentable, puis mesurer de nouveau avec le même outil. Sans mesure avant/après, vous ne saurez pas si le changement a servi.

Mesurer le temps de réponse

Le temps jusqu'au premier octet (TTFB) indique si le serveur est lent ; le Largest Contentful Paint (LCP) indique si la page complète est lente. Les deux se lisent dans l'onglet Réseau et le panneau Performance des outils du navigateur. En ligne de commande :

curl -o /dev/null -sS -w "dns=%{time_namelookup} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" https://votre-domaine.fr/

Si le TTFB dépasse largement 300 ms, cherchez côté serveur. S'il est correct mais que la page reste lente, cherchez côté contenu.

Côté serveur : PHP, compression, en-têtes

Sur l'hébergement web NeoHeberg, PHP 8.4 et MySQL sont fournis par KeyHelp. Vérifiez dans le panneau que la version de PHP du domaine est bien 8.4 et que l'OPcache est actif pour les sites PHP.

Contrôlez ensuite la compression et le protocole :

curl -sI -H "Accept-Encoding: gzip, br" https://votre-domaine.fr/ | grep -iE "content-encoding|HTTP"
curl -sI --http2 https://votre-domaine.fr/ | head -n 1

Un content-encoding: br ou gzip divise le poids du HTML et du CSS. HTTP/2 réduit la latence quand de nombreuses ressources sont demandées.

Pour la base, identifiez les requêtes lentes avant d'ajouter un cache : une colonne utilisée dans WHERE ou JOIN sans index coûte cher sur chaque page. Un SELECT * inutile transfère aussi des données dont vous n'avez pas besoin.

Côté contenu : images et requêtes

Servez chaque image à sa taille d'affichage réelle, en WebP ou AVIF, et activez le chargement différé sous la ligne de flottaison — jamais sur l'image principale, qui doit rester prioritaire. Regroupez les fichiers CSS et JS, différez les scripts non critiques, et auto-hébergez les polices avec font-display: swap pour éviter une attente sur un domaine tiers.

Les fichiers statiques versionnés (app.a1b2c3.css) peuvent recevoir un cache long :

Cache-Control: public, max-age=31536000, immutable

CDN et vérification

Un CDN rapproche les fichiers statiques des visiteurs et peut terminer le TLS. Il impose de modifier les enregistrements DNS du domaine : faites-le après avoir stabilisé le serveur, sinon vous mesurez le CDN au lieu de votre application.

Terminez par une mesure identique à celle du départ, en navigation privée et avec un profil mobile bridé. Comparez TTFB et LCP, vérifiez qu'aucune mise en page ne casse, et gardez une sauvegarde avant de changer un réglage PHP ou un en-tête de cache. Un seul mécanisme de cache par niveau : empiler deux plugins ou deux couches de cache produit des pages périmées difficiles à diagnostiquer.