Réduire la sous-partie Cache Duration du Time to First Byte

Réduire la Cache Duration du Time to First Byte

Cet article fait partie de notre guide sur le Time to First Byte (TTFB). La cache duration est la deuxième sous-partie du TTFB et représente le temps que le navigateur passe à vérifier son cache local et tout service worker actif pour une réponse correspondante. Bien que la cache duration soit rarement le goulot d'étranglement principal, il est important de la comprendre pour les sites qui utilisent des service workers ou qui s'appuient fortement sur les stratégies de mise en cache du navigateur.

Le Time to First Byte (TTFB) peut être décomposé en les sous-parties suivantes :

• 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 couvre la partie cache duration du Time to First Byte. Si vous cherchez à comprendre ou à corriger le Time to First Byte et que vous ne savez pas ce que signifie cache duration, veuillez lire qu'est-ce que le Time to First Byte et identifier et corriger les problèmes de Time to First Byte avant de commencer cet article.

Note : généralement, la partie Cache Duration du Time to First Byte n'est pas un goulot d'étranglement. Continuez donc votre lecture si a) vous utilisez un service worker, ou b) vous êtes un passionné de pagespeed comme moi !

Généralement, la sous-partie cache duration du Time to First Byte n'est pas un goulot d'étranglement et se produit en 10 à 20 ms. Lors de l'utilisation d'un service worker, un temps acceptable est inférieur à 60 ms.

Comment les Service Workers affectent-ils le Time to First Byte ?

Les service workers peuvent avoir un impact à la fois positif et négatif sur le Time to First Byte (TTFB), mais seulement pour les sites web qui utilisent des Service Workers.

Voici comment les service workers affectent le TTFB :

Ralentissement du TTFB en raison du temps de démarrage du Service Worker : La valeur workerStart représente le temps nécessaire au démarrage d'un Service Worker, s'il y en a un de présent pour la ressource demandée. Ce temps de démarrage est inclus dans le calcul du TTFB. Si un Service Worker doit être démarré ou repris depuis un état arrêté, cela peut ajouter un délai au temps de réponse initial et augmenter le TTFB.

Accélération du TTFB par la mise en cache : En utilisant une stratégie de mise en cache comme stale-while-revalidate, un service worker peut servir le contenu directement depuis le cache s'il est disponible. Cela conduit à un TTFB quasi instantané pour les ressources fréquemment consultées, car le navigateur n'a pas besoin d'attendre une réponse du serveur. Cette stratégie fonctionne mieux pour le contenu rarement mis à jour que pour le contenu généré dynamiquement qui nécessite des informations à jour.

Accélération du TTFB avec l'app-shell : Pour les applications rendues côté client, le modèle app shell (où un service worker livre une structure de page de base depuis le cache et charge dynamiquement le contenu plus tard) peut réduire le TTFB pour cette structure de base à presque zéro.

Ralentissement du TTFB avec du code non optimisé : Des service workers compliqués et inefficaces peuvent ralentir le processus de recherche dans le cache et, ce faisant, ralentir également le TTFB.

Les service workers sont-ils mauvais pour la pagespeed ? Non (généralement) ils ne sont pas mauvais du tout. Bien que les Service Workers puissent initialement augmenter le TTFB en raison du temps de démarrage, leur capacité à intercepter les requêtes réseau, à gérer la mise en cache et à fournir un support hors ligne peut conduire à de sérieuses améliorations de performance à long terme, en particulier pour les visiteurs récurrents d'un site.

Stratégies de mise en cache des Service Workers

La stratégie de mise en cache utilisée par votre service worker détermine comment elle équilibre la vitesse et la fraîcheur. Chaque stratégie a des implications différentes pour la sous-partie cache duration du TTFB :

Cache-First (Cache avec repli sur le réseau)

Le service worker vérifie d'abord le cache. Si une réponse en cache existe, elle est renvoyée 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 : les actifs statiques, les images, les polices et le contenu qui change rarement.

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 repli sur le cache)

Le service worker essaie toujours d'abord le réseau. Si la requête réseau échoue (par exemple, si l'utilisateur est hors ligne), la version en cache est servie. Cette stratégie garantit un contenu frais lorsque le réseau est disponible, mais ne réduit pas le TTFB pour les utilisateurs en ligne.

Idéal pour : les réponses API, le contenu fréquemment mis à jour et les 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 simultanément une version mise à jour sur le réseau en arrière-plan. La version mise à jour remplace la copie en cache pour la prochaine visite. C'est souvent le meilleur équilibre entre vitesse et fraîcheur.

Idéal pour : le contenu qui change régulièrement mais ne nécessite pas une précision en temps réel, comme les articles d'actualité, les articles 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 de l'en-tête Cache-Control

Bien que la sous-partie cache duration du TTFB mesure spécifiquement le temps passé dans les recherches du service worker et du cache du navigateur, des en-têtes Cache-Control appropriés déterminent si le navigateur doit contacter le serveur ou non. Des en-têtes de cache corrects peuvent contourner efficacement l'intégralité du TTFB pour les visiteurs récurrents.

Voici une configuration Cache-Control recommandée pour différents types de ressources :

# Pages HTML (toujours revalider)
Cache-Control: no-cache

# Actifs statiques avec hachage de contenu (cache permanent)
Cache-Control: public, max-age=31536000, immutable

