Benchmark de caché fría y caliente: cómo no mezclar resultados

Respuesta breve

Un benchmark de caché en WordPress solo sirve si cada serie de medidas responde a una única pregunta y declara desde qué estado parte. La pasada fría mide el coste de generar la respuesta cuando no hay nada almacenado; la pasada caliente mide el coste de servirla ya construida. Son dos números que describen escenarios distintos, y mezclarlos en una media produce una cifra que no representa ninguna situación real. El protocolo consiste en inventariar las capas de caché que existen, fijar las rutas, purgar solo el entorno de prueba, ejecutar varias pasadas de cada tipo con evidencia de qué capa respondió y conservar todas las muestras, incluidas las malas.

Puntos clave

• Fría y caliente son dos series separadas; la media de ambas no describe nada.
• Antes de medir hay que saber qué capas de caché existen y cómo se distingue cuál respondió.
• Una respuesta rápida con contenido antiguo es un fallo, no un buen resultado.
• Varias pasadas y todas las muestras: la mediana sin dispersión oculta las respuestas lentas.
• Dos candidatos solo son comparables si comparten ruta, contenido, cliente, red, región y política de caché.
• El tiempo de servidor y la carga visual responden a preguntas diferentes y no se mezclan en la misma tabla.

Dos series, dos preguntas

Pasada fría

• Cuánto cuesta generar la respuesta sin nada almacenado
• Se registra qué capa respondió
• Varias pasadas: mediana y peor valor
• Todas las muestras, también las anómalas

Pasada caliente

• Cuánto cuesta servirla ya construida
• El contenido servido se comprueba: rápido y antiguo es un fallo
• Misma ruta, cliente, red, región y política de caché
• Tiempo de servidor y carga visual, en tablas distintas

Definir las capas

Inventaría caché de navegador, caché de página, caché de objetos, OPcache, proxy inverso y CDN. Para cada una registra proveedor, clave de caché, tiempo de vida, mecanismo de purga y qué cabecera o evidencia permite saber que ha respondido. No asumas que un HIT significa la misma capa en todos los entornos: distintos productos usan la misma palabra para cosas distintas.

Las capas de caché entre el visitante y el origen: qué evita cada una y cómo reconocer cuál respondió.

Capa	Qué evita	Cómo se reconoce
navegador	volver a descargar recursos ya obtenidos	cabeceras de control de caché y respuestas 304
CDN o proxy	llegar al origen	cabecera propia del proveedor con estado de acierto
página	ejecutar PHP y montar el HTML	cabecera del plugin o del servidor, o archivo estático servido
objetos	repetir consultas a la base de datos	número de consultas por petición con instrumentación activa
OPcache	recompilar el código PHP	estado del propio OPcache en el servidor

Este inventario es la parte del trabajo que más se salta y la que más resultados invalida. Sin él no se puede afirmar qué capa se está midiendo, y cualquier mejora observada podría venir de otra que nadie tocó.

Preparar rutas

Selecciona un conjunto pequeño y representativo: portada, una landing comercial, un artículo, una página con funcionalidad dinámica y una ruta no cacheable si existe. Cinco rutas bien elegidas dicen más que treinta escogidas al azar, porque cada una representa una plantilla y un patrón de consulta distintos.

Usa contenido estable durante toda la prueba y evita URLs con parámetros que cambien la clave de caché: un parámetro de seguimiento puede convertir cada petición en un fallo de caché y hacer que la pasada caliente nunca lo sea. Documenta si hay autenticación, cookies o consentimiento de por medio, porque muchas configuraciones desactivan la caché de página para usuarios con sesión y esa diferencia explica resultados aparentemente contradictorios.

Pasada fría

Purga únicamente el entorno de prueba, confirma que el estado es el esperado y ejecuta una solicitud controlada. Registra resolución DNS, establecimiento de conexión, negociación TLS, tiempo hasta el primer byte, transferencia, código de respuesta y, si hay instrumentación disponible, consultas a base de datos y memoria. Nunca purgues producción sin autorización explícita: una purga completa en hora punta traslada toda la carga al origen de golpe.

