Riduci la porzione di durata della cache del Time to First Byte

Riduci la durata della cache del Time to First Byte

Questo articolo fa parte della nostra guida sul Time to First Byte (TTFB). La durata della cache è la seconda sotto-parte del TTFB. Rappresenta il tempo che il browser impiega a cercare una risposta nella cache locale e nei service worker attivi. Di rado la durata della cache è il collo di bottiglia principale. Capirla però è importante per i siti che usano i service worker o dipendono molto dalle strategie di caching del browser.

Il Time to First Byte (TTFB) si divide in queste sotto-parti:

• Waiting + Redirect (o durata di attesa)
• Worker + Cache (o durata della cache)
• DNS (o durata del DNS)
• Connessione (o durata della connessione)
• Richiesta (o durata della richiesta)

Vuoi ottimizzare il Time to First Byte? Questo articolo copre la durata della cache del Time to First Byte. Se vuoi capire o correggere il Time to First Byte e non sai cosa significa la durata della cache, leggi cos'è il Time to First Byte e identifica e risolvi i problemi di Time to First Byte prima di iniziare questo articolo.

Nota: in genere la durata della cache del Time to First Byte non è un collo di bottiglia. Continua a leggere se a) usi un service worker, oppure b) sei un appassionato di performance come me!

Di solito la durata della cache del Time to First Byte non è un collo di bottiglia e si completa tra 10 e 20 ms. Se usi un service worker, un tempo accettabile è sotto i 60 ms.

In che modo i service worker influenzano il Time to First Byte?

I service worker possono avere un impatto sia positivo che negativo sul Time to First Byte (TTFB). Questo vale solo per i siti che li utilizzano.

Ecco come i service worker influenzano il TTFB:

Rallentano il TTFB per via del tempo di avvio del service worker: Il valore workerStart rappresenta il tempo necessario per avviare un service worker. Questo tempo di avvio entra nel calcolo del TTFB. Se un service worker deve avviarsi o riprendersi da uno stato terminato, aggiunge un ritardo alla risposta iniziale e aumenta il TTFB.

Velocizzano il TTFB grazie alla cache: Usando una strategia come stale-while-revalidate, un service worker serve il contenuto direttamente dalla cache. Questo porta a un TTFB quasi istantaneo per le risorse frequenti. Il browser non deve aspettare la risposta del server. Questa strategia funziona bene per i contenuti aggiornati di rado. Non è adatta ai contenuti generati dinamicamente che richiedono dati sempre aggiornati.

Velocizzano il TTFB con l'app-shell: Nelle applicazioni client-rendered, il modello app-shell (in cui un service worker fornisce la struttura di base della pagina dalla cache e carica il contenuto dinamicamente in seguito) azzera quasi del tutto il TTFB di quella struttura di base.

Rallentano il TTFB con codice non ottimizzato: Service worker complessi e inefficienti rallentano la ricerca nella cache. Di conseguenza rallentano anche il TTFB.

I service worker danneggiano la velocità? No, quasi mai. I service worker possono aumentare il TTFB iniziale per via dell'avvio. Tuttavia, intercettano le richieste, gestiscono la cache e offrono supporto offline. Nel lungo periodo portano enormi miglioramenti di performance, specialmente per i visitatori ricorrenti.

Strategie di caching dei service worker

La strategia di caching del service worker decide l'equilibrio tra velocità e freschezza dei dati. Ogni strategia ha effetti diversi sulla durata della cache nel TTFB:

Cache-First (Cache con fallback alla rete)

Il service worker controlla prima la cache. Se trova una risposta, la restituisce subito. Altrimenti la richiesta passa alla rete. Questa strategia offre il TTFB più basso per le risorse in cache, ma rischia di servire contenuti vecchi.

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

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 alla cache)

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

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

Stale-While-Revalidate

Il service worker restituisce subito la versione in cache (TTFB veloce). Allo stesso tempo recupera in background la versione aggiornata dalla rete. La nuova versione sostituisce quella in cache per la visita successiva. Spesso è il miglior compromesso tra velocità e freschezza.

Ideale per: contenuti aggiornati regolarmente ma senza bisogno di precisione in tempo reale. Ad esempio notizie, articoli di blog e schede prodotto.

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'header Cache-Control

La durata della cache nel TTFB misura il tempo speso per cercare nei service worker e nella cache del browser. I giusti header Cache-Control, però, decidono se il browser deve contattare del tutto il server. Header di cache corretti azzerano l'intero TTFB per i visitatori ricorrenti.

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

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

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

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

