Medir el beneficio del almacenamiento en caché JSON

Mide el almacenamiento en caché JSON progresivo con la misma URL pública en condiciones controladas en frío y en caliente. Una puntuación general de velocidad de página no puede aislar el trabajo de base de datos, renderizado y arranque que ahorra este subsistema.

Definir la pregunta

Entre las preguntas útiles se incluyen:

  • ¿Cuánto más rápida es la segunda solicitud al origen que la primera?
  • ¿Cuánto procesamiento de servidor evita la entrega temprana de PHP en comparación con la alternativa de WordPress?
  • ¿La entrega directa de Apache proporciona una ganancia adicional significativa?
  • ¿Con qué frecuencia solicitan los visitantes lotes que ya se han generado?
  • ¿Una purga automática de todo el sitio crea un pico temporal inaceptable?

Elige una pregunta por prueba. De lo contrario, las aciertos de CDN, la reutilización del navegador y el comportamiento del origen pueden confundirse.

Seleccionar rutas representativas

Prueba algo más que el archivo más pequeño. Incluye:

  • un lote de archivo estándar común;
  • un lote más profundo con plantillas de elementos enriquecidas;
  • un lote dividido por término, si se utiliza;
  • una ruta traducida;
  • una ruta próxima a la respuesta JSON normal más grande;
  • una ruta de alto tráfico que importe operativamente.

Conserva siempre la URL exacta entre las solicitudes en frío y en caliente. Cambiar el hash de contexto, el prefijo de idioma, el número de página o los elementos por página crea una entrada de caché distinta.

Establecer la línea base en frío

  1. Abre POM Cache → General → Progressive JSON tools.
  2. Selecciona Delete Progressive JSON Cache.
  3. Asegúrate de que el CDN se omita mediante un método de prueba de origen aprobado;
  4. Utiliza una sesión sin iniciar sesión y sin cookie de carrito ni de contraseña;
  5. Solicita una vez la URL limpia elegida .json;
  6. Registra el estado, el tamaño de la respuesta, el tiempo de servidor y el tiempo de respuesta total;
  7. Confirma X-POM-Progressive-Archive-Cache: generated-cacheable;
  8. Confirma que el recuento de archivos JSON aumenta.

Este es el coste de generación bajo demanda. Si la respuesta indica generated-dynamic, no es un candidato válido para esta comparación.

Medir un acierto temprano de PHP

Mantén:

  • Progressive JSON cache habilitado;
  • PHP early static serving habilitado;
  • la regla JSON opcional de Apache deshabilitada para esta fase.

Solicita la URL idéntica varias veces y confirma:

X-POM-Cache: Served static JSON cache from PHP; phase=early

Registra los tiempos de la mediana y de la cola más lenta en lugar de elegir solo la solicitud más rápida. La diferencia con respecto a la solicitud en frío representa el trabajo ahorrado de WordPress, consultas, plantillas y codificación, más cualquier cambio en el coste del sistema de archivos.

Medir la alternativa de WordPress

Para una comparación controlada:

  1. Deshabilita PHP early static serving;

  2. Mantén WordPress read fallback habilitado;

  3. Solicita el mismo archivo almacenado;

  4. Confirma:

    X-POM-Progressive-Archive-Cache: hit
  5. Registra los tiempos;

  6. Vuelve a habilitar la entrega temprana de PHP después de la prueba.

La alternativa debería ahorrar la generación del archivo, pero sigue pagando el coste de la solicitud de WordPress. Es normal que sea más lenta que un acierto temprano de PHP.

Medir Apache por separado

Una vez que la línea base de PHP sea estable, instala el bloque JSON de Apache revisado y repite la prueba de origen. Confirma que Apache sirvió realmente el archivo; la sola ausencia de la cabecera de PHP no es evidencia suficiente.

Compara:

Estado ¿WordPress cargado? ¿Archivo renderizado?
Generación dinámica Sí Sí
Acierto de alternativa de WordPress Sí No
Acierto temprano de PHP Sin arranque completo No
Acierto directo de Apache Sin PHP No

Esta comparación revela si la complejidad operativa adicional de una regla de servidor está justificada en tu origen.

Mantener los resultados del CDN por separado

Un acierto del CDN mide el borde, no POM Cache. Ejecútalo como un segundo experimento:

  1. Verifica primero la respuesta actual del origen;
  2. Solicita la URL pública del visor;
  3. Registra las cabeceras de estado de caché y edad del CDN;
  4. Repite después del s-maxage configurado;
  5. Limpia el JSON del origen y observa si el borde aún conserva una copia anterior;
  6. Prueba el procedimiento documentado de invalidación del CDN.

No infieras la frescura del origen a partir de un acierto rápido en el borde.

Observar la regeneración tras una purga

Para un archivo de alto tráfico, mide el breve período posterior al vaciado:

  • cuántas rutas JSON distintas se regeneran;
  • cuánto tarda el conjunto de trabajo en calentarse de forma natural;
  • si las primeras solicitudes concurrentes aumentan la carga de PHP o de la base de datos;
  • si la invalidación automática de todo el sitio se activa con más frecuencia de la que necesita el flujo de trabajo de contenido.

POM Cache no tiene precargador integrado. La primera solicitud a cada ruta después de un vaciado es dinámica.

Informar del resultado con honestidad

Documenta:

  • fecha y entorno;
  • ruta y modo de archivo;
  • tamaño en bytes de la respuesta;
  • conmutadores de tiempo de ejecución activos;
  • si se omitió Apache o el CDN;
  • estado de cookies y autenticación;
  • recuentos de muestras en frío y en caliente;
  • latencia de la mediana y de la cola;
  • observaciones de base de datos o PHP disponibles en tu monitorización aprobada;
  • la frecuencia de invalidación esperada en producción.

Evita una afirmación universal como «el almacenamiento en caché JSON hace que todos los archivos sean un 90 % más rápidos». Un resultado defendible está vinculado a la ruta probada y a la capa de entrega.

Si la solicitud en caliente no llega a la capa prevista, resuélvelo con How a JSON cache request is served antes de utilizar las cifras.