Réduire la durée du cache du Time to First Byte

Réduire la durée du cache du Time to First Byte

Cet article fait partie de notre guide sur le Time to First Byte (TTFB). La durée du cache est la deuxième sous-partie du TTFB. Elle correspond au temps que passe le navigateur à vérifier son cache local et les service workers actifs pour trouver une réponse correspondante. Cette durée est rarement le goulot d'étranglement principal, mais la comprendre est indispensable pour les sites qui utilisent des service workers ou reposent fortement sur des stratégies de cache navigateur.

Le Time to First Byte (TTFB) se décompose en plusieurs sous-parties :

• Waiting + Redirect (ou waiting duration)
• Worker + Cache (ou cache duration)
• DNS (ou DNS duration)
• Connection (ou connection duration)
• Request (ou request duration)

Vous cherchez à optimiser le Time to First Byte ? Cet article traite de la durée du cache du Time to First Byte. Si vous souhaitez comprendre ou corriger le Time to First Byte sans savoir ce que signifie la durée du cache, lisez d'abord qu'est-ce que le Time to First Byte et identifier et corriger les problèmes de Time to First Byte avant d'attaquer cet article.

Remarque : la durée du cache du Time to First Byte est rarement un goulot d'étranglement. Poursuivez donc la lecture si a) vous utilisez un service worker, ou b) vous êtes passionné de pagespeed comme moi !

En général, la sous-partie durée du cache du Time to First Byte ne pose pas problème et s'exécute en 10 à 20 ms. Avec un service worker, un temps inférieur à 60 ms reste acceptable.

Comment les service workers influent sur le Time to First Byte

Les service workers peuvent avoir un impact positif comme négatif sur le Time to First Byte (TTFB), mais uniquement pour les sites qui les utilisent.

Voici comment les service workers influent sur le TTFB :

Ralentir le TTFB à cause du temps de démarrage du service worker : la valeur workerStart représente le temps nécessaire au démarrage d'un service worker si la ressource demandée en dépend. Ce temps de démarrage est inclus dans le calcul du TTFB. Si un service worker doit démarrer ou sortir d'un état arrêté, il ajoute un délai au temps de réponse initial et augmente le TTFB.

Accélérer le TTFB grâce au cache : avec une stratégie de cache comme stale-while-revalidate, un service worker peut servir directement le contenu depuis le cache s'il est disponible. Cela permet d'obtenir un TTFB quasi instantané pour les ressources fréquemment consultées, puisque le navigateur n'a pas à attendre de réponse du serveur. Cette stratégie fonctionne particulièrement bien pour les contenus rarement mis à jour, plutôt que pour les contenus dynamiques qui exigent des données fraîches.

Accélérer le TTFB avec l'app-shell : pour les applications avec rendu côté client, le modèle app-shell (où un service worker fournit une structure de page de base depuis le cache et charge dynamiquement le contenu ensuite) peut réduire le TTFB de cette structure de base à quasiment zéro.

Ralentir le TTFB avec du code non optimisé : des service workers complexes et inefficaces peuvent ralentir la recherche dans le cache et, par conséquent, dégrader le TTFB.

Les service workers sont-ils mauvais pour la pagespeed ? Non (en général), pas du tout. Même si les service workers peuvent initialement augmenter le TTFB à cause de leur temps de démarrage, leur capacité à intercepter les requêtes réseau, gérer le cache et assurer un fonctionnement hors ligne apporte des gains de performance majeurs sur le long terme, surtout pour les visiteurs réguliers.

Stratégies de cache des service workers

La stratégie de cache du service worker détermine l'équilibre entre vitesse et fraîcheur. Chaque stratégie a des répercussions différentes sur la durée du cache du TTFB :

Cache-first (cache avec fallback sur le réseau)

Le service worker vérifie d'abord le cache. Si une réponse s'y trouve, il la renvoie immédiatement. Sinon, la requête part sur le réseau. Cette stratégie offre le TTFB le plus rapide pour les ressources en cache, mais risque de servir du contenu obsolète.

