Reduce la subparte de la duración de la caché del Time to First Byte

Reduce la subparte de la duración de la caché del Time to First Byte

Este artículo forma parte de nuestra guía sobre el Time to First Byte (TTFB). La duración de la caché es la segunda subparte del TTFB y representa el tiempo que pasa el navegador comprobando su caché local y cualquier service worker activo en busca de una respuesta coincidente. Aunque la duración de la caché rara vez es el principal cuello de botella, entenderla es importante para los sitios que usan service workers o dependen en gran medida de las estrategias de caché del navegador.

El Time to First Byte (TTFB) se puede desglosar en las siguientes subpartes:

• Waiting + Redirect (o duración de la espera)
• Worker + Cache (o duración de la caché)
• DNS (o duración de DNS)
• Connection (o duración de la conexión)
• Request (o duración de la solicitud)

¿Buscas optimizar el Time to First Byte? Este artículo cubre la parte de la duración de la caché del Time to First Byte. Si buscas entender o solucionar los problemas del Time to First Byte y no sabes qué significa la duración de la caché, lee qué es el Time to First Byte y cómo identificar y solucionar problemas del Time to First Byte antes de empezar con este artículo.

Nota: por lo general, la parte de la duración de la caché del Time to First Byte no es un cuello de botella. Así que sigue leyendo si a) estás usando un service worker, o b) ¡eres un entusiasta de pagespeed como yo!

Normalmente, la subparte de la duración de la caché del Time to First Byte no es un cuello de botella y ocurrirá en un margen de 10 a 20 ms. Cuando se usa un service worker, un tiempo aceptable es inferior a 60 ms.

¿Cómo afectan los Service Workers al Time to First Byte?

Los service workers pueden tener un impacto tanto positivo como negativo en el Time to First Byte (TTFB), pero solo para los sitios web que usan Service Workers.

Así es como los service workers afectan al TTFB:

Ralentizan el TTFB debido al tiempo de inicio del Service Worker: El valor workerStart representa el tiempo que tarda un Service Worker en iniciarse si hay uno presente para el recurso solicitado. Este tiempo de inicio se incluye en el cálculo del TTFB. Si un Service Worker necesita iniciarse o reanudarse desde un estado finalizado, puede añadir un retraso al tiempo de respuesta inicial y aumentar el TTFB.

Aceleran el TTFB mediante el almacenamiento en caché: Al usar una estrategia de almacenamiento en caché como stale-while-revalidate, un service worker puede servir el contenido directamente desde la caché si está disponible. Esto lleva a un TTFB casi instantáneo para los recursos a los que se accede con frecuencia, ya que el navegador no necesita esperar una respuesta del servidor. Esta estrategia funciona mejor para el contenido que se actualiza con poca frecuencia en lugar de para el contenido generado dinámicamente que requiere información actualizada.

Aceleran el TTFB con app-shell: Para las aplicaciones renderizadas en el cliente, el modelo app shell (donde un service worker ofrece una estructura de página básica desde la caché y carga el contenido dinámicamente más tarde) puede reducir el TTFB de esa estructura base casi a cero.

Ralentizan el TTFB con código no optimizado: Los service workers complicados e ineficientes pueden ralentizar el proceso de búsqueda en la caché y, al hacerlo, también ralentizan el TTFB.

¿Son malos los service workers para pagespeed? No (por lo general), no son malos en absoluto. Aunque los Service Workers pueden aumentar inicialmente el TTFB debido al tiempo de inicio, su capacidad para interceptar las solicitudes de red, gestionar el almacenamiento en caché y proporcionar soporte sin conexión puede llevar a mejoras de rendimiento importantes a largo plazo, especialmente para los visitantes recurrentes de un sitio.

Estrategias de almacenamiento en caché del Service Worker

La estrategia de almacenamiento en caché que usa tu service worker determina cómo equilibra la velocidad y la frescura. Cada estrategia tiene diferentes implicaciones para la subparte de la duración de la caché del TTFB:

Cache-First (Caché con respaldo en la red)

El service worker comprueba primero la caché. Si existe una respuesta en caché, se devuelve inmediatamente. Si no, la solicitud va a la red. Esta estrategia ofrece el TTFB más rápido para los recursos en caché, pero corre el riesgo de servir contenido obsoleto.

Ideal para: activos estáticos, imágenes, fuentes y contenido que cambia con poca frecuencia.

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 (Red con respaldo en la caché)

El service worker siempre intenta la red primero. Si la solicitud de red falla (por ejemplo, el usuario está desconectado), se sirve la versión en caché. Esta estrategia garantiza contenido fresco cuando la red está disponible, pero no reduce el TTFB para los usuarios conectados.

Ideal para: respuestas de la API, contenido actualizado con frecuencia y páginas donde la frescura es crítica.

Stale-While-Revalidate

El service worker devuelve la versión en caché de inmediato (TTFB rápido) mientras obtiene simultáneamente una versión actualizada de la red en segundo plano. La versión actualizada reemplaza a la copia en caché para la siguiente visita. A menudo, este es el mejor equilibrio entre velocidad y frescura.

Ideal para: contenido que cambia regularmente pero que no requiere una precisión en tiempo real, como artículos de noticias, publicaciones de blog y listados de productos.

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

Configuración de la cabecera Cache-Control

