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

Reduce la duración de 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 caché es la segunda subparte del TTFB y representa el tiempo que el navegador dedica a consultar su caché local y cualquier service worker activo en busca de una respuesta coincidente. Aunque la duración de caché rara vez es el cuello de botella principal, comprenderla es importante para sitios que utilizan service workers o dependen en gran medida de estrategias de caché del navegador.

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

• Espera + Redirección (o duración de espera)
• Worker + Caché (o duración de caché)
• DNS (o duración de DNS)
• Conexión (o duración de conexión)
• Solicitud (o duración de solicitud)

¿Buscas optimizar el Time to First Byte? Este artículo proporciona un análisis en profundidad de la parte de duración de caché del Time to First Byte. Si buscas entender o solucionar el Time to First Byte y no sabes qué significa la duración de caché, por favor lee qué es el Time to First Byte y identificar y solucionar problemas del Time to First Byte antes de comenzar con este artículo.

Nota: normalmente la parte de duración de caché del Time to First Byte no es un cuello de botella. Así que continúa leyendo si a) estás utilizando un service worker, o b) eres un entusiasta del rendimiento web como yo.

Normalmente la subparte de duración de caché del Time to First Byte no es un cuello de botella y se completa en 10 a 20 ms. Cuando se utiliza 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 sitios web que utilizan Service Workers.

Así es como los service workers pueden afectar el TTFB:

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

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

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

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

¿Son malos los service workers para el rendimiento web? No, (generalmente) no son malos en absoluto. Aunque los Service Workers pueden aumentar inicialmente el TTFB debido al tiempo de arranque, su capacidad para interceptar solicitudes de red, gestionar la caché y proporcionar soporte offline puede llevar a mejoras de rendimiento significativas a largo plazo, especialmente para visitantes recurrentes de un sitio.

Estrategias de caché de Service Workers

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

Cache-First (caché primero, red como respaldo)

El service worker consulta la caché primero. 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 recursos en caché, pero corre el riesgo de servir contenido desactualizado.

Ideal para: recursos 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 primero, caché como respaldo)

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

Ideal para: respuestas de 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é inmediatamente (TTFB rápido) mientras simultáneamente obtiene una versión actualizada de la red en segundo plano. La versión actualizada reemplaza la copia en caché para la siguiente visita. Este es a menudo el mejor equilibrio entre velocidad y frescura.

Ideal para: contenido que cambia regularmente pero no requiere 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 cabeceras Cache-Control

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

Esta es 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

Directivas clave explicadas:

• no-cache: el navegador debe revalidar con el servidor antes de usar una copia en caché. Esto no significa "no almacenar en caché"; significa "verificar 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 puede servirse desde la caché sin revalidación.
• immutable: indica al navegador que el recurso nunca cambiará. Combínalo con nombres de archivo con hash de contenido (por ejemplo, style.a1b2c3.css) para recursos estáticos.
• public: permite que la respuesta sea almacenada en cachés compartidas (CDN, proxy). Usa private para contenido específico del usuario.

Cuando usas un CDN como Cloudflare, también puedes configurar reglas de caché en el borde. Consulta nuestra guía sobre cómo configurar Cloudflare para rendimiento para 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 memoria cuando el usuario navega fuera de ella. Cuando el usuario presiona el botón atrás o adelante, la página se restaura instantáneamente desde la memoria, eliminando completamente el TTFB (y todas las demás métricas de carga).

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

Para asegurar que tus páginas sean elegibles para bfcache:

• No uses listeners del evento 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 bfcache en Chrome DevTools en la pestaña Application, en la sección "Back/Forward Cache". Chrome listará cualquier razón por la que la página no fue elegible para bfcache.

Para sitios con patrones significativos de navegación atrás/adelante (por ejemplo, páginas de categorías y productos de comercio electrónico, páginas de resultados de búsqueda), bfcache puede mejorar drásticamente el TTFB percibido para una gran parte de las navegaciones.

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

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

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 de TTFB causados por una alta duración de caché

Para encontrar el impacto que experimentan los usuarios reales causado por la duración de caché, necesitarás usar una herramienta de RUM como CoreDash. Real User Monitoring te permitirá rastrear los Core Web Vitals con gran detalle.

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

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

Para optimizar el TTFB cuando se utilizan Service Workers:

• Minimiza la complejidad de los scripts del Service Worker para reducir el tiempo de arranque.
• Implementa estrategias de caché eficientes dentro del Service Worker (prefiere stale-while-revalidate para solicitudes de navegación).
• Considera pre-almacenar en caché los recursos críticos durante la instalación del Service Worker.
• Monitorea y analiza regularmente el impacto de los Service Workers en el TTFB de tu sitio.
• Usa navigation preload para permitir que la solicitud de red ocurra en paralelo con el arranque 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();
      }
    })()
  );
});

Al gestionar cuidadosamente la implementación del Service Worker y comprender su impacto en el TTFB, los desarrolladores pueden equilibrar la sobrecarga inicial con los beneficios de rendimiento a largo plazo que proporcionan los Service Workers.

Lecturas adicionales: guías de optimización

Para técnicas de optimización relacionadas que afectan la caché y el TTFB, explora estas guías:

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

Subpartes del TTFB: artículos de análisis detallado

La duración de caché es una de las cinco subpartes del TTFB. Explora las otras subpartes para comprender el panorama completo:

• Identificar y solucionar problemas de TTFB: el punto de partida diagnóstico para toda optimización del TTFB.
• Duración de espera: redirecciones, cola del navegador y optimización de HSTS.
• Duración de DNS: selección de proveedor DNS, configuración de TTL y dns-prefetch.
• Duración de conexión: handshake TCP, optimización TLS, HTTP/3 y preconnect.