La primera visita tarda varios segundos; al actualizar, la página aparece casi al instante. Esto no demuestra simplemente que «la caché funciona». Indica que se paga una vez un coste que después se reutiliza: HTML generado, imagen, fuente, JavaScript, conexión o almacenamiento del navegador.
La reparación depende de cuál de esos costes desaparece.
Reproducir sin confundir las cachés
En una petición pueden participar caché del navegador, página completa, objetos, código PHP, CDN, DNS y conexiones reutilizadas. Una ventana privada elimina parte de los datos locales, pero no vacía necesariamente WordPress ni el nodo CDN.
En una página autorizada, registra la primera carga privada, recarga inmediata, nueva visita después de la caducidad habitual y primera carga desde otra ubicación. No purgues todo antes de cada petición: crearías un caso artificial y perderías la posibilidad de identificar la capa que cambia.
Comparar cabeceras y primer byte
Consulta dos veces el HTML:
curl -I https://example.com/pagina/
curl -I https://example.com/pagina/Busca age, cache-control, cf-cache-status, x-cache, x-litespeed-cache, x-fastcgi-cache o la cabecera del proveedor. Importa si la primera respuesta es MISS y la segunda HIT, no el nombre concreto.
Si ambas son HIT y el navegador mejora mucho al recargar, probablemente se reutiliza un recurso o trabajo local. Si la primera es MISS y el primer byte tarda, investiga la generación de origen.
Puedes medir varias peticiones con un volumen bajo:
for i in 1 2 3; do
curl -s -o /dev/null
-w "petición $i: %{time_starttransfer}sn"
https://example.com/pagina/
doneUn resultado de 2,4 segundos seguido de 0,2 sugiere trabajo del servidor guardado en caché. Tiempos parecidos con una mejora visual indican otra capa. Esto es una comparación diagnóstica, no una prueba de carga.
No esconder un origen lento
La caché de página completa evita que WordPress reconstruya el HTML para cada visita. Es adecuada, pero la ruta sin caché sigue usándose al caducar, publicar, purgar, personalizar o visitar carrito, checkout y cuenta.
Si esa respuesta tarda varios segundos, revisa consultas MySQL, APIs externas, opciones con carga automática, plugins que trabajan en cada petición, procesos PHP disponibles, sistema de archivos y errores repetidos.
Alargar la duración de caché reduce la frecuencia del coste, pero no lo repara.
Detectar fragmentación innecesaria
El sitio puede crear entradas distintas por parámetros, idioma, moneda, dispositivo, cookies, campaña, sesión o variantes de URL. Así, tu prueba acierta la caché mientras muchos visitantes reales obtienen un MISS.
Revisa especialmente parámetros publicitarios y barras finales. No combines respuestas realmente personales o diferentes: elimina claves sin significado, nunca el aislamiento entre clientes.
Revisar los recursos de la primera visita
Si el primer byte es rápido en ambas peticiones, compara las cascadas. En la primera carga anota bytes, imagen principal, fuentes, CSS, JavaScript, terceros y vídeo. En la segunda, observa qué llega desde memoria o disco.
Una imagen de 3 MB puede desaparecer al recargar y crear una falsa sensación de arreglo. Para los nuevos visitantes sigue intacta. Corrige dimensiones y formatos, srcset y sizes, bitrate de vídeos, pesos de fuentes y scripts que no se usan en esa página.
Define caché larga solo para archivos estáticos versionados. Si un recurso cambia bajo la misma URL, el visitante podría conservar una copia rota u obsoleta.
Contar conexiones, fuentes y terceros
La primera visita resuelve DNS y negocia TCP/TLS para el dominio y servicios externos. Analítica, etiquetas, consentimiento, chat, mapas, vídeo, fuentes y publicidad multiplican esos inicios.
Reduce orígenes prescindibles. No añadas preconnect para todos: cada pista consume recursos; resérvala para dominios realmente necesarios al principio.
Si el texto queda invisible la primera vez, revisa familias, pesos, duplicados, política de caché y font-display. Una regla básica puede usar:
@font-face {
font-family: "Brand Sans";
src: url("/fonts/brand-sans-regular.woff2") format("woff2");
font-weight: 400;
font-style: normal;
font-display: swap;
}Comprueba que el cambio de fuente no provoque saltos de diseño.
Comprobar estados especiales
Un *service worker* puede servir recursos guardados después de la primera visita. Revísalo en Application: alcance, URLs controladas y estrategia de actualización. Prueba desregistrarlo solo en una sesión diagnóstica, no para usuarios reales.
También compara visitante nuevo y recurrente, cliente conectado y administrador. La caché suele excluir cookies de WordPress o WooCommerce. Si solo las sesiones abiertas son lentas, optimizar la caché pública no ayudará: hay que revisar petición dinámica, base de datos y recursos de ese estado.
Precalentar sin sobrecargar
El precalentamiento puede reconstruir páginas importantes tras un purgado, pero debe priorizar URLs valiosas, limitar concurrencia y excluir checkout, cuenta, filtros y contenido personal.
Recorrer miles de variantes puede agotar los procesos PHP. Precalentar complementa un origen eficiente; no sustituye su reparación.
Nunca hagas públicamente cacheables carrito, checkout o cuenta para acelerar su primera visita. Verifica con dos sesiones independientes que no se comparten datos y que la respuesta dinámica es rápida.
Secuencia de reparación
Reproduce la diferencia, compara primer byte, identifica HIT o MISS, revisa la cascada de recursos y localiza el mayor coste que desaparece. Cambia solo esa capa, conserva reversión y vuelve a probar primera visita, recarga y recorridos dinámicos.
Para una evaluación reúne URL, tiempos, cabeceras, estado de sesión, dispositivo, navegador, ubicación y cambios recientes. No envíes contraseñas. El objetivo es reparar el coste original, no enterrarlo bajo más capas de caché.