Análisis de dispositivos móviles de PageSpeed Insights

PageSpeed Insights analiza una página para comprobar que siga nuestras recomendaciones enfocadas a poder publicar una página en menos de un segundo en una red para móviles. Según nuestros estudios, cualquier espera superior a un segundo provoca que el usuario pierda el hilo de sus ideas y, por lo tanto, la experiencia es deficiente. Nuestro objetivo es mantener la implicación del usuario en la página y ofrecer una experiencia óptima, sea cual sea el dispositivo o el tipo de red.

No es fácil que todo el contenido de una página se cargue en menos de un segundo, pero por suerte, tampoco es necesario. De hecho, tan solo hay que renderizar y mostrar el contenido situado en la mitad superior de la página en menos de un segundo; de este modo, los usuarios pueden empezar a utilizarla cuanto antes. El resto de la página puede ir renderizándose progresivamente y en segundo plano mientras los usuarios se encuentran en la primera página de contenido.

Adaptación a redes para móviles de latencia alta

Cumplir el criterio de la mitad superior en un segundo en los dispositivos móviles plantea dificultades específicas que no se encuentran en otras redes. Puede que los usuarios accedan a tu sitio web mediante diferentes redes 2G, 3G y 4G. Las latencias de red son considerablemente más altas que las de una conexión por cable y consumen gran parte del margen de 1000 ms dentro del cual debería renderizarse el contenido de la mitad superior de una página.

El tipo de red 4G es el predominante a escala mundial, por lo que deberías asumir que la mayoría de los usuarios accederán a tu página a través de una red de ese tipo y que, por tanto, las solicitudes de red tardarán 100 ms de media.

Con estos datos en mente, veamos el proceso previo. En una secuencia de comunicación habitual entre un navegador y un servidor, se pierden 300 ms en tareas de la red: una petición de DNS para resolver el nombre de host (por ejemplo, google.com) en una dirección IP, un ciclo de ida y vuelta de red para hacer el handshake de TCP y una conexión TLS opcional. Una vez terminado todo esto, quedan 700 ms.

Renderizar páginas en menos de un segundo

Después de restar la latencia de la red, solo quedan 700 ms de tiempo y todavía hay trabajo que hacer: el servidor tiene que procesar la respuesta, el código de aplicación de cliente debe ejecutarse y el navegador tiene que ordenar y renderizar el contenido. Sabiendo esto, los siguientes criterios deberían ayudarnos a no sobrepasar la marca de un segundo:

(1) El servidor tiene que publicar la respuesta (< 200 ms).
El tiempo de respuesta del servidor es lo que tarda un servidor en devolver el código HTML inicial, sin tener en cuenta el tiempo de transporte de la red. Como tenemos muy poco tiempo, se debe intentar minimizar. Lo ideal serían 200 ms y, a poder ser, menos.
(2) El número de redirecciones debe minimizarse.
Las redirecciones HTTP adicionales pueden añadir uno o dos ciclos de ida y vuelta más (dos si hay que hacer otra petición de DNS), lo que supone cientos de milisegundos de latencia extra en las redes 4G. Por este motivo, recomendamos encarecidamente que los webmasters minimicen el número de redirecciones y, si es posible, que las eliminen completamente. Es especialmente importante seguir esta recomendación en documentos HTML; evita redirecciones a páginas para móviles (que empiezan por "m.") siempre que puedas.
(3) El número de ciclos de ida y vuelta para la primera publicación se debe minimizar.

Debido a la forma en la que el protocolo TCP calcula la capacidad de una conexión (es decir, Slow Start de TCP), una nueva conexión TCP no puede utilizar de inmediato todo el ancho de banda disponible entre el cliente y el servidor. Dada esta limitación, el servidor puede enviar hasta 10 paquetes de TCP en una conexión nueva (~14 kB) en el primer ciclo de ida y vuelta; una vez enviados estos datos, tiene que esperar a que el cliente los acepte para aumentar el margen de congestión y empezar a entregar más datos.

Ten en cuenta que el límite de 10 paquetes (IW10) es una novedad del estándar TCP, por lo que debes asegurarte de que tu servidor esté actualizado a la versión más reciente para sacar provecho de este cambio. De lo contrario, es probable que el límite solo sea de 3 o 4 paquetes.

A causa de este comportamiento del protocolo TCP, es importante que optimices tu contenido para minimizar el número de ciclos de ida y vuelta que se necesitan para entregar los datos con los que hacer el primer renderizado de una página. Lo ideal es que el contenido de la mitad superior de una página no supere los 98 KB; de este modo, los navegadores pueden empezar a mostrar elementos visuales después de tan solo tres ciclos de ida y vuelta, lo que deja tiempo suficiente para que el servidor responda y la página se renderice en el cliente.

(4) Se deben evitar archivos JavaScript y CSS externos que bloqueen el renderizado en el contenido de la mitad superior de las páginas.

Para que un navegador pueda mostrar páginas a los usuarios, primero tiene que analizarlas. Si encuentra un script no asíncrono o externo que bloquee la visualización del contenido durante el análisis, debe detenerse y descargar el recurso. Cada vez que se encuentra con uno, se crea un ciclo de ida y vuelta de red que retrasa el primer renderizado de las páginas.

