Has pasado tu web por PageSpeed Insights y, entre todos los diagnósticos, aparece uno que quizá no habías visto antes:
Document Request Latency.
El nombre suena bastante técnico, pero el problema que describe es mucho más sencillo de entender de lo que parece.
Antes de que tu WordPress pueda mostrar imágenes, textos, botones o prácticamente cualquier otra cosa, el navegador necesita solicitar el documento HTML inicial de la página.
Si esa primera respuesta tarda demasiado, todo empieza más tarde.
Y aquí viene lo importante: ver este aviso no significa automáticamente que necesites cambiar de hosting, instalar otro plugin de caché o empezar a modificar archivos de WordPress.
Primero hay que averiguar dónde se está perdiendo el tiempo.
En esta guía vamos a hacerlo paso a paso, incluso si nunca has utilizado herramientas de desarrollo ni sabes qué significa TTFB.
¿Qué significa Document Request Latency?
Imagina que entras en un restaurante.
Te sientas, haces tu pedido y la cocina tarda mucho tiempo simplemente en empezar a prepararlo.
Después puede que los camareros sean rapidísimos, pero ya hemos perdido un tiempo precioso antes de comenzar.
En una web sucede algo parecido.
Cuando escribes una dirección en el navegador, este solicita al servidor el documento principal de la página.
Simplificando mucho, ocurre esto:
Tu navegador → servidor → WordPress → HTML → navegador
Una vez recibido ese HTML, el navegador puede empezar a descubrir y solicitar muchos de los demás recursos necesarios para construir la página.
Por eso la petición inicial es tan importante.
Google explica que el resto de solicitudes de red y el contenido de la página dependen de esta solicitud inicial.
Si empieza tarde, estamos poniendo un freno al principio de todo el proceso.
¿Por qué PageSpeed muestra este aviso?
Aquí tenemos una buena noticia: no necesitamos investigar cien posibilidades desde el principio.
Document Request Latency comprueba principalmente tres situaciones:
- La petición inicial ha sufrido una o más redirecciones.
- El servidor ha tardado demasiado en responder.
- El documento HTML se está enviando sin compresión.
Por tanto, nuestro trabajo inicial consiste en responder tres preguntas:
¿Estoy haciendo redirecciones innecesarias?
¿Mi servidor tarda demasiado en empezar a responder?
¿El HTML está llegando comprimido?
Mucho más manejable, ¿verdad?
Document Request Latency no significa automáticamente que tu hosting sea malo
Es una conclusión muy tentadora.
PageSpeed dice que el servidor responde lentamente y pensamos:
“Necesito un hosting más rápido.”
Puede ser.
Pero todavía no lo sabemos.
WordPress no es simplemente un conjunto de archivos HTML esperando a que alguien los descargue.
Dependiendo de cómo esté configurada la web, cuando llega una petición pueden intervenir PHP, WordPress, el theme, plugins, consultas a la base de datos y otros procesos antes de generar la página que finalmente recibirá el navegador.
También puede existir una caché que evite realizar buena parte de ese trabajo.
Por eso cambiar de servidor sin diagnosticar el problema puede significar gastar dinero y descubrir después que el verdadero cuello de botella estaba en otro sitio.
Primero medimos. Después tocamos.
Esa será nuestra regla durante toda esta guía.
Cómo comprobar de dónde viene la latencia
PageSpeed Insights nos ha avisado de que existe un problema.
Ahora necesitamos investigar un poco más.
Podemos empezar con una herramienta que probablemente ya tienes instalada: Google Chrome.
Abre tu web con Chrome.
Pulsa F12 para abrir las herramientas para desarrolladores.
También puedes hacer clic con el botón derecho sobre la página y seleccionar Inspeccionar.
Busca la pestaña:
Network
o Red, dependiendo del idioma de Chrome.
Recarga ahora la página.
Verás aparecer muchas filas.
No te preocupes si parece complicado. No necesitamos entenderlas todas.
Entre esas peticiones nos interesa especialmente la correspondiente al documento HTML principal.
Normalmente aparecerá con el nombre de tu dominio o de la página que estás visitando y con un tipo similar a document.
Ese es nuestro punto de partida.
1. Comprueba si hay redirecciones antes de llegar a WordPress
Imagina esta situación:
http://ejemplo.com
te lleva a:
https://ejemplo.com
y esta después a:
https://www.ejemplo.com
El usuario termina viendo la página correcta, pero el navegador ha tenido que recorrer varios pasos antes de conseguirla.
Es como llegar a una oficina y que te digan:
“Es en la segunda planta”.
Subes y allí te dicen:
“No, perdona, es en el edificio de enfrente”.
Finalmente llegas, pero hemos perdido tiempo innecesariamente.
Una redirección puede ser perfectamente necesaria. El problema son las redirecciones evitables o las cadenas de varias redirecciones antes de alcanzar el documento definitivo.
¿Qué puedes revisar?
Comprueba cuál es la URL definitiva de tu WordPress.
Por ejemplo:
https://tudominio.com
Si todos tus enlaces internos apuntan ya directamente hacia esa dirección, evitamos obligar al navegador a pasar innecesariamente por versiones anteriores de la URL.
También conviene comprobar que no estamos creando cadenas del tipo:
HTTP → HTTPS → WWW → URL final
cuando podrían resolverse de una forma más directa.
No elimines redirecciones simplemente porque existen. Algunas son necesarias para mantener URLs antiguas, migraciones o cambios de estructura.
Nuestro objetivo no es tener cero redirecciones a cualquier precio.
Es evitar viajes innecesarios antes de cargar la página correcta.
2. Comprueba cuánto tarda el servidor en responder
Esta suele ser una de las partes más interesantes del diagnóstico.
Volvamos a:
Chrome → DevTools → Network
Selecciona la petición correspondiente al documento HTML.
Busca ahora el apartado:
Timing
Entre los diferentes tiempos encontrarás uno relacionado con la espera de la respuesta del servidor.
Aquí estamos empezando a acercarnos a una métrica que seguramente encontrarás muchas veces al optimizar WordPress:
TTFB — Time To First Byte.
No necesitas memorizar el nombre.
La pregunta que nos interesa es muchísimo más sencilla:
¿Cuánto tiempo pasa desde que pedimos la página hasta que empieza a llegar la respuesta?
Si la mayor parte del tiempo se está consumiendo esperando al servidor, ya tenemos una pista importante.
Y también podemos descartar otras cosas.
Por ejemplo, imagina que tienes una fotografía de 800 KB dentro del artículo.
Optimizar esa fotografía puede ser una excelente idea para mejorar otros aspectos del rendimiento.
Pero no solucionará por sí sola un servidor que tarda demasiado en empezar a entregar el HTML inicial.
Acabamos de hacer algo muy importante:
hemos dejado de optimizar a ciegas.
¿Cuánto tiempo considera excesivo PageSpeed?
Aquí conviene diferenciar dos conceptos que pueden confundirse.
El diagnóstico Document Request Latency considera problemático que el servidor tarde más de 600 ms en responder.
Por otro lado, puedes encontrar referencias a unos 800 ms para TTFB.
No son exactamente la misma medición.
El TTFB puede incluir otros tiempos, como la resolución DNS y las redirecciones, además del tiempo de respuesta del propio servidor.
Por eso no debemos convertir los 600 ms en una especie de frontera mágica donde 599 ms significa “web perfecta” y 601 ms significa “web lenta”.
Utilízalo como una señal para investigar.
Nuestro objetivo no es perseguir números porque sí.
Queremos descubrir qué está esperando el usuario y si podemos reducir esa espera.
3. ¿Por qué puede tardar WordPress en generar la página?
Aquí es donde la investigación empieza a ser especialmente interesante.
Si hemos descubierto que existe bastante tiempo de espera antes de recibir el HTML, podemos empezar a preguntarnos qué está ocurriendo dentro de WordPress.
Hay varias posibilidades.
Plugins
Cada plugin añade alguna funcionalidad.
Eso no significa que tener muchos plugins convierta automáticamente una web en lenta.
Un WordPress con 25 plugins pequeños y bien programados puede funcionar perfectamente, mientras que una única extensión puede realizar operaciones costosas y aumentar considerablemente el tiempo necesario para generar determinadas páginas.
Por eso la pregunta correcta no es:
“¿Cuántos plugins tengo?”
sino:
“¿Alguno de estos plugins está provocando trabajo innecesario o especialmente pesado?”
Y aquí tampoco recomiendo empezar desactivando plugins al azar en una web en producción.
Primero diagnostica.
El theme
El theme también participa en la generación de la página.
Un tema ligero y bien construido puede facilitar mucho las cosas.
En cambio, un theme excesivamente complejo puede añadir funcionalidades, consultas y procesamiento que no necesitamos.
Eso no significa que debas cambiar inmediatamente de plantilla.
Significa simplemente que el theme también forma parte de la ecuación.
Base de datos
WordPress utiliza una base de datos para almacenar gran parte de su información.
Para construir una página puede necesitar realizar diferentes consultas.
Una base de datos grande tampoco es automáticamente una base de datos lenta.
Lo que nos interesa descubrir es si existen consultas costosas, datos cargados innecesariamente o algún comportamiento anómalo que esté retrasando la generación de la página.
PHP y servidor
WordPress necesita ejecutar PHP.
La versión utilizada, la configuración del servidor, los recursos disponibles, la carga del servidor y otros factores pueden afectar al tiempo de respuesta.
Aquí ya entramos en una zona algo más técnica.
Si eres principiante, no necesitas empezar modificando PHP ni la configuración del servidor.
Lo importante en esta primera fase es saber que el problema puede estar ahí.
4. La caché puede cambiar completamente la situación
Vamos con uno de los conceptos más importantes de rendimiento WordPress.
Imagina que WordPress necesita preparar un plato cada vez que llega un visitante.
Tiene que consultar ingredientes, cocinarlo, emplatarlo y finalmente servirlo.
Ahora imagina que para determinadas peticiones podemos tener el resultado ya preparado.
Eso, simplificando muchísimo, es una de las ventajas que puede proporcionarnos la caché de página.
En lugar de ejecutar todo el proceso de WordPress para cada visita, determinados visitantes pueden recibir una versión del HTML que ya estaba preparada.
Eso puede reducir enormemente el trabajo necesario antes de empezar a enviar la página.
Pero aquí aparece uno de los errores más habituales al intentar mejorar WordPress:
“Mi web va lenta, así que voy a instalar un plugin de caché.”
Puede funcionar.
Pero seguimos sin saber cuál era el problema.
Y todavía peor:
“Sigue lenta, instalaré otro plugin de optimización.”
Ahora podemos terminar teniendo varias herramientas intentando hacer lo mismo.
Una caché.
Otra minificación.
Una optimización de JavaScript.
Otra optimización de CSS.
Y cuando algo se rompe resulta mucho más difícil averiguar quién lo ha provocado.
Mi recomendación es mucho más sencilla:
diagnóstico → cambio → medición.
Una modificación cada vez siempre que sea posible.
5. Comprueba si el documento HTML está comprimido
Hay una tercera comprobación importante dentro de Document Request Latency.
La compresión.
El HTML es texto.
Y el texto puede comprimirse antes de viajar desde el servidor hasta el navegador.
Piensa en un archivo que ocupa, por ejemplo, 100 KB.
Si podemos transmitir una versión comprimida mucho más pequeña y el navegador sabe descomprimirla, necesitaremos transferir menos información.
No significa que todos los documentos vayan a reducirse en la misma proporción. Es simplemente la idea que necesitamos comprender.
¿Cómo puedo comprobarlo?
Vuelve a:
DevTools → Network
Selecciona el documento HTML.
Entra en:
Headers
Busca un encabezado parecido a:
content-encoding: br
o:
content-encoding: gzip
Eso indica que el servidor está utilizando un sistema de compresión compatible para entregar el documento.
Si PageSpeed te está avisando de que el documento no está comprimido, tendrás que revisar la configuración de tu servidor, CDN o sistema de caché.
Google recomienda específicamente habilitar la compresión de texto en el servidor para WordPress.
Si eres principiante y no sabes qué servidor utiliza tu hosting, no cambies configuraciones al azar.
Ya has conseguido algo muy valioso: identificar exactamente qué parte debes revisar.
Cómo reducir Document Request Latency en WordPress
Llegados a este punto podemos ordenar las soluciones de una manera mucho más lógica.
No existe un botón universal llamado “solucionar Document Request Latency”.
La solución depende de lo que hayamos encontrado.
Si tienes redirecciones innecesarias
Revisa que tus enlaces internos apunten directamente a las URLs definitivas.
Comprueba también la configuración HTTP/HTTPS y WWW/no-WWW de la instalación.
Si existen redirecciones históricas necesarias, mantenlas.
Lo que queremos eliminar son saltos innecesarios, no redirecciones legítimas.
Si WordPress tarda demasiado en generar la página
Aquí tendremos que profundizar.
Entre otras cosas, puede ser necesario revisar:
- plugins;
- theme;
- consultas a la base de datos;
- configuración de caché;
- versión y configuración de PHP;
- recursos del servidor;
- llamadas externas;
- funcionamiento del hosting.
No intentes optimizar todas esas cosas simultáneamente.
Busca primero el cuello de botella más evidente.
Si no tienes caché de página
Estudia la posibilidad de implementarla correctamente.
Muchos hostings ofrecen sistemas de caché propios y también existen excelentes plugins para WordPress.
Pero más no significa mejor.
Si tu hosting ya dispone de un sistema de caché a nivel de servidor, comprueba cómo debe integrarse con WordPress antes de instalar varias soluciones adicionales.
Si el HTML no está comprimido
Comprueba si tu hosting permite activar Brotli o gzip.
También puede encargarse de ello una CDN o alguna capa de infraestructura situada delante de WordPress.
Lo importante es verificar después que realmente funciona.
No basta con activar una casilla.
Cambia → mide → confirma.
Si el problema es el servidor
También puede ocurrir.
Si después de optimizar WordPress y configurar correctamente la caché seguimos encontrando tiempos de respuesta elevados, tendremos que investigar la infraestructura.
Puede que el servidor esté saturado, tenga pocos recursos o simplemente no sea adecuado para las necesidades de esa web.
En ese momento sí tiene sentido valorar un cambio de hosting.
Pero ahora la decisión se basa en un diagnóstico.
No en una suposición.
Cuidado: mejorar PageSpeed también puede romper WordPress
Existe una tentación bastante comprensible cuando empezamos con PageSpeed:
activar todo lo que diga “optimizar”.
Minificar CSS.
Combinar archivos.
Retrasar JavaScript.
Eliminar CSS.
Lazy load.
Precargar recursos.
Caché.
CDN.
Todo activado.
Y entonces desaparece el menú.
O un formulario deja de funcionar.
O el diseño cambia.
O aparece un error que antes no existía.
La optimización de rendimiento no consiste en activar el máximo número posible de opciones.
Consiste en conseguir que la web haga el trabajo necesario de la forma más eficiente posible.
Si una opción nos hace ganar una cantidad irrelevante de rendimiento a cambio de volver inestable la página, quizá no sea una buena optimización.
¿Tengo que conseguir 100 en PageSpeed?
No.
Un 100 puede ser fantástico, pero no debería convertirse en una obsesión.
PageSpeed es una herramienta de diagnóstico extraordinariamente útil, pero nuestro objetivo real es conseguir una web rápida, estable y agradable para las personas que la utilizan.
Una puntuación de laboratorio tampoco representa todas las condiciones posibles de todos tus visitantes.
Por eso prefiero utilizar PageSpeed como un médico utiliza determinadas pruebas:
para encontrar pistas y tomar mejores decisiones.
No para perseguir un número sin entender lo que estamos cambiando.
¿Document Request Latency afecta al LCP?
Puede hacerlo.
Recuerda el proceso:
Navegador → documento HTML → descubrimiento de recursos → renderizado
Si el documento inicial tarda mucho en llegar, el navegador puede empezar más tarde a descubrir otros elementos importantes de la página.
Entre ellos podría estar el elemento que finalmente se convierta en el Largest Contentful Paint (LCP).
Esto no significa que reducir Document Request Latency vaya a solucionar automáticamente cualquier problema de LCP.
El LCP puede estar afectado por otros muchos factores.
Pero comenzar antes suele ser mejor que comenzar después.
Lo que puedes comprobar tú mismo aunque seas principiante
Si has llegado hasta aquí, ya puedes realizar un diagnóstico inicial bastante útil sin ser desarrollador.
Puedes:
- ejecutar PageSpeed Insights;
- localizar Document Request Latency;
- abrir Network en Chrome;
- identificar la petición del documento;
- comprobar si existen redirecciones;
- observar cuánto tarda la respuesta;
- comprobar si existe compresión;
- revisar si tienes algún sistema de caché.
Y, sobre todo, puedes hacer algo todavía más importante:
dejar de instalar soluciones al azar.
No necesitas convertirte en especialista en servidores para mejorar el rendimiento de tu WordPress.
Necesitas aprender a formular la pregunta correcta.
Diagnóstico rápido de Document Request Latency
Cuando PageSpeed me muestra este aviso, seguiría este orden:
1. ¿Existen redirecciones antes de llegar al documento definitivo?
Si existen, comprueba si pueden reducirse.
↓
2. ¿El servidor tarda demasiado en empezar a responder?
Si es así, investiga WordPress, caché, plugins, theme, PHP, base de datos y servidor.
↓
3. ¿El documento HTML está comprimido?
Si no lo está, revisa gzip/Brotli y la configuración del servidor o CDN.
↓
4. Realiza un cambio.
↓
5. Vuelve a medir.
↓
6. Compara.
Este último paso es fundamental.
No optimices confiando únicamente en que “ahora parece más rápido”.
Mídelo.
Lo que no haría para solucionar este problema
No cambiaría de hosting como primera medida.
No instalaría varios plugins de caché.
No activaría todas las opciones de optimización simultáneamente.
No desactivaría plugins aleatoriamente en una web importante en producción.
No modificaría .htaccess, Nginx, PHP o la base de datos sin saber qué estoy intentando corregir.
Y tampoco intentaría solucionar Document Request Latency optimizando cosas que pertenecen a otras fases de la carga simplemente porque PageSpeed también las muestra.
Primero resolvemos una pregunta:
¿Por qué está tardando la petición inicial del documento?
Preguntas frecuentes
¿Document Request Latency y TTFB son lo mismo?
No exactamente.
Están estrechamente relacionados, pero el TTFB puede incluir tiempo empleado en DNS y redirecciones además de la respuesta del servidor.
Por eso PageSpeed puede utilizar referencias diferentes para ambos conceptos.
¿Un plugin de caché soluciona Document Request Latency?
Puede ayudar muchísimo si el problema está relacionado con el tiempo que necesita WordPress para generar la página.
Pero no es una solución universal.
Por ejemplo, no deberíamos esperar que un plugin de caché elimine por arte de magia una cadena de redirecciones mal configurada.
Primero identifica la causa.
¿Necesito cambiar de hosting?
No necesariamente.
Un servidor lento puede ser la causa, pero también pueden existir problemas dentro de WordPress.
Antes de migrar una web completa, comprueba qué está provocando realmente el retraso.
¿600 ms significa que mi WordPress es lento?
No deberíamos interpretar esa cifra de una manera tan absoluta.
Document Request Latency utiliza 600 ms como referencia para el tiempo de respuesta del servidor.
Es una señal útil para investigar, no una sentencia sobre la calidad completa de tu web.
¿Por qué PageSpeed cambia de resultado entre una prueba y otra?
El rendimiento no ocurre en un laboratorio perfectamente idéntico cada segundo.
La carga del servidor, cachés, red y otros factores pueden provocar variaciones.
Por eso es mejor realizar varias mediciones y buscar tendencias en lugar de sacar conclusiones importantes a partir de una única prueba.
En definitiva: primero descubre dónde está el problema
Document Request Latency parece un diagnóstico complicado cuando lo vemos por primera vez en PageSpeed.
Pero ahora podemos traducirlo a tres preguntas bastante sencillas:
¿Estoy perdiendo tiempo en redirecciones?
¿Mi servidor o WordPress tarda demasiado en responder?
¿Estoy enviando el HTML comprimido?
A partir de ahí podemos profundizar todo lo que sea necesario.
Quizá encontremos un problema de caché.
Quizá un plugin.
Quizá PHP.
Quizá la base de datos.
Quizá finalmente descubramos que necesitamos un servidor mejor.
Pero ya no estaremos adivinando.
Y esa es probablemente una de las mejores costumbres que puedes adquirir cuando empiezas a optimizar WordPress:
mide primero, cambia después y vuelve a medir.
.