PTAH
← Blog
Mémoire cache : économiser 2 400 $/an sur votre serveur

Mémoire cache : économiser 2 400 $/an sur votre serveur

Jean-Michel Harvey-Perron
Jean-Michel Harvey-Perron
Full-Stack Developer
2

Mon t2.medium AWS me coûtait 408 $/an. Après avoir implémenté la mémoire cache, j'ai downgradé à t2.micro : 100 $/an.

Même trafic. Même performance. 75 % d'économies.

La mémoire cache (ou simplement "cache") stocke temporairement les résultats de calculs coûteux. Au lieu de régénérer la même page 10 000 fois par jour, votre serveur la calcule une fois, la met en cache, puis la sert instantanément aux 9 999 visiteurs suivants.

Ça réduit le CPU, accélère les temps de réponse, et vous permet de payer pour un serveur plus petit. Voici comment ça fonctionne — et combien vous pourriez économiser.

Le problème invisible

Votre site reçoit 100 visiteurs par jour. Votre page d'accueil fait trois requêtes à la base de données, charge un template PHP, compile du CSS, assemble le HTML final. Ça prend 200 millisecondes.

Multipliez par 100 visiteurs : votre serveur refait ce travail 100 fois. Même calcul. Même résultat. 100 fois.

À 10 000 visiteurs par jour, c'est 10 000 calculs identiques. Votre CPU tourne en continu pour régénérer ce qui n'a pas changé depuis hier.

Vous ne payez pas pour l'hébergement. Vous payez pour recalculer la même chose 10 000 fois.

Ce que le cache change

Avec le cache activé, la première visite génère la page normalement. Le serveur stocke le résultat en mémoire RAM (cache). Les 9 999 visites suivantes servent cette version mise en cache — pas de PHP, pas de base de données, pas de calcul.

Avant cache :

Après cache : Économie : 308 $/an sur un seul site avec trafic modéré.

Calculs concrets : 3 scénarios

Scénario 1 : Petit site (5 000 visites/mois)

Sans cache :

Avec cache : Économie annuelle : 104 $

Scénario 2 : Site moyen (50 000 visites/mois)

Sans cache :

Avec cache : Économie annuelle : 204 $

Scénario 3 : Gros site (500 000 visites/mois)

Sans cache :

Avec cache : Économie annuelle : 1 225 $ à 1 600 $

Sur 5 ans, c'est entre 6 000 $ et 8 000 $ économisés — juste en activant le cache.

Les types de cache (et lesquels utiliser)

La mémoire cache fonctionne à différents niveaux. Peu importe votre technologie (PHP, Node.js, Python), ces principes s'appliquent.

Page cache (Nginx/Apache) Sert la page HTML complète sans toucher à votre code backend. La requête n'atteint même pas PHP — Nginx répond directement depuis la RAM.

→ Résultat : Temps de réponse 50× plus rapide → Idéal pour : Pages publiques qui changent rarement (accueil, blog, pages produits) → Attention : Ne pas cacher les pages dynamiques (paniers, tableaux de bord utilisateur)

Opcode cache (automatique en 2026) PHP compile votre code en opcodes avant de l'exécuter. OPcache garde ces opcodes en mémoire plutôt que de recompiler à chaque requête. Node.js et Python ont des mécanismes similaires intégrés.

→ Résultat : Code s'exécute 3× plus vite → Configuration : Activé par défaut sur PHP 8+ → Zéro effort, gain immédiat

Objet cache (Redis/Memcached) Cache les résultats de requêtes de base de données, appels API externes, calculs lourds. Fonctionne avec toutes les technologies backend.

→ Résultat : 80 % moins de requêtes à la base de données → Idéal pour : Données fréquemment lues, rarement modifiées (produits, catégories, profils) → Exemple : Au lieu de requêter la DB pour chaque vue produit, stockez le résultat en Redis pour 10 minutes

CDN (CloudFront, Cloudflare) Images, CSS, JavaScript servis depuis des serveurs proches de vos visiteurs. Réduit la bande passante sur votre serveur principal. Complètement indépendant de votre backend.

→ Résultat : Bande passante serveur réduite de 60 % → Latence réduite (fichiers servis depuis Paris pour visiteurs français, depuis Montréal pour Québec) → Coût : Gratuit (Cloudflare) à quelques dollars/mois (CloudFront)

Priorité d'implémentation : 1. Opcode cache (déjà actif si PHP 8+) 2. Page cache Nginx (impact maximal, setup simple) 3. CDN (économise bande passante immédiatement) 4. Redis/Memcached (si votre DB est un bottleneck)

Mise en place : 3 niveaux

Niveau 1 : Activer OPcache (5 minutes)

Vérifiez que OPcache est actif :

