Abres la portada, visitas un producto y todo responde enseguida. Sin embargo, un cliente afirma que la web tarda. Las dos experiencias pueden ser ciertas: tu visita usa tu dispositivo, conexión, ubicación, cookies y, a menudo, una caché ya preparada. Un usuario nuevo con un móvil medio recorre otro camino.
La investigación no consiste en decidir quién tiene razón, sino en encontrar la condición que separa las visitas rápidas de las lentas.
Definir exactamente qué significa «lento»
Pide una URL, una acción y un momento concretos. No es lo mismo una pantalla en blanco inicial que una imagen principal tardía, un menú bloqueado, una búsqueda lenta o un checkout que se detiene tras introducir la dirección.
Cada síntoma apunta a una capa diferente. Un primer byte lento puede proceder de PHP, MySQL o una API; una página que llega rápido pero tarda en reaccionar suele exigir revisar imágenes, CSS, JavaScript, fuentes y terceros. Instalar otro plugin de optimización antes de aislar el retraso puede ocultar la causa.
Comparar caché fría y caliente
Tus visitas repetidas pueden aprovechar HTML en caché, recursos guardados en el navegador, DNS resuelto, conexión TLS abierta y el nodo CDN ya poblado. El primer visitante quizá no tenga ninguna de esas ventajas.
Prueba la URL exacta en una ventana privada, aunque eso no garantiza que la caché del servidor o CDN esté vacía. Comprueba las cabeceras:
curl -I https://example.com/pagina/Busca valores como cache-control, age, x-cache, cf-cache-status o la cabecera propia del hosting. Si una petición repetida muestra HIT y la primera MISS, ya existe una diferencia medible.
Separar el servidor de la carga visual
Mide el tiempo hasta el primer byte aparte del tiempo total:
curl -s -o /dev/null
-w 'DNS: %{time_namelookup}snConexión: %{time_connect}snTLS: %{time_appconnect}snPrimer byte: %{time_starttransfer}snTotal: %{time_total}sn'
https://example.com/pagina/En PowerShell utiliza curl.exe. Repite la medición varias veces; una sola ejecución no demuestra nada. Si el primer byte es alto de forma consistente, revisa WordPress, PHP, consultas MySQL, llamadas externas y capacidad del hosting. Si el HTML comienza pronto pero la página aparece tarde, analiza el trabajo del navegador.
Probar desde la ubicación y el dispositivo del público
Una web alojada en Europa puede parecer inmediata en Barcelona y tardar mucho más en América o Australia. Prueba desde una región parecida a la del visitante y compara primer byte, Largest Contentful Paint, bytes transferidos, número de peticiones, estado de caché y recurso más lento.
Un portátil moderno con fibra también oculta trabajo que un teléfono tarda en descargar, interpretar y dibujar. En las herramientas del navegador aplica una vista móvil y limitación razonable de CPU y red. Revisa si:
- la imagen principal empieza a descargarse demasiado tarde;
- se envía una imagen de escritorio a una pantalla estrecha;
- un script ocupa el hilo principal;
- las fuentes bloquean el texto;
- el gestor de consentimiento retrasa funciones;
- el diseño salta cuando llegan recursos tardíos.
Comparar usuarios conectados y visitantes nuevos
Los administradores suelen probar con la sesión abierta. Muchos sistemas excluyen de la caché las peticiones con cookie de usuario; además, la barra de administración y ciertos plugins añaden recursos. A la vez, algunos anuncios, consentimientos o scripts públicos pueden no ejecutarse para el administrador.
Compara cuatro estados: administrador conectado, usuario desconectado, primera visita sin cookies y visita repetida con recursos cacheados. Optimiza el recorrido comercial afectado, no el estado que produzca la cifra más llamativa.
Entender laboratorio y usuarios reales
PageSpeed Insights puede mostrar una prueba de laboratorio controlada y datos de campo agregados de visitas reales de Chrome. Pueden discrepar porque cambian dispositivos, redes, ubicaciones, páginas, caché, consentimiento y periodo histórico.
Comprobar plantillas y recorridos distintos
WordPress no es una sola página. Crea un conjunto reducido con portada, página de servicio, landing más pesada, búsqueda, producto, carrito, checkout y área de cuenta cuando existan.
Si solo falla una plantilla, una migración o cambio global de caché resulta excesivo. Un producto puede enviar todas sus variaciones mediante JavaScript mientras el resto del sitio funciona bien. Reparar esa plantilla es más seguro que reconstruir toda la configuración.
También busca presión intermitente: copias, cron, picos de tráfico o falta de procesos PHP pueden hacer que la web funcione bien justo cuando el administrador la revisa.
Conservar evidencias antes de cambiar
No apiles plugins, minificación y varias cachés ni cambies de servidor sin un caso rápido y otro lento comparables. Esos cambios pueden romper JavaScript, cachear páginas dinámicas de WooCommerce y borrar la evidencia original.
Anota URL, país, dispositivo, hora, primera o sucesivas visitas, estado de sesión, cascada disponible y cambios recientes. Añade cabeceras de una petición rápida y otra lenta. No envíes contraseñas inicialmente.
El resultado correcto no es que la portada alcance 95 una vez. Es que el recorrido del visitante afectado mejore de forma medible y se entienda por qué. La solución puede ser reducir el primer byte, corregir imágenes adaptables, retirar trabajo del navegador, excluir checkout de la caché o reprogramar una tarea pesada. El cambio mínimo verificado suele ser más fiable que activar un paquete completo de optimizaciones.