La pasada fría es la más difícil de repetir bien, porque después de la primera petición el sistema ya está caliente. Cada medición fría exige purgar de nuevo, y purgar de nuevo tiene coste. Por eso conviene decidir de antemano cuántas repeticiones se van a hacer y aceptar que serán menos que en la serie caliente. Anota esa asimetría en el informe en lugar de disimularla.

Pasada caliente

Repite exactamente la misma URL en las mismas condiciones y confirma con la cabecera o con la evidencia acordada que la capa esperada ha respondido. Ejecuta varias veces y conserva la distribución completa. Un valor anómalo se mantiene y se explica; no se elimina por conveniencia, porque muchas veces es la única pista de un problema intermitente.

Elige también la herramienta con criterio y no la cambies a mitad. Una petición desde línea de comandos mide la respuesta del servidor sin ejecutar nada del navegador; una herramienta de auditoría en navegador mide además el trabajo de la página. Las dos son legítimas y responden a preguntas distintas, así que sus números no se comparan entre sí ni se anotan en la misma columna. Sea cual sea, deja escrito el comando exacto con sus opciones: la mayoría de las discrepancias entre dos mediciones del mismo sitio se explican por una opción distinta y no por un cambio real.

Descarta la primera petición posterior a la purga como calentamiento y déjalo escrito. Y comprueba que la serie caliente lo es de verdad: si el tiempo de vida configurado es corto y la prueba se alarga, algunas peticiones caerán en fría sin avisar y la distribución mostrará dos grupos separados. Esa bimodalidad es información, no ruido.

Validar contenido

Compara un hash del HTML o un conjunto de elementos clave para detectar una caché obsoleta. Una respuesta muy rápida que devuelve la versión anterior de la página no es un buen resultado: es un fallo de invalidación que el benchmark acaba de premiar.

Después de cada despliegue, la lectura debe confirmar tres cosas por separado: que el origen sirve la versión nueva, que la caché pública ya la ha recogido y que la configuración persiste tras el reinicio del servicio. Son tres comprobaciones distintas y la primera pasa con frecuencia mientras las otras dos fallan en silencio durante horas.

Una respuesta muy rápida que devuelve la versión anterior de la página no es un buen resultado: es un fallo de invalidación que el benchmark acaba de premiar.

Comparaciones que sí son válidas

Dos candidatos son comparables solo cuando comparten ruta, contenido, cliente, red, región y política de caché. Si una variable cambia, se anota y el resultado pasa a ser otra serie, no una fila más de la misma tabla. El orden de ejecución también importa: alternar los candidatos reduce el riesgo de que una mejora de la red o una bajada de carga del sistema favorezca siempre al que se midió después.

Hay comparaciones que no son válidas por mucho que se repitan. Un entorno local contra un servidor compartido no mide lo mismo, y una configuración con LiteSpeed no equivale a otra pila aunque los números salgan parecidos. Una prueba desde una conexión doméstica no compara servidores, compara rutas de red. Estas limitaciones no invalidan la medición: la acotan, y por eso deben figurar en el informe en lugar de omitirse.

Informe

El informe incluye versión del software, fecha, ubicación desde la que se mide, herramienta y comandos exactos, rutas probadas, número de pasadas, mediana, peor valor y limitaciones conocidas. Con esos campos otra persona puede repetir la prueba; sin ellos, el resultado es una anécdota fechada.

Conserva todas las muestras, no solo la mejor: es la misma disciplina que hace creíble auditar la propia web conservando los defectos. Una mediana sin dispersión puede esconder respuestas muy lentas que son precisamente las que sufre una parte de las visitas. Y no mezcles tiempo de servidor con carga visual: el tiempo hasta el primer byte es una métrica de diagnóstico, no una de las Core Web Vitals, cuyos umbrales de referencia en campo son LCP de 2,5 segundos, INP de 200 milisegundos y CLS de 0,1 en el percentil 75. Un servidor rápido con una plantilla pesada puede seguir fallando la experiencia; el método de medición de Core Web Vitals separa lo que corresponde a cada plano, y el servicio de SEO técnico integra el resultado con el resto del diagnóstico de rendimiento.

