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:
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:
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.
Observación del HTML y estados de visitante que faltan por probar
El 24 de octubre de 2026 a las 23:40 UTC hicimos tres GET por perfil de User-Agent a la versión inglesa de esta guía, desde un cliente Python sin cookies ni autenticación. Los seis devolvieron 200. El tiempo hasta el primer byte del cuerpo fue 149,99; 143,91 y 139,68 ms con User-Agent de escritorio, y 152,73; 130,82 y 149,49 ms con el móvil.
Este tiempo incluye conexión y preparación de la respuesta. No es el TTFB de Navigation Timing, una carga completa ni una comparación de dispositivos reales. No cargamos recursos, ejecutamos JavaScript, vaciamos cachés de producción ni probamos cuentas conectadas. Repetir peticiones no demuestra caché fría o caliente; las huellas del cuerpo variaron, por lo que tampoco acredita contenido idéntico.
La conclusión se limita a esas peticiones anónimas de HTML satisfactorias bajo las condiciones registradas. No descartan lentitud de menú, renderizado móvil o sesión personalizada. La explicación de web.dev sobre laboratorio y campo ayuda a separar esas poblaciones.
Conserva URL y contenido al comparar una visita anónima nueva, una recurrente, el consentimiento y una sesión iniciada autorizada. Registra navegador, viewport, red y evidencia de caché. Los dos experimentos de abajo ya miden el consentimiento guardado y los estados nuevo, recurrente y autenticado con perfiles de escritorio y móvil emulado. El teléfono físico y la acción afectada de un cliente necesitan una reproducción representativa.
Seis cargas reales en escritorio con distintas preferencias guardadas
El 25 de octubre de 2026 cargamos seis veces la versión inglesa de esta guía en Chrome 155 para Windows, a 2560 × 1323 píxeles CSS y relación de píxel 1. Alternamos tres rechazos y tres aceptaciones guardados mediante los controles del sitio, y recargamos desde arriba. Todas las observaciones se mantuvieron en primer plano y usaron el mismo contenido. Son visitas recurrentes de escritorio, no sesiones privadas nuevas ni una comparación con teléfono.
Un observador optativo registró Navigation Timing, pinturas, candidato a LCP y desplazamientos durante unos 15 segundos desde su inicio, o 15,2–15,5 segundos desde la navegación en esta serie. El TTFB de la tabla va del inicio de navegación a responseStart. El observador y su pequeño control añaden trabajo. No se vació la caché del navegador ni se limitó red o CPU; estas recargas no garantizan una caché fría.
Observaciones alternadas en escritorio, 25 de octubre de 2026
Carga / elección guardada
TTFB de navegación (ms)
Candidato a LCP (ms)
Entradas de recursos Google
D1 · Rechazo
130.9
284
2
A1 · Aceptación
120.6
244
2
D2 · Rechazo
464.6
588
2
A2 · Aceptación
101.1
276
2
D3 · Rechazo
123.6
228
2
A3 · Aceptación
107.4
204
2
Los rechazos dieron una mediana del candidato a LCP de 284 ms, con rango de 228 a 588 ms; las aceptaciones, 244 ms, entre 204 y 276 ms. El elemento registrado fue siempre el título del artículo. Las medianas de primera pintura con contenido fueron 284 y 204 ms, respectivamente. El máximo de las ventanas de desplazamiento observado osciló entre 0 y 0,00291. Son observaciones acotadas, no Web Vitals de campo de toda la visita.
El rechazo más lento también tuvo una espera mayor hasta el primer byte. Con tres repeticiones por grupo y rangos de LCP superpuestos, la muestra no demuestra que el consentimiento causara la diferencia. Aporta casos reales que investigar, en lugar de dar un veredicto por la sensación de una persona.
Una solicitud del tag no identifica el consentimiento
Ambos grupos registraron dos entradas de recursos procedentes de Google. La configuración servida fija el consentimiento inicial en denegado y actualiza la elección de analítica cuando se acepta. La documentación de Consent Mode de Google distingue bloquear etiquetas de cargarlas con valores iniciales denegados. El patrón observado encaja con la segunda opción. Esta prueba no inspeccionó contenidos de cookies ni cargas de las peticiones, por lo que no certifica cada señal o proveedor.
Añadimos Preferencias de cookies para reabrir los controles existentes. Para repetir la comparación, elige un estado, vuelve arriba, recarga, mantén la página visible y registra la misma ventana. Anota consentimiento y comportamiento de peticiones junto al tiempo. Retiramos el panel temporal de medición y restauramos el rechazo que tenía inicialmente este navegador.
Este primer experimento compara elecciones de consentimiento guardadas en visitas recurrentes de escritorio. El siguiente utiliza contextos aislados para medir visitas nuevas, recurrentes y con sesión iniciada en escritorio y móvil emulado. Ambos usan la URL inglesa; las traducciones explican las mismas observaciones.
Visita nueva, recurrente y con sesión iniciada: 18 cargas medidas
El «a mí me va rápido» pedía una comparación en condiciones. El 25 de octubre de 2026 cargamos la versión inglesa de esta guía con un contexto anónimo nuevo, una segunda visita en ese mismo contexto y una sesión real de suscriptor de WordPress. Hicimos las tres pruebas en escritorio y móvil emulado, con tres repeticiones por condición. El contenido renderizado del artículo conservó la misma huella SHA-256 en las 18 cargas.
El perfil de escritorio tenía 1440 × 900 píxeles CSS y DPR 1. El de Pixel 7, 412 × 839, DPR 2,625, pantalla táctil y User-Agent móvil, dentro de Chromium 152.0.7977.82 con Playwright 1.63.0. Se usó la misma red del VPS, sin limitar red ni CPU. Es una emulación del comportamiento responsive; no reproduce un teléfono físico ni su procesador. La documentación de Playwright explica el alcance de sus perfiles de dispositivo y el aislamiento del almacenamiento entre contextos.
La revisión destapó un fallo de maquetación móvil. Aunque el perfil estaba configurado a 412 × 839, el viewport de diseño registrado se amplió a 1435 × 2921 en las nueve cargas móviles. Los bloques largos de código ensanchaban una columna de la cuadrícula y el navegador reducía la página para encajarla. La tabla recoge ese comportamiento anterior al arreglo. Después limitamos el ancho de la columna y conservamos el scroll interno de código y tablas. Una nueva revisión visual comprueba el ancho corregido; estos tiempos no son resultados posteriores al arreglo ni una mejora de velocidad demostrada.
Tres cargas por condición · candidato a LCP y CLS en los primeros 15 segundos
Perfil y visita
LCP mediano (rango), ms
TTFB mediano, ms
CLS mediano
Escritorio · Anónima nueva
1108 (1100–1308)
182
0,0092
Escritorio · Anónima recurrente
460 (428–484)
86
0
Escritorio · Sesión iniciada
2224 (1364–2584)
170
0,009
Móvil emulado · Anónima nueva
1020 (1012–1828)
105
0
Móvil emulado · Anónima recurrente
252 (204–276)
86
0
Móvil emulado · Sesión iniciada
1104 (900–1308)
162
0
Las páginas permanecieron en primer plano. Un observador instalado antes de los scripts recogió el candidato a LCP y la mayor ventana de CLS durante los primeros 15 segundos. El TTFB va del inicio de navegación a responseStart. No hubo scroll, clics ni operaciones comerciales. El candidato a LCP fue siempre el H1. Son observaciones acotadas de laboratorio; no equivalen a Core Web Vitals de campo ni miden INP.
Qué podemos sacar de estos números
La segunda visita fue más rápida en las seis parejas. Registró siete recursos con cero bytes transferidos y un tamaño decodificado positivo; los contextos anónimos nuevos no registraron ninguno con esa combinación. Es una señal compatible con reutilización de recursos en el navegador. No separa el efecto de la caché del DNS, las conexiones, la variación de red o el orden fijo de primera y segunda visita. Tampoco demuestra un HIT de caché del servidor sin una cabecera que lo confirme.
La sesión iniciada no era una etiqueta inventada: las seis cargas autenticadas mostraron la barra de WordPress y el enlace de salida. El documento devolvió directivas de caché privadas y no-store. Ese grupo registró 15 recursos, frente a siete u ocho en la visita anónima nueva. La interfaz adicional cambia la experiencia medida; no demuestra que una cookie o un plugin concreto causen la diferencia. Usamos un suscriptor temporal sin permisos de edición y, al terminar, eliminamos la cuenta y revocamos sus sesiones.
La carga nueva más lenta del móvil emulado también esperó 884 ms hasta el primer byte. Una pantalla pequeña no estabiliza la red. Si el problema lo comunica un cliente, toca repetir esta matriz en su dispositivo físico y su conexión, y añadir la acción que falla. Volver a abrir una guía no representa un checkout, un filtro o el área de clientes.
En las 18 visitas el consentimiento de analítica siguió sin elegir y el aviso inicial permaneció visible. La comparación entre aceptación y rechazo está en el bloque anterior. No desplegamos una optimización durante estas mediciones. Esta versión española y la catalana explican el experimento de la URL inglesa; no son muestras de rendimiento independientes.