Aunque la subparte de la duración de la caché del TTFB mide específicamente el tiempo empleado en las búsquedas en la caché del navegador y del service worker, las cabeceras Cache-Control adecuadas determinan si el navegador necesita contactar con el servidor en absoluto. Unas cabeceras de caché correctas pueden omitir eficazmente todo el TTFB para los visitantes recurrentes.

Aquí tienes una configuración recomendada de Cache-Control para diferentes tipos de recursos:

# 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

Explicación de las directivas clave:

• no-cache: el navegador debe revalidar con el servidor antes de usar una copia en caché. Esto no significa "no almacenar en caché"; significa "comprobar siempre primero".
• no-store: el navegador no debe almacenar en caché la respuesta en absoluto. Úsalo para contenido sensible o altamente dinámico.
• max-age: el número de segundos que la respuesta se puede servir desde la caché sin revalidación.
• immutable: le dice al navegador que el recurso nunca cambiará. Combina esto con nombres de archivo con hash de contenido (por ejemplo, style.a1b2c3.css) para los activos estáticos.
• public: permite que la respuesta sea almacenada en caché por cachés compartidas (CDN, proxy). Usa private para el contenido específico del usuario.

Al usar una CDN como Cloudflare, también puedes configurar reglas de caché en el borde. Consulta nuestra guía sobre cómo configurar Cloudflare para el rendimiento para obtener instrucciones detalladas.

Back/Forward Cache (bfcache)

La back/forward cache (bfcache) es una optimización del navegador que almacena una instantánea completa de una página en la memoria cuando el usuario navega fuera de ella. Cuando el usuario pulsa el botón de retroceso o avance, la página se restaura de forma instantánea desde la memoria, eliminando por completo el TTFB (y cualquier otra métrica de carga).

Las páginas servidas desde la bfcache muestran un TTFB de 0 milisegundos en los datos de RUM porque no se realiza ninguna solicitud de red en absoluto. El navegador simplemente restaura la página desde su instantánea en memoria.

Para asegurarte de que tus páginas sean elegibles para la bfcache:

• No uses detectores de eventos unload (usa pagehide en su lugar).
• No uses Cache-Control: no-store en el documento HTML.
• Cierra cualquier conexión abierta de IndexedDB cuando la página esté oculta.
• No mantengas conexiones activas de WebSocket o WebRTC (ciérralas en el evento pagehide).

Puedes probar la elegibilidad de la bfcache en Chrome DevTools en la pestaña Application, en la sección "Back/Forward Cache". Chrome enumerará los motivos por los que la página no ha sido elegible para la bfcache.

Para los sitios con patrones de navegación de retroceso/avance significativos (por ejemplo, páginas de productos y categorías de comercio electrónico, páginas de resultados de búsqueda), la bfcache puede mejorar de forma drástica el TTFB percibido en una gran parte de las navegaciones.

Cómo medir la subparte de la duración de la caché del Time to First Byte

Puedes medir la subparte de la duración de la caché del Time to First Byte con este fragmento:

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

Cómo encontrar problemas del TTFB causados por una alta duración de la caché

Para encontrar el impacto que experimentan los usuarios reales causado por la duración de la caché, tendrás que usar una herramienta de RUM como CoreDash. Real User Monitoring te permitirá hacer un seguimiento detallado de las Core Web Vitals.

En CoreDash, simplemente navega hasta "Time to First Byte" y mira los detalles del desglose. Esto te mostrará el desglose del TTFB en todas sus subpartes y te dirá exactamente cuánto tiempo tarda cacheDuration en el percentil 75.

Cómo minimizar el impacto del tiempo de caché del Service Worker

Para optimizar el TTFB al usar Service Workers:

• Minimiza la complejidad de los scripts de los Service Workers para reducir el tiempo de inicio.
• Implementa estrategias de almacenamiento en caché eficientes dentro del Service Worker (prefiere stale-while-revalidate para las solicitudes de navegación).
• Considera el almacenamiento previo en caché de los recursos críticos durante la instalación del Service Worker.
• Supervisa y analiza periódicamente el impacto de los Service Workers en el TTFB de tu sitio.
• Usa navigation preload para permitir que la solicitud de red se produzca en paralelo al inicio del service worker. Esto evita que el tiempo de arranque del service worker se añada al TTFB.

Habilita navigation preload en tu service worker con:

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

Haz bien la implementación y los service workers acelerarán tu sitio para los visitantes recurrentes. Hazlo mal y cada carga de página pagará el coste de arranque.

Lecturas adicionales: Guías de optimización

Guías relacionadas:

• 103 Early Hints: empieza a cargar los recursos críticos antes de que la respuesta del servidor esté lista, como complemento de tu estrategia de almacenamiento en caché.
• Configurar Cloudflare para el rendimiento: configura el almacenamiento en caché perimetral de la CDN, las reglas de caché y las reglas de página para optimizar tu estrategia de caché a nivel perimetral.

Subpartes del TTFB: Guías completas

La duración de la caché es una de las cinco subpartes del TTFB. Explora las otras subpartes para entender la imagen completa:

• Identificar y solucionar problemas del TTFB: el punto de partida de diagnóstico para toda la optimización del TTFB.
• Duración de la espera: redirecciones, colas en el navegador y optimización de HSTS.
• Duración de DNS: selección de proveedores DNS, configuración TTL y dns-prefetch.
• Duración de la conexión: enlace de tres vías TCP, optimización de TLS, HTTP/3 y preconnect.
• Duración de la solicitud: tiempo de procesamiento del servidor, consultas a la base de datos y optimización del backend.