Accélérer son site sans changer de serveur

Avant d'acheter de la puissance, mesurez : la plupart des sites lents ne manquent pas de processeur, ils envoient trop d'octets et ouvrent trop de connexions.

Mesurer d'abord

curl -o /dev/null -s -w 'connexion %{time_connect}s · tls %{time_appconnect}s · premier octet %{time_starttransfer}s · total %{time_total}s · %{size_download} octets\n' https://monsite.fr/

Un premier octet lent désigne le serveur ou l'application. Un total lent avec un premier octet rapide désigne le poids de la page. Ce sont deux chantiers différents.

1. Compresser

gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_types text/plain text/css application/json application/javascript
           text/xml application/xml image/svg+xml;

Sur du HTML, du CSS ou du JavaScript, la compression retire couramment 70 % du poids. Inutile sur les images et les vidéos, déjà compressées — et les compresser à nouveau coûte du processeur pour rien.

2. Laisser le navigateur garder les fichiers

location ~* \.(js|css|png|jpg|jpeg|gif|webp|svg|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    access_log off;
}

3. HTTP/2

listen 443 ssl;
http2 on;

Une seule connexion transporte toutes les requêtes en parallèle au lieu d'en ouvrir six. Le gain est net sur les pages à nombreux fichiers, et il ne coûte qu'une ligne.

4. Mettre en cache côté serveur

Pour un site dont les pages ne changent pas à chaque visite, nginx peut garder la réponse et servir les suivantes sans réveiller l'application.

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=site:10m max_size=1g inactive=60m;

server {
    location / {
        proxy_cache site;
        proxy_cache_valid 200 10m;
        proxy_cache_bypass $cookie_session;   # jamais de cache pour un visiteur connecté
        add_header X-Cache $upstream_cache_status;
        proxy_pass http://127.0.0.1:3000;
    }
}

Ce qui pèse le plus lourd, en général