# Risposte API (nessuna cache)
Cache-Control: no-store

Spiegazione delle direttive chiave:

• no-cache: il browser deve revalidare la risorsa col server prima di usarla. Non significa "non fare cache", ma "controlla sempre prima".
• no-store: il browser non deve mai mettere in cache la risposta. Usalo per contenuti sensibili o molto dinamici.
• max-age: il numero di secondi in cui la risposta può essere servita dalla cache senza revalidazione.
• immutable: dice al browser che la risorsa non cambierà mai. Combinalo con nomi file che includono un hash (es. style.a1b2c3.css) per gli asset statici.
• public: permette di salvare la risposta in cache condivise (CDN, proxy). Usa private per i contenuti specifici dell'utente.

Se usi una CDN come Cloudflare, puoi anche configurare regole di edge caching. Consulta la nostra guida su come configurare Cloudflare per le performance per le istruzioni complete.

Back/Forward Cache (bfcache)

La back/forward cache (bfcache) è un'ottimizzazione del browser. Salva in memoria un'istantanea completa della pagina quando l'utente la lascia. Quando l'utente preme i tasti indietro o avanti, la pagina viene ripristinata all'istante dalla memoria. Questo azzera il TTFB e ogni altra metrica di caricamento.

Le pagine servite dalla bfcache mostrano un TTFB di 0 millisecondi nei dati RUM. Questo accade perché non c'è nessuna richiesta di rete. Il browser ripristina semplicemente la pagina dall'istantanea in memoria.

Per assicurarti che le tue pagine supportino la bfcache:

• Non usare i listener per l'evento unload (usa pagehide).
• Non usare 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 la compatibilità con la bfcache nei Chrome DevTools, nel tab Application, sotto la sezione "Back/Forward Cache". Chrome elencherà i motivi per cui la pagina non era compatibile con la bfcache.

Per i siti con frequenti navigazioni avanti/indietro (es. pagine di categoria e prodotto negli e-commerce, pagine di risultati di ricerca), la bfcache migliora drasticamente il TTFB percepito per un gran numero di visite.

Come misurare la durata della cache del Time to First Byte

Puoi misurare la durata della cache 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 durata della cache
  const cacheDuration = dnsStart - waitEnd;

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

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

Come trovare problemi di TTFB causati da un'alta durata della cache

Per scoprire l'impatto della durata della cache sugli utenti reali ti serve uno strumento RUM come CoreDash. Il Real User Monitoring ti permette di tracciare i Core Web Vitals nel dettaglio.

In CoreDash, vai in "Time to First Byte" e guarda i dettagli del breakdown. Vedrai il TTFB diviso in tutte le sue sotto-parti. Scoprirai esattamente quanto tempo richiede la cacheDuration per il 75° percentile.

Come ridurre l'impatto dei tempi di cache dei service worker

Per ottimizzare il TTFB quando usi i service worker:

• Riduci la complessità degli script del service worker per abbassare il tempo di avvio.
• Implementa strategie di caching efficienti nel service worker (preferisci stale-while-revalidate per le richieste di navigazione).
• Valuta 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 il navigation preload per fare in modo che la richiesta di rete parta in parallelo con l'avvio del service worker. Questo evita di sommare il tempo di avvio al TTFB.

Abilita il navigation preload nel tuo service worker così:

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

Implementali nel modo giusto e i service worker velocizzeranno il sito per i visitatori ricorrenti. Sbaglia, e ogni caricamento di pagina pagherà il costo di avvio.

Approfondimenti: Guide all'ottimizzazione

Guide correlate:

• 103 Early Hints: inizia a caricare risorse critiche prima che la risposta del server sia pronta. Si integra perfettamente con la tua strategia di caching.
• Configurare Cloudflare per le performance: imposta edge caching sulla CDN, cache rules e page rules per ottimizzare la strategia di caching a livello edge.

Sotto-parti del TTFB: Guide complete

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

• Identificare e risolvere problemi di TTFB: il punto di partenza diagnostico per l'ottimizzazione del TTFB.
• Durata di attesa: redirect, code del browser e ottimizzazione HSTS.
• Durata del DNS: scelta del provider DNS, configurazione TTL e dns-prefetch.
• Durata della connessione: handshake TCP, ottimizzazione TLS, HTTP/3 e preconnect.
• Durata della richiesta: tempo di elaborazione del server, query al database e ottimizzazione backend.