La clave de caché: la aritmética de la cardinalidad

La clave de caché es la afirmación de que dos peticiones distintas merecen exactamente la misma respuesta. Definirla es definir una relación de equivalencia sobre el espacio de peticiones, y ahí está todo el juego: si la haces demasiado fina, tienes millones de entradas que nunca aciertan; si la haces demasiado gruesa, sirves la respuesta de una persona a otra. El equilibrio se calcula, no se intuye, y la aritmética es sencilla.

Qué forma la clave por defecto

Sin configuración, una caché compartida identifica una respuesta por: el método, el esquema, el host, la ruta y la cadena de consulta completa. A eso se suman las cabeceras que la respuesta declare en Vary.

Tres consecuencias inmediatas y molestas:

La cadena de consulta entra entera y en el orden en que llegó. ?a=1&b=2 y ?b=2&a=1 son dos entradas distintas para la misma página. Y ?utm_source=boletin crea una entrada nueva para cada campaña, aunque la respuesta sea idéntica byte a byte.

El host importa. ejemplo.com y www.ejemplo.com son dos cachés separadas. Si no rediriges consistentemente, tienes el doble de entradas y la mitad de aciertos.

Vary es opaco para ti. No puedes ver cuántas variantes ha generado ni cuáles. Por eso, cuando el proveedor lo permite, es preferible definir la clave explícitamente —incluyendo las cookies y cabeceras concretas que quieres— antes que confiar en Vary: lo que defines lo puedes contar.

La aritmética de la cardinalidad

Aquí está el razonamiento que casi nadie hace y que predice si una configuración va a funcionar.

La cardinalidad de una clave es el número de entradas distintas que puede generar: el producto de las cardinalidades de cada dimensión.

10.000 URLs
  x  3 idiomas
  x  2 clases de dispositivo
  x  5 paises
= 300.000 entradas distintas

Ahora la parte que decide. Una entrada acierta si alguien la pide otra vez antes de que caduque y en el mismo nodo. Con un tiempo de vida T y R peticiones a esa clave dentro de la ventana T en ese nodo, la tasa de aciertos de esa clave es aproximadamente (R - 1) / R: la primera petición falla y llena, las demás aciertan.

Los números que salen de ahí son duros:

Y ahora multiplica por el número de nodos. Si tu proveedor tiene trescientos puntos de presencia y tu tráfico se reparte, cada nodo recibe una fracción del total. Una ruta con seiscientas visitas a la hora y un tiempo de vida de una hora suena bien hasta que ves que son dos peticiones por nodo: 50 % de aciertos, y eso siendo optimista con el reparto.

Hay dos remedios y conviene conocer los dos.

Caché en niveles. El proveedor coloca un nivel intermedio —un nodo escudo— entre los nodos de borde y tu origen. Los fallos de los trescientos nodos van al escudo, no a tu servidor. El escudo ve el tráfico agregado, así que su tasa de aciertos es altísima, y tu origen recibe una fracción minúscula. Es una casilla que se marca en la configuración y es de lo más rentable que existe si tienes tráfico repartido geográficamente.

Tiempos de vida más largos con revalidación. Con stale-while-revalidate puedes poner un tiempo de vida largo sin sacrificar frescura, porque el contenido caducado se sigue sirviendo mientras se refresca por detrás. Alargar la ventana T sube R de forma directa.

Normalizar: quitar lo que no cambia la respuesta

La normalización es la operación de mayor rendimiento por línea de código de todo este nivel.

const PARAMS_IRRELEVANTES = new Set([
  'utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
  'gclid', 'fbclid', 'msclkid', 'mc_cid', 'mc_eid', 'ref', 'referrer',
  '_ga', 'igshid', 'ttclid',
]);

function normalizar(url) {
  const u = new URL(url);

  // 1. Fuera los parametros que no cambian la respuesta.
  for (const clave of [...u.searchParams.keys()]) {
    if (PARAMS_IRRELEVANTES.has(clave.toLowerCase())) u.searchParams.delete(clave);
  }

  // 2. Orden estable: ?a=1&b=2 y ?b=2&a=1 son la misma pagina.
  u.searchParams.sort();

  // 3. Host en minusculas y sin puerto por defecto.
  u.hostname = u.hostname.toLowerCase();

  // 4. Barra final consistente.
  if (u.pathname.length > 1 && u.pathname.endsWith('/')) {
    u.pathname = u.pathname.slice(0, -1);
  }

  // 5. El fragmento nunca llega al servidor, pero por si acaso.
  u.hash = '';

  return u;
}

Ojo con el paso 1: solo se pueden quitar los parámetros que de verdad no cambian la respuesta. Si tu aplicación usa ref para algo funcional, quitarlo sirve contenido equivocado. La lista se construye mirando tu código, no copiándola de internet.

El efecto de esto es a menudo espectacular y se puede estimar antes de implementarlo: cuenta cuántas URL distintas ve tu origen en un día y cuántas quedan tras normalizar. En sitios con campañas activas, la reducción de tres a diez veces es habitual, y una reducción de la cardinalidad por cinco multiplica R por cinco.

Añadir dimensiones sin arruinarlo

A veces sí quieres que la respuesta dependa de algo más. País para la moneda, idioma, clase de dispositivo para servir una plantilla distinta. La técnica es agrupar en cubetas: nunca metas el valor bruto en la clave, mete la clase.

// Anadir dimensiones controlando la cardinalidad.
function claveDeCache(peticion) {
  const u = normalizar(peticion.url);

  // Pais -> 4 cubetas, no 200. La respuesta solo cambia por moneda.
  const pais = (peticion.headers.get('cf-ipcountry') || 'XX').toUpperCase();
  const zona = pais === 'ES' ? 'es'
             : ['PT', 'FR', 'IT', 'DE'].includes(pais) ? 'eur'
             : ['MX', 'AR', 'CO', 'CL'].includes(pais) ? 'latam'
             : 'resto';
  u.searchParams.set('__zona', zona);

  // Dispositivo -> 2 cubetas, no miles de cadenas de agente.
  const ua = peticion.headers.get('user-agent') || '';
  u.searchParams.set('__disp', /Mobi|Android|iPhone/i.test(ua) ? 'm' : 'd');

  // Idioma -> las 3 que soportas, no las 40 combinaciones de Accept-Language.
  const idiomas = (peticion.headers.get('accept-language') || '').toLowerCase();
  const idioma = idiomas.startsWith('ca') ? 'ca'
               : idiomas.startsWith('en') ? 'en'
               : 'es';
  u.searchParams.set('__idioma', idioma);

  return new Request(u.toString(), peticion);
}

La diferencia entre esto y usar Vary: Accept-Language, User-Agent, CF-IPCountry es de varios órdenes de magnitud en cardinalidad: cuatro por dos por tres son veinticuatro variantes, frente a las decenas de miles que producen las cabeceras crudas. Y como los parámetros sintéticos son visibles en la URL de la clave, puedes contarlos y depurarlos.

Un detalle sobre la clase de dispositivo que merece mención: si tu CSS es responsivo de verdad, no necesitas esta dimensión en absoluto, y la mejor optimización es eliminarla. Servir plantillas distintas por dispositivo duplica la caché, duplica el trabajo de mantenimiento y produce el bug clásico de que un usuario con la ventana estrecha en escritorio recibe la versión que no toca.