```bash php -i | grep opcache ```

Si désactivé, éditez `php.ini` :

```ini opcache.enable=1 opcache.memory_consumption=128 opcache.max_accelerated_files=10000 ```

Redémarrez PHP-FPM :

```bash sudo systemctl restart php8.3-fpm ```

Gain immédiat : 2-3× plus rapide. Zéro changement de code.

Niveau 2 : Nginx page cache (30 minutes)

Ajoutez dans votre config Nginx :

```nginx fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=MYAPP:100m inactive=60m;

server { location ~ \.php$ { fastcgi_cache MYAPP; fastcgi_cache_valid 200 10m; fastcgi_cache_key "$scheme$request_method$host$request_uri"; add_header X-Cache-Status $upstream_cache_status; # Ne pas cacher si utilisateur connecté fastcgi_cache_bypass $cookie_session; fastcgi_no_cache $cookie_session; } } ```

Testez et rechargez :

```bash sudo nginx -t sudo systemctl reload nginx ```

Vérifiez que ça marche :

```bash curl -I https://votresite.com | grep X-Cache-Status # Devrait afficher "HIT" après la première visite ```

Gain : 20-50× plus rapide pour les pages publiques.

Niveau 3 : Redis + CDN (2 heures)

Redis pour le cache objet :

Installez Redis :

```bash sudo apt install redis-server sudo systemctl enable redis-server ```

Dans votre code (exemple PHP) :

```php $redis = new Redis(); $redis->connect('127.0.0.1', 6379);

$cacheKey = 'product_' . $productId; $product = $redis->get($cacheKey);

if (!$product) { $product = $db->query("SELECT * FROM products WHERE id = ?", [$productId]); $redis->setex($cacheKey, 600, json_encode($product)); // Cache 10 min } ```

CDN avec CloudFront (si AWS) ou Cloudflare (gratuit) :

Cloudflare : Ajoutez votre domaine, pointez vos DNS. Cloudflare cache automatiquement vos assets statiques.

CloudFront : Créez une distribution, configurez votre origine (voir guide EC2).

Gain combiné : 60-80 % de réduction de charge serveur.

L'erreur qui coûte cher

Cache sans invalidation = contenu périmé.

Vous mettez à jour un produit dans votre base de données. Mais le cache sert encore l'ancienne version pendant 10 minutes. Vos clients voient des prix obsolètes.

Solution 1 : Durée courte Cachez pour 5-10 minutes maximum sur du contenu qui change régulièrement. Acceptable pour la plupart des cas.

Solution 2 : Invalidation manuelle Quand vous modifiez un produit, supprimez sa clé du cache :

```php $redis->del('product_' . $productId); ```

Ou purgez le cache Nginx :

```bash sudo rm -rf /var/cache/nginx/* ```

Solution 3 : Cache warming Après modification, régénérez immédiatement la version cachée. Le visiteur suivant obtient la nouvelle version instantanément.

Monitoring : savoir si ça marche

Ajoutez des headers pour suivre le taux de cache hit :

```nginx add_header X-Cache-Status $upstream_cache_status; ```

Monitorez avec :

```bash curl -I https://votresite.com | grep X-Cache # HIT = servi depuis le cache (bon) # MISS = calcul complet (normal pour première visite) # BYPASS = cache ignoré volontairement ```

Suivez votre CPU usage avant/après :

```bash top htop ```

Si le cache fonctionne, votre charge CPU devrait baisser de 50-80 %.

Ce qui compte vraiment

Un t2.medium sans cache = un t2.micro avec cache.

Vous ne payez pas pour de la puissance. Vous payez pour compenser l'inefficacité de recalculer ce qui n'a pas changé.

Le cache élimine cette inefficacité. Les calculs coûteux deviennent rares. Les réponses instantanées deviennent la norme. Votre serveur passe 90 % de son temps à attendre plutôt qu'à calculer.

Résultat : vous downgradez votre instance, réduisez vos coûts, améliorez les performances.

Checklist actionnable :

Moins de 10 000 visites/mois : → Activez OPcache (5 min) → Économie estimée : 50-100 $/an

10 000 à 100 000 visites/mois : → OPcache + Nginx page cache (30 min) → Économie estimée : 200-400 $/an

Plus de 100 000 visites/mois : → OPcache + Nginx + Redis + CDN (2-3h setup) → Économie estimée : 1 000-2 400 $/an

Chaque niveau se construit sur le précédent. Commencez simple. Ajoutez selon vos besoins.

Le cache n'est pas une optimisation. C'est une décision financière.

Votre serveur fait déjà le travail. La seule question : allez-vous le faire payer pour le refaire 10 000 fois, ou une seule ?

Autres articles