Caché del navegador explicado: Cache-Control, ETag y ajuste de CDN

Dos capas de caché HTTP

El navegador solicita un recurso
      ↓
① Caché fuerte (sin ida y vuelta al servidor)
   Cache-Control: max-age=31536000
      ↓ expirado
② Caché de validación (preguntar al servidor si cambió)
   ETag / Last-Modified → 304 Not Modified
      ↓ recurso cambiado
③ Obtener nuevo recurso del servidor → 200 OK

Directivas de Cache-Control

Directiva	Significado	Ejemplo de uso
`max-age=N`	Usar caché durante N segundos	JS/CSS (1 año)
`s-maxage=N`	La CDN almacena en caché durante N segundos	HTML (1 día)
`no-cache`	Revalidar ETag cada vez	Respuestas de API
`no-store`	Sin caché en absoluto	Datos sensibles
`immutable`	El contenido nunca cambia	Recursos con nombre hash
`stale-while-revalidate=N`	Servir contenido obsoleto durante N segundos mientras se revalida	JSON de i18n

Configuración de caché de ToolsKu

# _next/static/chunks/app-abc123.js
Cache-Control: public, max-age=31536000, immutable

# /es-419/pdf/merge/index.html
Cache-Control: public, max-age=3600, s-maxage=86400

# /i18n/toolClients/es-419.json
Cache-Control: public, max-age=86400, stale-while-revalidate=604800

Caché de validación ETag

# Primera solicitud
GET /api/config HTTP/1.1
→ 200 OK
   ETag: "abc123"
   Cache-Control: no-cache

# Solicitud posterior
GET /api/config HTTP/1.1
   If-None-Match: "abc123"
→ 304 Not Modified (cuerpo vacío, ahorra ancho de banda)

Los ETags se derivan de un hash del contenido. El contenido sin cambios devuelve 304 y el navegador usa su copia local.

Arquitectura de caché CDN

ToolsKu está desplegado en Alibaba Cloud OSS + CDN:

El usuario solicita https://www.toolsku.com/es-419/
      ↓
Nodo periférico CDN (Beijing / Shanghái / Guangzhou)
      ↓ acierto de caché → respuesta directa (TTFB ~20ms)
      ↓ fallo de caché
Origen OSS (Beijing)
      ↓ devuelve recurso + llena la caché CDN
CDN → usuario

Diseño de clave de caché

Las claves CDN suelen ser URL + cadena de consulta. Cuidado con:

?v=123 y ?v=456 son entradas de caché diferentes
Las solicitudes con Accept-Language pueden dividir la caché (encabezado Vary)
ToolsKu usa configuraciones regionales basadas en rutas (/zh-CN/, /en/) para evitar problemas con Vary

Problemas comunes de caché

1. JS actualizado pero los usuarios ven la versión anterior

Causa: El JS antiguo está fuertemente cacheado; el nuevo HTML referencia nuevos nombres de archivo pero el JS antiguo permanece en caché.

Solución: Nombres de archivo con hash de contenido (por defecto en Next.js _next/static/chunks/app-[hash].js). Cambio de contenido → cambio de hash → invalidación natural.

2. La caché de HTML oculta contenido actualizado

Solución: max-age más corto + s-maxage en HTML, o purgar activamente mediante la API de actualización de CDN.

3. Caché de Service Worker vs caché HTTP

El controlador fetch del Service Worker puede interceptar todas las solicitudes — tiene prioridad sobre la caché HTTP. Incremente la versión de caché en las actualizaciones del SW y elimine las cachés antiguas.

Herramientas de depuración de caché

Chrome DevTools → Network: Columna Size ((disk cache) / (memory cache) / tamaño real)
Encabezados de respuesta: Verificar Cache-Control, ETag, Age
ToolsKu Referencia de códigos de estado HTTP: Entender 200, 304, 404, etc.

Resumen

Un buen caché es fundamental para el rendimiento web. Caché fuerte + caché de validación + nodos periféricos de CDN dan a ToolsKu un TTFB de aproximadamente ~50ms en la primera pintura. Entender Cache-Control y ETag es un trabajo fundamental de rendimiento frontend.