En cuatro láminas

Fría y caliente. Columnas: Qué mide, Qué invalida el resultado. Pasada fría: Qué mide → Cuánto cuesta generar la respuesta; Qué invalida el resultado → Que el sistema ya esté caliente por la petición anterior. Pasada caliente: Qué mide → Cuánto cuesta servirla ya construida; Qué invalida el resultado → Una respuesta rápida con contenido antiguo

shell: $ curl -s -o /dev/null \ / -w "%{time_starttransfer} %{http_code}\n" URL / 0.412 200 # fría: primera petición / 0.038 200 # caliente / 0.041 200 # caliente / 0.039 200 # caliente / / # series separadas; se apunta qué capa respondió

0 muestras descartadas. Un valor anómalo se mantiene y se explica: muchas veces es la única pista de un problema intermitente.

Errores frecuentes

• Promediar pasadas frías y calientes en una sola cifra que no describe ningún escenario real.
• Medir una vez cada candidato y decidir con esa comparación.
• Purgar producción para hacer una prueba y trasladar toda la carga al origen sin avisar.
• Interpretar una respuesta rápida como éxito sin comprobar que el contenido servido es el actual.
• Eliminar el valor anómalo porque «estropea la media».
• Comparar el entorno local con producción y presentar la diferencia como mejora del código.
• No registrar qué capa respondió, con lo que la mejora no se puede atribuir a nada.

Preguntas habituales

¿Puedo dar una media de las pasadas frías y calientes?

Esa media no describe ningún escenario real: nadie visita la web en un estado intermedio. Son dos series separadas que responden a preguntas distintas —cuánto cuesta generar la respuesta y cuánto cuesta servirla ya construida— y se presentan por separado, cada una con su dispersión.

Una respuesta muy rápida, ¿es siempre buena señal?

No si el contenido servido es antiguo. Una caché que devuelve en milisegundos una versión caducada es un fallo, no un buen resultado, y en un benchmark aparece como la mejor cifra de la tabla. Por eso cada medición comprueba también qué se sirvió, no solo cuánto tardó.

¿Puedo purgar producción para hacer la prueba?

Se puede, pero traslada toda la carga al origen de golpe y eso tiene consecuencias para quien esté navegando en ese momento. Si se hace, se avisa y se elige la franja; si no, se mide sobre una ruta acotada en lugar de vaciarlo todo.

¿Qué hago con una pasada anómala?

Mirarla antes de tocarla. Eliminarla porque «estropea la media» borra justo la información que explica la dispersión: una caché fría no prevista, un vecino ruidoso, una purga en curso. Se registran todas las muestras y se dice qué capa respondió en cada una; sin eso, ninguna mejora se puede atribuir.

Próximo paso

Empieza por el inventario de capas: proveedor, clave, tiempo de vida, purga y evidencia observable de cada una. Es la única parte del protocolo que no se puede improvisar durante la medición, y suele revelar por sí sola configuraciones solapadas que explican comportamientos raros sin necesidad de ningún benchmark.

Con el inventario cerrado, define las rutas, escribe el comando exacto que vas a ejecutar y haz una prueba de ensayo completa antes de recoger datos buenos. Esa pasada en falso sirve para comprobar que las cabeceras identifican la capa correcta y que la purga hace lo que dice hacer, que son los dos supuestos que más veces fallan.

Fuentes

• web.dev, Core Web Vitals — documentación oficial.
• Chrome for Developers, informe de experiencia de usuario (CrUX) — documentación oficial.

Servicio relacionado

Si esto es lo que te está pasando, auditoría seo es el trabajo que lo resuelve. Diagnóstico primero, prioridades después.

Ver auditoría seo