Un indicador verde de "caché habilitado" no prueba que la respuesta probada provenga del caché. Las cookies iniciadas, cadenas de consulta, sesiones de WooCommerce, variantes móviles o un error de CDN pueden enviar la solicitud de vuelta a través de PHP y MySQL.
Rastree una respuesta pública desde el borde hasta el origen antes de cambiar los plugins o el hosting.
Define la respuesta que estás midiendo
Pruebe una URL pública normal en una sesión privada. Utilice la dirección HTTPS canónica sin parámetros de seguimiento y realice dos o tres solicitudes separadas por unos segundos.
Inspeccionar encabezados:
curl -sS -D - -o NUL https://example.com/service/En Windows, NUL descarta el cuerpo; en Linux o macOS use /dev/null. Ejecute esto sólo en un sitio que usted controle.
Busque encabezados de estado de caché, Age, sincronización del servidor y redirecciones inesperadas. Los nombres de los encabezados difieren entre hosts y CDN, así que interprételos utilizando la documentación del proveedor.
Separar un fallo de un golpe lento
La primera solicitud después de una purga puede legítimamente fallar mientras PHP genera la página. Una segunda solicitud idéntica normalmente debería ser un éxito si la página se puede almacenar en caché.
Si fallan todas las solicitudes, busque el motivo de la omisión. Si los encabezados informan un acierto pero el TTFB permanece alto, inspeccione la ubicación de la CDN, la configuración de la conexión y si el encabezado se refiere a un caché interno mientras otra capa lenta todavía se encuentra al frente.
No promedies los aciertos y errores juntos. Describen dos experiencias diferentes para los visitantes.
Consulta cookies y contenido personalizado
Los cachés de páginas comúnmente omiten a los usuarios y visitantes que han iniciado sesión con cookies de carrito o de sesión. Abra una nueva ventana privada e inspeccione las cookies de solicitud.
Un plugin de marketing o consentimiento puede establecer una cookie que coincida involuntariamente con una regla de omisión amplia. Las páginas de WooCommerce, como el carrito, el proceso de pago y la cuenta, no deben almacenarse en caché como HTML público normal, pero normalmente sí debería hacerlo una página de servicio informativo.
Nunca elimine las exclusiones de comercio electrónico solo para crear un éxito. Confirme si la URL probada contiene contenido personalizado.
Inspeccionar variaciones de URL
Las barras diagonales, los redireccionamientos de HTTP a HTTPS, las variantes de www y los parámetros de seguimiento pueden crear claves de caché independientes. Una herramienta de rendimiento puede probar una URL que redirecciona primero o nunca activa la variante canónica.
Elija una dirección canónica y haga que las cadenas de redireccionamiento sean directas. Decida si los parámetros de marketing inofensivos pueden reutilizar el mismo contenido almacenado en caché utilizando CDN o controles de caché compatibles.
No ignore los parámetros globalmente. Los parámetros de búsqueda, moneda, idioma y vista previa pueden alterar el contenido y necesitan un manejo por separado.
Compare cuidadosamente la CDN y el origen
Si una CDN encabeza el sitio, un error público aún puede llegar a un caché de servidor rápido o a una solicitud PHP sin caché. Utilice diagnósticos del proveedor o una prueba de origen/archivo de hosts autorizada para comparar capas.
No expongas una IP de origen privado ni eludas los controles de seguridad sin permiso. Cuando las pruebas de origen directo no están disponibles, los registros del servidor y los encabezados de tiempo pueden mostrar si la solicitud llega a PHP.
Un caché de borde cerca de una ubicación de prueba no demuestra un comportamiento equivalente en todas las regiones. Verifique una región de visitante relevante cuando sea posible.
Medir la ruta no almacenada en caché
Incluso un caché de página excelente necesita una ruta de error saludable para purgas, páginas nuevas y solicitudes personalizadas. Perfile WordPress en etapa de prueba o con monitoreo de producción con bajos gastos generales.
Divida el tiempo en:
- servidor web y cola PHP;
- Arranque de WordPress;
- consultas de bases de datos;
- llamadas API externas;
- representación de plantillas;
- almacenamiento en caché.
No instale varios plugins de creación de perfiles en un sitio de producción ocupado. Utilice una herramienta controlada y elimínela o desactívela después de recopilar pruebas.
Verificar el calentamiento y la invalidación de la caché
Publique un cambio de preparación inofensivo y confirme que la URL relevante invalida, regenera y luego accede al caché. Un caché que nunca caduca ofrece contenido obsoleto; un caché purgado por cada evento cron nunca permanece recurso.
Revise si un plugin borra todo el caché cada vez que cambia el valor de stock de un producto. La invalidación dirigida puede proteger tanto la frescura como la tasa de aciertos.
Cuándo solicitar una reparación de rendimiento
Solicite una evaluación cuando los encabezados no estén de acuerdo, cada solicitud anónima omita el caché o la ruta perdida sea inusualmente lenta. Comparta la URL pública, los tiempos de solicitud y los encabezados de respuesta sin valores confidenciales.
La reparación debe identificar qué capa responde a cada solicitud, preservar las exclusiones para contenido personalizado y mejorar el origen no almacenado en caché en lugar de informar solo que hay un interruptor de caché activado.