Idéal pour : ressources statiques, images, polices et contenus rarement modifiés.

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then((cachedResponse) => {
      if (cachedResponse) {
        return cachedResponse;
      }
      return fetch(event.request).then((networkResponse) => {
        const cache = await caches.open('v1');
        cache.put(event.request, networkResponse.clone());
        return networkResponse;
      });
    })
  );
});

Network-first (réseau avec fallback sur le cache)

Le service worker tente toujours le réseau en priorité. Si la requête réseau échoue (par exemple quand l'utilisateur est hors ligne), la version en cache est servie. Cette stratégie garantit un contenu frais dès que le réseau fonctionne, mais ne réduit pas le TTFB pour les utilisateurs connectés.

Idéal pour : réponses d'API, contenus fréquemment mis à jour et pages où la fraîcheur est critique.

Stale-while-revalidate

Le service worker renvoie immédiatement la version en cache (TTFB rapide) tout en récupérant en arrière-plan une version mise à jour sur le réseau. La version mise à jour remplace la copie en cache pour la visite suivante. C'est souvent le meilleur compromis entre vitesse et fraîcheur.

Idéal pour : contenus modifiés régulièrement sans exiger une précision en temps réel, comme les articles d'actualité, les billets de blog et les listes de produits.

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.open('v1').then((cache) => {
      return cache.match(event.request).then((cachedResponse) => {
        const fetchPromise = fetch(event.request).then((networkResponse) => {
          cache.put(event.request, networkResponse.clone());
          return networkResponse;
        });
        return cachedResponse || fetchPromise;
      });
    })
  );
});

Configuration des en-têtes Cache-Control

Alors que la sous-partie durée du cache du TTFB mesure précisément le temps passé dans les recherches du service worker et du cache navigateur, des en-têtes Cache-Control adaptés déterminent si le navigateur a besoin de contacter le serveur. Des en-têtes de cache bien configurés permettent tout simplement d'éliminer l'intégralité du TTFB pour les visiteurs qui reviennent.

Voici une configuration Cache-Control recommandée selon le type de ressource :

# HTML pages (always revalidate)
Cache-Control: no-cache

# Static assets with content hashing (cache forever)
Cache-Control: public, max-age=31536000, immutable

# Images without content hashing (cache for 1 week)
Cache-Control: public, max-age=604800

# API responses (no caching)
Cache-Control: no-store

Explication des directives clés :

• no-cache : le navigateur doit revalider auprès du serveur avant d'utiliser une copie en cache. Cela ne signifie pas « ne pas mettre en cache », mais « toujours vérifier d'abord ».
• no-store : le navigateur ne doit absolument pas mettre la réponse en cache. Utilisez cette directive pour les contenus sensibles ou très dynamiques.
• max-age : durée en secondes pendant laquelle la réponse peut être servie depuis le cache sans revalidation.
• immutable : indique au navigateur que la ressource ne changera jamais. Associez cette directive à des noms de fichiers contenant un hash du contenu (par exemple style.a1b2c3.css) pour les assets statiques.
• public : autorise la mise en cache de la réponse par des caches partagés (CDN, proxy). Utilisez private pour les contenus spécifiques à un utilisateur.

Avec un CDN comme Cloudflare, vous pouvez aussi configurer des règles d'edge caching. Consultez notre guide pour configurer Cloudflare pour la performance afin d'obtenir des instructions détaillées.

Back/forward cache (bfcache)

Le back/forward cache (bfcache) est une optimisation du navigateur qui stocke un instantané complet de la page en mémoire dès que l'utilisateur s'en éloigne. Lorsque l'utilisateur clique sur le bouton Précédent ou Suivant, la page est restaurée instantanément depuis la mémoire, ce qui élimine totalement le TTFB (ainsi que toutes les autres métriques de chargement).

Les pages servies depuis le bfcache affichent un TTFB de 0 milliseconde dans les données RUM, car aucune requête réseau n'est émise. Le navigateur se contente de restaurer la page depuis son instantané en mémoire.

Pour garantir l'éligibilité des pages au bfcache :