A consecuencia de esta situación, los archivos JavaScript y CSS que se necesitan para ofrecer la región de la parte superior visible deben estar insertados y los archivos JavaScript o CSS necesarios para añadir funciones adicionales a la página se deben cargar después de que el contenido de la parte superior se haya mostrado.

(5) Reserva tiempo para la ordenación y el renderizado en el navegador (200 ms).
El proceso de análisis de HTML y de CSS y la ejecución de JavaScript supone tiempo y recursos del cliente. Dependiendo de la velocidad del dispositivo móvil y de la complejidad de la página, este proceso se puede prolongar durante cientos de milisegundos. Te recomendamos que reserves 200 ms para la sobrecarga del navegador.
(6) Optimiza el tiempo de ejecución y renderizado de JavaScript.
Las secuencias de comandos complicadas y el código ineficaz pueden tardar decenas o centenares de milisegundos en ejecutarse. Con las herramientas para desarrolladores integradas en el navegador Chrome, puedes perfilar y optimizar el código. Para obtener una introducción de gran utilidad a estas herramientas, echa un vistazo a nuestro curso interactivo sobre las herramientas para desarrolladores de Chrome.

Preguntas frecuentes

Utilizo una biblioteca JavaScript, como jQuery. ¿Qué me recomendáis?
Muchas bibliotecas JavaScript, como jQuery, se utilizan para mejorar las páginas y, así, hacerlas más interactivas y añadirles animaciones y otros efectos. Sin embargo, muchos de estos comportamientos se pueden añadir después de que el contenido de la mitad superior de la página se haya mostrado. Prueba a ejecutar y cargar este JavaScript una vez que se haya cargado la página.
Uso un entorno de JavaScript para crear la página. ¿Qué me recomendáis?
Si generas el contenido de páginas mediante JavaScript de cliente, prueba a insertar los módulos de JavaScript correspondientes en el código HTML para evitar que se produzcan ciclos de ida y vuelta de red adicionales. Del mismo modo, si aprovechas el renderizado por parte de servidores, es posible que se mejore significativamente el rendimiento de la primera carga de página. Para hacerlo, procesa las plantillas de JavaScript en el servidor, inserta los resultados en el HTML y, a continuación, usa las plantillas de cliente.
¿Cómo identifico el CSS importante de mi página?
En las Herramientas para desarrolladores de Chrome, abre el panel "Auditorías" y ejecuta el informe de rendimiento de la página web. En el informe que se genere, busca la opción para suprimir reglas CSS no utilizadas. Otra opción es utilizar cualquier otra herramienta de terceros o un script para identificar qué selectores de CSS se aplican en cada página.
¿Estas prácticas recomendadas se pueden automatizar?
Por supuesto. Hay muchos productos de optimización del rendimiento web, ya sean comerciales o de código abierto, que te pueden ayudar a cumplir todos o parte de los criterios descritos anteriormente. Si te interesan las soluciones de código abierto, echa un vistazo a las herramientas de optimización de PageSpeed.
¿Cómo modifico mi servidor para cumplir estos criterios?
En primer lugar, comprueba que el servidor tenga en ejecución una versión actualizada del sistema operativo. Para poder aprovechar el mayor periodo de congestión de TCP inicial (IW10), necesitarás un núcleo Linux 2.6.39+. En el caso de otros sistemas operativos, consulta la documentación.
Para optimizar el tiempo de respuesta del servidor, prepara tu código o utiliza una solución de supervisión de la aplicación para identificar el cuello de botella; por ejemplo, el tiempo de ejecución de creación de secuencias de comandos, las llamadas a la base de datos, las solicitudes de RPC, la publicación, etc. El objetivo es mostrar la respuesta HTML en menos de 200 ms.
¿Qué sucede con la política de seguridad del contenido?
Si utilizas la política de seguridad de contenido, puede que tengas que actualizar tu política predeterminada.
En primer lugar, siempre que puedas, evita insertar atributos CSS en elementos HTML (por ejemplo, &lt p style=...&gt), ya que, al hacerlo, a menudo se duplica código de manera innecesaria. Además, la política de seguridad de contenido bloquea estos atributos de forma predeterminada. Puedes inhabilitar este bloqueo incluyendo "unsafe inline" en "style-src". Si la política de seguridad de contenido está habilitada, bloqueará todas las etiquetas de secuencias de comandos insertadas de forma predeterminada. Si tienes JavaScript incrustado, tienes que actualizar la política de seguridad del contenido para utilizar valores de seguridad (nonces) o hashes de script, o bien utilizar “unsafe-inline” para activar todas las secuencias de comandos incrustadas que se tienen que ejecutar. Si tienes estilos incrustados, tendrás que actualizar la política de seguridad del contenido para utilizar valores de seguridad (nonces) o hashes de estilo, o bien utilizar "unsafe-inline" para permitir que todos los bloques de estilo incrustados se procesen.

¿Tienes más dudas? Haz preguntas y comentarios en nuestro foro temático.