Análisis de dispositivos móviles en PageSpeed Insights

PageSpeed Insights analiza una página a fin de ver si sigue nuestras recomendaciones para hacer que una página se renderice en menos de un segundo en una red móvil. Las investigaciones demostraron que cualquier demora mayor a un segundo hará que el usuario interrumpa su flujo de pensamiento, lo que creará una mala experiencia. Nuestro objetivo es mantener la participación del usuario en la página y brindar una experiencia óptima, independientemente del dispositivo o del tipo de red.

No es fácil alcanzar el presupuesto de un segundo. Afortunadamente, no es necesario que toda la página se renderice con este presupuesto. En su lugar, debemos entregar y renderizar el contenido de la mitad superior de la página (ATF) en menos de un segundo, lo que permite que el usuario comience a interactuar con la página lo antes posible. Luego, mientras el usuario interpreta la primera página del contenido, el resto de la página se puede publicar de manera progresiva en segundo plano.

Adaptación a redes móviles de alta latencia

Cumplir con los criterios de la ATF de un segundo en los dispositivos móviles plantea desafíos únicos que no están presentes en otras redes. Los usuarios pueden acceder a su sitio a través de diferentes redes 2G, 3G y 4G. Las latencias de red son significativamente más altas que las de una conexión por cable y consumen una parte significativa de nuestro presupuesto de 1, 000 ms para procesar el contenido ATF.

La red 4G es el tipo de red predominante en todo el mundo. Es de esperar que la mayoría de los usuarios accedan a tu página desde una red 4G. Por este motivo, debemos suponer que cada solicitud de red tomará, en promedio, 100 milisegundos.

Con esto en mente, ahora trabajemos hacia atrás. Si observamos una secuencia típica de comunicación entre un navegador y un servidor, la sobrecarga de la red ya usó 300 ms de ese tiempo: una búsqueda de DNS para resolver el nombre de host (p.ej., google.com) a una dirección IP, un recorrido de la red para realizar el protocolo de enlace TCP y una conexión TLS opcional. Esto nos deja 700 ms.

Cómo ofrecer la experiencia de renderización de menos de un segundo

Después de restar la latencia de red, solo nos queda 700 milisegundos de presupuesto, y queda mucho trabajo por hacer: el servidor debe procesar la respuesta, se debe ejecutar el código de la aplicación del cliente y el navegador debe diseñar y procesar el contenido. Con esto en mente, los siguientes criterios nos ayudan a mantenernos dentro del presupuesto:

(1) El servidor debe procesar la respuesta (< 200 ms)
El tiempo de respuesta del servidor es el tiempo que tarda un servidor en mostrar el HTML inicial, sin tener en cuenta el tiempo de transporte de la red. Dado que el tiempo es escaso, el tiempo debe ser mínimo, idealmente en menos de 200 milisegundos.
(2) Minimiza la cantidad de redireccionamientos
Los redireccionamientos HTTP adicionales pueden agregar uno o dos recorridos de red adicionales (dos si se requiere una búsqueda de DNS adicional), lo que genera cientos de milisegundos de latencia adicional en las redes 4G. Por este motivo, recomendamos a los webmasters que minimicen la cantidad de redireccionamientos y que, idealmente, eliminen por completo los redireccionamientos. Esto es muy importante para el documento HTML (evita los redireccionamientos "m punto" siempre que sea posible).
(3) Se debe minimizar la cantidad de recorridos a la primera renderización

Debido a la forma en que TCP estima la capacidad de una conexión (es decir, inicio lento de TCP), una nueva conexión TCP no puede usar de inmediato todo el ancho de banda disponible entre el cliente y el servidor. Debido a esto, el servidor puede enviar hasta 10 paquetes TCP en una nueva conexión (~14 KB) en el primer recorrido y, luego, debe esperar a que el cliente confirme estos datos para poder aumentar su ventana de congestión y proceder a entregar más datos.

Además, es importante tener en cuenta que el límite de 10 paquetes (IW10) es una actualización reciente del estándar TCP: debes asegurarte de que tu servidor esté actualizado a la versión más reciente para aprovechar este cambio. De lo contrario, el límite probablemente sea de 3 a 4 paquetes.

Debido a este comportamiento de TCP, es importante optimizar el contenido para minimizar la cantidad de recorridos necesarios a fin de entregar los datos necesarios para realizar la primera renderización de la página. Idealmente, el contenido de ATF debería ser inferior a 98 KB. Esto permite que el navegador pinte la página después de solo tres recorridos a fin de disponer de tiempo suficiente para la latencia de respuesta del servidor y la renderización del cliente.

(4) Evita el bloqueo externo de JavaScript y CSS en el contenido de la mitad superior de la página