• N'utilisez pas d'écouteurs d'événements unload (privilégiez pagehide).
• N'utilisez pas Cache-Control: no-store sur le document HTML.
• Fermez les connexions IndexedDB ouvertes lorsque la page est masquée.
• Ne maintenez pas de connexions WebSocket ou WebRTC actives (fermez-les dans l'événement pagehide).

Vous pouvez tester l'éligibilité au bfcache dans Chrome DevTools sous l'onglet Application, dans la section « Back/Forward Cache ». Chrome listera toutes les raisons pour lesquelles la page n'était pas éligible.

Pour les sites avec un volume important de navigations précédent/suivant (par exemple les pages de catégories et de produits en e-commerce ou les résultats de recherche), le bfcache améliore considérablement le TTFB perçu sur une large part des navigations.

Comment mesurer la durée du cache du Time to First Byte

Vous pouvez mesurer la durée du cache du Time to First Byte avec ce snippet :

new PerformanceObserver((entryList) => {
  const [navigationEntry] = entryList.getEntriesByType('navigation');

  // get the relevant timestamps
  const activationStart = navigationEntry.activationStart || 0;
  const waitEnd = Math.max(
    (navigationEntry.workerStart || navigationEntry.fetchStart) -
    activationStart,
    0,
  );
  const dnsStart = Math.max(
    navigationEntry.domainLookupStart - activationStart,
    0,
  );

  // calculate the cache duration
  const cacheDuration = dnsStart - waitEnd;

  // log the results
  console.log('%cTTFB cacheDuration', 'color: blue; font-weight: bold;');
  console.log(cacheDuration);

}).observe({
  type: 'navigation',
  buffered: true
});

Comment identifier les problèmes de TTFB liés à une durée du cache élevée

Pour mesurer l'impact réel subi par les utilisateurs en raison de la durée du cache, vous devez utiliser un outil de RUM comme CoreDash. Le Real User Monitoring permet de suivre les Core Web Vitals dans les moindres détails.

Dans CoreDash, accédez simplement à « Time to First Byte » et consultez le détail de la décomposition. Vous verrez ainsi la répartition du TTFB dans toutes ses sous-parties et saurez exactement combien de temps prend le cacheDuration au 75e percentile.

Comment minimiser l'impact du service worker sur la durée du cache

Pour optimiser le TTFB avec des service workers :

• Minimisez la complexité des scripts du service worker pour réduire le temps de démarrage.
• Mettez en place des stratégies de cache efficaces au sein du service worker (privilégiez stale-while-revalidate pour les requêtes de navigation).
• Pré-cachez les ressources critiques pendant l'installation du service worker.
• Surveillez et analysez régulièrement l'impact des service workers sur le TTFB du site.
• Utilisez navigation preload pour paralléliser la requête réseau avec le démarrage du service worker. Cela évite d'ajouter le temps de boot du service worker au TTFB.

Activez navigation preload dans le service worker avec :

self.addEventListener('activate', (event) => {
  event.waitUntil(
    (async () => {
      if (self.registration.navigationPreload) {
        await self.registration.navigationPreload.enable();
      }
    })()
  );
});

Réussissez l'implémentation, et les service workers accéléreront le site pour les visiteurs récurrents. Ratez-la, et chaque chargement de page paiera le coût du boot.

Pour aller plus loin : guides d'optimisation

Guides associés :

• 103 Early Hints : commencez à charger les ressources critiques avant même que la réponse du serveur soit prête, en complément de la stratégie de cache.
• Configurer Cloudflare pour la performance : configurez l'edge caching du CDN, des cache rules et des page rules pour optimiser la stratégie de cache au niveau de l'edge.

Sous-parties du TTFB : guides complets

La durée du cache est l'une des cinq sous-parties du TTFB. Explorez les autres sous-parties pour avoir une vue d'ensemble :

• Identifier et corriger les problèmes de TTFB : le point de départ du diagnostic pour toute optimisation du TTFB.
• Waiting Duration : redirections, file d'attente du navigateur et optimisation HSTS.
• DNS Duration : choix du résolveur DNS, configuration du TTL et dns-prefetch.
• Connection Duration : handshake TCP, optimisation TLS, HTTP/3 et preconnect.
• Request Duration : temps de traitement du serveur, requêtes en base de données et optimisation backend.