# Images sans hachage de contenu (cache pendant 1 semaine)
Cache-Control: public, max-age=604800

# Réponses API (pas de mise en cache)
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 » ; cela signifie « toujours vérifier d'abord » ;
• no-store : le navigateur ne doit pas mettre la réponse en cache du tout. Utilisez ceci pour le contenu sensible ou hautement dynamique ;
• max-age : le nombre de secondes pendant lesquelles la réponse peut être servie depuis le cache sans revalidation ;
• immutable : indique au navigateur que la ressource ne changera jamais. Combinez cela avec des noms de fichiers hachés par le contenu (ex : style.a1b2c3.css) pour les actifs statiques ;
• public : permet à la réponse d'être mise en cache par les caches partagés (CDN, proxy). Utilisez private pour le contenu spécifique à l'utilisateur.

Lors de l'utilisation d'un CDN comme Cloudflare, vous pouvez également configurer des règles de mise en cache edge. Consultez notre guide sur la façon de configurer Cloudflare pour la performance pour des instructions détaillées.

Back/Forward Cache (bfcache)

Le cache de recul/avance (bfcache) est une optimisation du navigateur qui stocke un instantané complet d'une page en mémoire lorsque l'utilisateur s'en éloigne. Lorsque l'utilisateur appuie sur le bouton de recul ou d'avance, la page est restaurée instantanément depuis la mémoire, éliminant complètement le TTFB (et toute autre métrique de chargement).

Les pages servies depuis le bfcache affichent un TTFB de 0 milliseconde dans les données de RUM car aucune requête réseau n'est effectuée du tout. Le navigateur restaure simplement la page depuis son instantané en mémoire.

Pour vous assurer que vos pages sont éligibles au bfcache :

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

Vous pouvez tester l'éligibilité au bfcache dans les 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 au bfcache.

Pour les sites ayant des schémas de navigation de recul/avance significatifs (ex : pages de catégorie et de produit e-commerce, pages de résultats de recherche), le bfcache peut améliorer considérablement le TTFB perçu pour une grande partie des navigations.

Comment mesurer la sous-partie Cache Duration du Time to First Byte

Vous pouvez mesurer la sous-partie cache duration du Time to First Byte avec cet extrait :

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

  \/\/ récupérer les horodatages pertinents
  const activationStart = navigationEntry.activationStart || 0;
  const waitEnd = Math.max(
    (navigationEntry.workerStart || navigationEntry.fetchStart) -
    activationStart,
    0,
  );
  const dnsStart = Math.max(
    navigationEntry.domainLookupStart - activationStart,
    0,
  );

  \/\/ calculer la cache duration
  const cacheDuration = dnsStart - waitEnd;

  \/\/ journaliser les résultats
  console.log('%cTTFB cacheDuration', 'color: blue; font-weight: bold;');
  console.log(cacheDuration);

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

Comment trouver les problèmes de TTFB causés par une Cache Duration élevée

Pour trouver l'impact que les utilisateurs réels subissent à cause de la cache duration, vous devrez utiliser un outil de RUM comme CoreDash. Le Real User Monitoring vous permettra de suivre les Core Web Vitals de manière très détaillée.

Dans CoreDash, naviguez simplement vers « Time to First Byte » et visualisez les détails de la décomposition. Cela vous montrera la décomposition du TTFB en toutes ses sous-parties et vous indiquera exactement combien de temps prend la cacheDuration pour le 75e centile.

Comment minimiser l'impact du temps de cache du Service Worker

Pour optimiser le TTFB lors de l'utilisation de Service Workers :

• Minimisez la complexité des scripts de Service Worker pour réduire le temps de démarrage ;
• Implémentez des stratégies de mise en cache efficaces au sein du Service Worker (préférez stale-while-revalidate pour les requêtes de navigation) ;
• Envisagez la mise en cache préalable des ressources critiques lors de l'installation du Service Worker ;
• Surveillez et analysez régulièrement l'impact des Service Workers sur le TTFB de votre site ;
• Utilisez le navigation preload pour permettre à la requête réseau de se produire en parallèle avec le démarrage du service worker. Cela évite que le temps de démarrage du service worker ne soit ajouté au TTFB.

Activez le préchargement de navigation dans votre 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 votre site pour les visiteurs récurrents. Échouez-la et chaque chargement de page paiera le coût du démarrage.

Lectures complémentaires : Guides d'optimisation

Guides connexes :

• 103 Early Hints : commencez à charger les ressources critiques avant que la réponse du serveur ne soit prête, complétant ainsi votre stratégie de mise en cache ;
• Configurer Cloudflare pour la performance : configurez la mise en cache edge du CDN, les règles de cache et les règles de page pour optimiser votre stratégie de mise en cache au niveau de l'edge.

Sous-parties du TTFB : Guides complets

La cache duration est l'une des cinq sous-parties du TTFB. Explorez les autres sous-parties pour comprendre l'image complète :

• Fix and Identify TTFB Issues : le point de départ du diagnostic pour toute l'optimisation du TTFB ;
• Waiting Duration : redirections, mise en file d'attente du navigateur et optimisation HSTS ;
• DNS Duration : sélection du fournisseur DNS, configuration TTL et dns-prefetch ;
• Connection Duration : handshake TCP, optimisation TLS, HTTP/3 et preconnect ;
• Request Duration : temps de traitement du serveur, requêtes de base de données et optimisation du backend.