Antes de que un navegador pueda mostrar una página al usuario, tiene que analizarla. Si encuentra una secuencia de comandos externa que no es asíncrona o que bloquea durante el análisis, debe detener y descargar ese recurso. Cada vez que lo hace, se agrega un recorrido de ida y vuelta en la red, lo que retrasará el tiempo hasta que se renderice la página por primera vez.

Como resultado, los elementos JavaScript y CSS necesarios para renderizar la región de la mitad superior de la página deben estar intercalados, y los elementos JavaScript o CSS necesarios para agregar funciones adicionales a la página deberían cargarse después de que se haya entregado el contenido de la ATF.

(5) Reserva tiempo para el diseño y la renderización del navegador (200 ms)
El proceso de analizar el código HTML y CSS, y ejecutar JavaScript requiere tiempo y recursos del cliente. Según la velocidad del dispositivo móvil y la complejidad de la página, este proceso puede tardar cientos de milisegundos. Nuestra recomendación es reservar 200 milisegundos para la sobrecarga del navegador.
(6) Optimiza el tiempo de ejecución y renderización de JavaScript
Las secuencias de comandos complicadas y los códigos ineficientes pueden tardar decenas y cientos de milisegundos en ejecutarse: usa las herramientas para desarrolladores integradas en el navegador a fin de generar perfiles y optimizar tu código. Si quieres obtener una excelente introducción, consulta nuestro curso interactivo sobre las herramientas para desarrolladores de Chrome.

Preguntas frecuentes

Uso una biblioteca de JavaScript, como JQuery, ¿alguna recomendación?
Muchas bibliotecas de JavaScript, como JQuery, se usan para mejorar la página y agregar interactividad, animaciones y otros efectos adicionales. Sin embargo, muchos de estos comportamientos se pueden agregar de forma segura después de que se renderice el contenido de ATF. Investiga cómo mover la ejecución y carga de ese JavaScript hasta después de que se cargue la página.
Uso un framework de JavaScript para construir la página, ¿alguna recomendación?
Si el contenido de la página se construye con JavaScript del cliente, debes investigar la incorporación de los módulos de JavaScript relevantes para evitar recorridos de red adicionales. De manera similar, aprovechar la renderización del servidor puede mejorar significativamente el rendimiento de la carga de la primera página: renderizar plantillas de JS en el servidor, intercalar los resultados en HTML y, luego, usar plantillas del cliente una vez que se cargue la aplicación.
¿Cómo identifico el código CSS esencial en mi página?
En las Herramientas para desarrolladores de Chrome, abre el panel Auditorías y ejecuta un informe de rendimiento de páginas web. En el informe generado, busca Quitar reglas de CSS sin usar. También puedes usar cualquier otra herramienta o secuencia de comandos de terceros para identificar los selectores CSS que se aplican a cada página.
¿Se pueden automatizar estas prácticas recomendadas?
¡Por supuesto! Existen muchos productos de optimización del rendimiento web (WPO) comerciales y de código abierto que pueden ayudarte a cumplir con todos o algunos de los criterios mencionados anteriormente. Para obtener soluciones de código abierto, consulta las herramientas de optimización de PageSpeed.
¿Cómo configuro mi servidor para que cumpla estos criterios?
Primero, asegúrate de que tu servidor ejecute una versión actualizada del sistema operativo. Para aprovechar el aumento del tamaño inicial de la ventana de congestión de TCP (IW10), necesitarás el kernel de Linux 2.6.39+. Para otros sistemas operativos, consulta la documentación.
Para optimizar el tiempo de respuesta del servidor, instrumenta tu código o usa una solución de supervisión de aplicaciones para identificar tu cuello de botella; p.ej., entorno de ejecución de secuencias de comandos, llamadas a la base de datos, solicitudes de RPC, procesamiento, etc. El objetivo es procesar la respuesta HTML en un plazo de 200 milisegundos.
¿Qué pasa con la Política de Seguridad del Contenido?
Si usas CSP, es posible que debas actualizar la política predeterminada.
Primero, intercala los atributos CSS en los elementos HTML(p.ej., < p style=...>) siempre que sea posible, ya que suelen generar una duplicación innecesaria de código y se bloquean de forma predeterminada con la CSP (inhabilitado mediante la opción "intercalada no segura" en "style-src"). Si la CSP está habilitada, bloqueará todas las etiquetas de secuencias de comandos intercaladas de forma predeterminada. Si tienes JavaScript intercalado, deberás actualizar la política de CSP para usar hashes o nonces de secuencias de comandos, o bien usar “unsafe-inline” para habilitar la ejecución de todas las secuencias de comandos intercaladas. Si tienes estilos intercalados, deberás actualizar la política de CSP para usar hashes de estilo o nonces, o bien usar "unsafe-inline" para habilitar el procesamiento de todos los bloques de estilo intercalado.

¿Tienes alguna otra pregunta? No dudes en hacer preguntas y enviar comentarios en nuestro grupo de discusión en pagespeed-insights-discuss.

Comentarios

¿Te sirvió esta página?