Ridurre la sotto-parte Cache Duration del Time to First Byte

Ridurre la Cache Duration del Time to First Byte

Questo articolo fa parte della nostra guida sul Time to First Byte (TTFB). La cache duration è la seconda sotto-parte del TTFB e rappresenta il tempo che il browser impiega a controllare la sua cache locale e gli eventuali service worker attivi per una risposta corrispondente. Sebbene la cache duration sia raramente il collo di bottiglia principale, comprenderla è importante per i siti che utilizzano i service worker o si affidano pesantemente alle strategie di caching del browser.

Il Time to First Byte (TTFB) può essere scomposto nelle seguenti sotto-parti:

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

Vuoi ottimizzare il Time to First Byte? Questo articolo copre la parte relativa alla cache duration del Time to First Byte. Se stai cercando di capire o risolvere il Time to First Byte e non sai cosa significhi cache duration, ti preghiamo di leggere cos'è il Time to First Byte e identificare e risolvere i problemi di Time to First Byte prima di iniziare con questo articolo.

Nota: solitamente la parte relativa alla Cache Duration del Time to First Byte non è un collo di bottiglia. Quindi continua a leggere se a) stai usando un service worker, o b) sei un appassionato di pagespeed come me!

Solitamente la sotto-parte cache duration del Time to First Byte non è un collo di bottiglia e si verifica entro 10-20 ms. Quando si utilizza un service worker, un tempo accettabile è inferiore a 60 ms.

In che modo i Service Worker influenzano il Time to First Byte?

I service worker possono avere sia un impatto positivo che negativo sul Time to First Byte (TTFB), ma solo per i siti web che utilizzano i Service Worker.

Ecco come i service worker influenzano il TTFB:

Rallentano il TTFB a causa del tempo di avvio del Service Worker: Il valore workerStart rappresenta il tempo necessario per l'avvio di un Service Worker, se presente per la risorsa richiesta. Questo tempo di avvio è incluso nel calcolo del TTFB. Se un Service Worker deve essere avviato o ripreso da uno stato terminato, può aggiungere un ritardo al tempo di risposta iniziale e aumentare il TTFB.

Velocizzano il TTFB tramite il caching: Utilizzando una strategia di caching come stale-while-revalidate, un service worker può servire i contenuti direttamente dalla cache, se disponibili. Ciò porta a un TTFB quasi istantaneo per le risorse consultate di frequente, poiché il browser non deve attendere una risposta dal server. Questa strategia funziona meglio per i contenuti aggiornati raramente piuttosto che per i contenuti generati dinamicamente che richiedono informazioni aggiornate.

Velocizzano il TTFB con l'app-shell: Per le applicazioni renderizzate sul client, il modello app shell (in cui un service worker fornisce una struttura di pagina di base dalla cache e carica dinamicamente i contenuti in un secondo momento) può ridurre il TTFB per quella struttura di base quasi a zero.

Rallentano il TTFB con codice non ottimizzato: Service worker complicati e inefficienti possono rallentare il processo di ricerca nella cache e, così facendo, rallentare anche il TTFB.

I service worker sono dannosi per la pagespeed? No (solitamente) non lo sono affatto. Sebbene i Service Worker possano inizialmente aumentare il TTFB a causa del tempo di avvio, la loro capacità di intercettare le richieste di rete, gestire il caching e fornire supporto offline può portare a seri miglioramenti delle prestazioni a lungo termine, specialmente per i visitatori ricorrenti di un sito.

Strategie di Caching dei Service Worker

La strategia di caching utilizzata dal tuo service worker determina il modo in cui bilancia velocità e freschezza. Ogni strategia ha implicazioni diverse per la sotto-parte cache duration del TTFB:

Cache-First (Cache con fallback sulla rete)

Il service worker controlla prima la cache. Se esiste una risposta in cache, viene restituita immediatamente. In caso contrario, la richiesta va alla rete. Questa strategia offre il TTFB più veloce per le risorse in cache, ma rischia di servire contenuti obsoleti.

Ideale per: asset statici, immagini, font e contenuti che cambiano raramente.

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 (Rete con fallback sulla cache)

Il service worker prova sempre prima la rete. Se la richiesta di rete fallisce (ad esempio, l'utente è offline), viene servita la versione in cache. Questa strategia garantisce contenuti freschi quando la rete è disponibile, ma non riduce il TTFB per gli utenti online.

Ideale per: risposte API, contenuti aggiornati di frequente e pagine in cui la freschezza è fondamentale.

Stale-While-Revalidate

Il service worker restituisce immediatamente la versione in cache (TTFB veloce) e contemporaneamente recupera una versione aggiornata dalla rete in background. La versione aggiornata sostituisce la copia in cache per la visita successiva. Questo è spesso il miglior equilibrio tra velocità e freschezza.

Ideale per: contenuti che cambiano regolarmente ma non richiedono precisione in tempo reale, come articoli di notizie, post di blog e listini prodotti.

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;
      });
    })
  );
});

Configurazione dell'intestazione Cache-Control

Mentre la sotto-parte cache duration del TTFB misura specificamente il tempo speso nelle ricerche del service worker e della cache del browser, intestazioni Cache-Control adeguate determinano se il browser deve contattare affatto il server. Intestazioni di cache corrette possono bypassare efficacemente l'intero TTFB per i visitatori ricorrenti.

Ecco una configurazione Cache-Control consigliata per diversi tipi di risorse:

# Pagine HTML (rivalidare sempre)
Cache-Control: no-cache

# Asset statici con content hashing (cache per sempre)
Cache-Control: public, max-age=31536000, immutable

# Immagini senza content hashing (cache per 1 settimana)
Cache-Control: public, max-age=604800

# Risposte API (nessun caching)
Cache-Control: no-store

