Web Performance Optimization & Lighthouse · Leçon

Mise en cache et compression des réponses d’API

Accélérez les réponses du backend grâce à des couches de mise en cache en mémoire et distribuées, à une invalidation intelligente du cache et à la réduction des charges utiles, afin que les serveurs travaillent moins pour chaque requête.

Leçon 4 sur 413 étapes

Mise en cache et compression des réponses d’API est une leçon Web Performance Optimization & Lighthouse gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Web Performance Optimization & Lighthouse, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Web Performance Optimization & Lighthouse comprend 4 leçons au total.

Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.

Why Cache on the Backend?

Recomputing the same response for every request wastes CPU and database time. Caching stores computed results so repeat requests return instantly, cutting both latency and load.

Layers of Caching

  • In-process memory fastest, but per-instance.
  • Distributed cache (Redis/Memcached) shared across servers.
  • HTTP/CDN cache at the edge.

A Simple Cache-Aside Pattern

The most common pattern: check the cache, return on hit, otherwise compute, store, and return. This is called cache-aside.

async function getUser(id) {
  const hit = await redis.get('user:' + id);
  if (hit) return JSON.parse(hit);
  const user = await db.findUser(id);
  await redis.set('user:' + id, JSON.stringify(user), 'EX', 300);
  return user;
}

Choosing a TTL

A time to live balances freshness against hit rate. Volatile data needs short TTLs; reference data can live much longer. Always set some expiry to avoid stale buildup.

Invalidation Strategies

The hard part of caching is invalidation. On writes, either delete the affected keys or update them (write-through). Stale data here is a common production bug.

async function updateUser(id, data) {
  await db.update(id, data);
  await redis.del('user:' + id);
}

HTTP Caching Headers

For cacheable API responses, set Cache-Control so browsers and CDNs can reuse them, removing the request entirely on a hit.

res.set('Cache-Control', 'public, max-age=60, stale-while-revalidate=300');

Conditional Requests

ETag and If-None-Match let the server reply 304 Not Modified with no body when data is unchanged, saving bandwidth.

res.set('ETag', hashOf(payload));
// next time: if If-None-Match matches, send 304

Shrinking the Payload

Return only the fields clients need, paginate large lists, and avoid over-fetching. Smaller payloads serialize faster and transfer quicker.

Compressing Responses

Enable gzip or Brotli on JSON responses. Combined with caching, this minimizes both compute and transfer per request.

const compression = require('compression');
app.use(compression());

Avoiding Stampedes

When a hot key expires, many requests may hit the database at once (a cache stampede). Mitigate with locks, request coalescing, or stale-while-revalidate.

Strategy Summary

  • Cache-aside with sensible TTLs.
  • Invalidate on writes.
  • Use Cache-Control and ETags.
  • Trim and compress payloads.
  • Guard against stampedes.

Quick Check

After a user updates their profile, the API keeps returning the old data for several minutes. What is the most likely cause?

Recap

You learned to cut backend work with layered caching (cache-aside, TTLs, invalidation on writes), HTTP caching via Cache-Control and ETags, payload trimming, and compression, while guarding against cache stampedes.

Gratuit pour commencer

Apprends Web Performance Optimization & Lighthouse avec un tuteur IA — gratuit

Écris et exécute du vrai code dans ton navigateur, obtiens de l'aide instantanée d'un tuteur IA disponible 24h/24, et reprends là où tu t'es arrêté sur le web ou dans l'app.

Cours
12
Leçons
48

Questions Fréquemment Posées

La leçon « Mise en cache et compression des réponses d’API » est-elle gratuite ?

Oui — le texte complet de « Mise en cache et compression des réponses d’API » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Web Performance Optimization & Lighthouse, passe à CoddyKit PRO. Le cours Web Performance Optimization & Lighthouse comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Mise en cache et compression des réponses d’API » ?

Accélérez les réponses du backend grâce à des couches de mise en cache en mémoire et distribuées, à une invalidation intelligente du cache et à la réduction des charges utiles, afin que les serveurs… Tu pratiques Web Performance Optimization & Lighthouse avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Web Performance Optimization & Lighthouse ?

Aucune expérience préalable n'est requise. Web Performance Optimization & Lighthouse sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.

Combien de temps prend la leçon « Mise en cache et compression des réponses d’API » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Web Performance Optimization & Lighthouse ?

Oui. Chaque leçon Web Performance Optimization & Lighthouse inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Goulets d’étranglement des performances côté serveur
  2. Optimisation des requêtes de base de données
  3. Impact du rendu côté serveur (SSR)
  4. Mise en cache et compression des réponses d’API
← Retour à Web Performance Optimization & Lighthouse