Spiegazione delle direttive chiave:

• no-cache: il browser deve rivalidare con il server prima di utilizzare una copia in cache. Non significa "non mettere in cache"; significa "controlla sempre prima".
• no-store: il browser non deve affatto mettere in cache la risposta. Usalo per contenuti sensibili o altamente dinamici.
• max-age: il numero di secondi per cui la risposta può essere servita dalla cache senza rivalidazione.
• immutable: indica al browser che la risorsa non cambierà mai. Combinatela con nomi di file con hash del contenuto (ad esempio, style.a1b2c3.css) per gli asset statici.
• public: consente alla risposta di essere memorizzata in cache dalle cache condivise (CDN, proxy). Usa private per i contenuti specifici dell'utente.

Quando utilizzi un CDN come Cloudflare, puoi anche configurare le regole di edge caching. Consulta la nostra guida su come configurare Cloudflare per le prestazioni per istruzioni dettagliate.

Back/Forward Cache (bfcache)

La back/forward cache (bfcache) è un'ottimizzazione del browser che memorizza uno snapshot completo di una pagina in memoria quando l'utente si allontana. Quando l'utente preme il pulsante avanti o indietro, la pagina viene ripristinata istantaneamente dalla memoria, eliminando completamente il TTFB (e ogni altra metrica di caricamento).

Le pagine servite dalla bfcache mostrano un TTFB di 0 millisecondi nei dati RUM perché non viene effettuata alcuna richiesta di rete. Il browser ripristina semplicemente la pagina dal suo snapshot in memoria.

Per assicurarti che le tue pagine siano idonee per la bfcache:

• Non utilizzare listener di eventi unload (usa invece pagehide).
• Non utilizzare Cache-Control: no-store sul documento HTML.
• Chiudi tutte le connessioni IndexedDB aperte quando la pagina viene nascosta.
• Non mantenere connessioni WebSocket o WebRTC attive (chiudile nell'evento pagehide).

Puoi testare l'idoneità alla bfcache in Chrome DevTools sotto la scheda Application, nella sezione "Back/Forward Cache". Chrome elencherà tutti i motivi per cui la pagina non era idonea per la bfcache.

Per i siti con schemi di navigazione avanti/indietro significativi (ad esempio, pagine di categoria e prodotto e-commerce, pagine dei risultati di ricerca), la bfcache può migliorare drasticamente il TTFB percepito per una gran parte delle navigazioni.

Come misurare la sotto-parte Cache Duration del Time to First Byte

Puoi misurare la sotto-parte cache duration del Time to First Byte con questo snippet:

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

  \/\/ ottieni i timestamp rilevanti
  const activationStart = navigationEntry.activationStart || 0;
  const waitEnd = Math.max(
    (navigationEntry.workerStart || navigationEntry.fetchStart) -
    activationStart,
    0,
  );
  const dnsStart = Math.max(
    navigationEntry.domainLookupStart - activationStart,
    0,
  );

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

  \/\/ logga i risultati
  console.log('%cTTFB cacheDuration', 'color: blue; font-weight: bold;');
  console.log(cacheDuration);

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

Come trovare i problemi di TTFB causati da un'elevata Cache Duration

Per trovare l'impatto che gli utenti reali sperimentano a causa della cache duration, dovrai utilizzare uno strumento RUM come CoreDash. Il Real User Monitoring ti permetterà di tracciare i Core Web Vitals in grande dettaglio.

In CoreDash, vai semplicemente su "Time to First Byte" e visualizza i dettagli della scomposizione. Questo ti mostrerà la scomposizione del TTFB in tutte le sue sotto-parti e ti dirà esattamente quanto tempo impiega la cacheDuration per il 75° percentile.

Come ridurre al minimo l'impatto del tempo di cache del Service Worker

Per ottimizzare il TTFB quando si utilizzano i Service Worker:

• Riduci al minimo la complessità degli script del Service Worker per ridurre il tempo di avvio.
• Implementa strategie di caching efficienti all'interno del Service Worker (preferisci stale-while-revalidate per le richieste di navigazione).
• Considera il pre-caching delle risorse critiche durante l'installazione del Service Worker.
• Monitora e analizza regolarmente l'impatto dei Service Worker sul TTFB del tuo sito.
• Usa navigation preload per consentire alla richiesta di rete di avvenire in parallelo con l'avvio del service worker. Questo impedisce che il tempo di boot del service worker venga aggiunto al TTFB.

Abilita il navigation preload nel tuo service worker con:

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

Esegui correttamente l'implementazione e i service worker velocizzeranno il tuo sito per i visitatori ricorrenti. Sbagliala e ogni caricamento di pagina pagherà il costo del boot.

Ulteriori letture: Guide all'ottimizzazione

Guide correlate:

• 103 Early Hints: inizia a caricare le risorse critiche prima che la risposta del server sia pronta, integrando la tua strategia di caching.
• Configurare Cloudflare per le prestazioni: imposta l'edge caching del CDN, le regole di cache e le regole di pagina per ottimizzare la tua strategia di caching a livello di edge.

Sotto-parti del TTFB: Guide complete

La cache duration è una delle cinque sotto-parti del TTFB. Esplora le altre sotto-parti per comprendere il quadro completo:

• Identificare e risolvere i problemi di TTFB: il punto di partenza diagnostico per tutta l'ottimizzazione del TTFB.
• Waiting Duration: reindirizzamenti, accodamento del browser e ottimizzazione HSTS.
• DNS Duration: selezione del fornitore DNS, configurazione TTL e dns-prefetch.
• Connection Duration: handshake TCP, ottimizzazione TLS, HTTP/3 e preconnect.
• Request Duration: tempo di elaborazione del server, query del database e ottimizzazione del backend.