Análisis para móviles en 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 cumplir el margen de tiempo de un segundo. Por suerte, no es necesario publicar toda la página dentro de ese margen, sino que hay que ofrecer y publicar el contenido situado en la mitad superior en menos de un segundo, así el usuario puede empezar a utilizar la página cuanto antes. Después, mientras el usuario interpreta la primera página de contenido, el resto de la página se puede publicar de forma progresiva y en segundo plano.

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 al sitio por una serie de redes 2G, 3G y 4G diferentes. Las latencias de la red son considerablemente más altas que las de una conexión por cable y consumen una gran parte del margen de 1.000 ms disponible para publicar el contenido de la mitad superior:

  • trayecto de ida y vuelta de 200-300 ms en redes 3G,
  • trayecto de ida y vuelta de 50-100 ms en redes 4G.

El tipo de red 3G es el dominante a escala internacional y, aunque la implantación de 4G está en proceso en todo el mundo, deberías dar por supuesto que la mayoría de los usuarios accederá a la página a través de una red 3G. Por eso tenemos que dar por sentado que cada solicitud de red tardará una media de 200 ms.

Teniendo esa información en mente, veamos el proceso previo. Si observamos un modelo de secuencia de comunicación entre un navegador y un servidor, 600 ms de ese tiempo ya se han empleado en la sobrecarga de la red: una búsqueda DNS para resolver el nombre de host (por ejemplo, google.com) en una dirección IP, un trayecto de ida y vuelta de la red para realizar la presentación de TCP y, por último, un trayecto de ida y vuelta completo de la red para enviar la solicitud HTTP. Esto nos deja tan solo 400 ms.

Ofrecer la experiencia de publicación inferior a un segundo

Después de restar la latencia de la red, nos quedan 400 ms en el margen de tiempo y aún queda mucho que hacer: el servidor tiene que publicar la respuesta, el código de aplicación del cliente se tiene que ejecutar y el navegador tiene que ordenar y publicar el contenido. Con esa información en mente, los criterios siguientes deberían ayudarnos a mantenernos dentro del margen de tiempo:

(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 se deben minimizar.
Las redirecciones HTTP adicionales pueden añadir uno o dos trayectos de ida y vuelta más (dos si se necesita una búsqueda DNS adicional), lo que supone cientos de milisegundos de latencia más en las redes 3G. Por eso, recomendamos a los webmasters que minimicen el número de redirecciones y, a poder ser, que los eliminen completamente. Sobre todo es importante para el documento HTML (evita las redirecciones a páginas para móviles siempre que se pueda).
(3) El número de trayectos 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 trayecto de ida y vuelta y después tiene que esperar a que el cliente envíe un acuse de recibo de estos datos antes de poder aumentar el intervalo de congestión y pasar a ofrecer más datos.

Debido a este comportamiento del protocolo TCP, es importante optimizar el contenido a fin de minimizar el número de trayectos de ida y vuelta necesarios para ofrecer los datos necesarios para realizar la primera publicación de la página. Lo ideal es que el tamaño del contenido de la mitad superior sea inferior a 14 KB, así el navegador puede delinear la página después de tan solo un trayecto de ida y vuelta. Además, es importante tener en cuenta que el límite de 10 paquetes (IW10) es una novedad de la norma de TCP, por lo que debes asegurarte de que el 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 baje a 3-4 paquetes.

(4) Se debe evitar el bloqueo de JavaScript y CSS externos en el contenido de la mitad superior.

Para que un navegador pueda mostrar una página al usuario, antes debe analizarla. 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 sucede esto, se crea un nuevo flujo de datos en la red que retrasa la carga de la página.

A consecuencia de esta situación, los archivos JavaScript y CSS que se necesitan para ofrecer la región de la mitad superior 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 mitad superior se haya entregado.

(5) Reserva tiempo para la ordenación y la publicación en el navegador (200 ms).
El proceso de análisis de HTML y de CSS y la ejecución de JavaScript suponen 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 publicación y la ejecución de JavaScript.
Los scripts complicados y el código ineficaz pueden tardar decenas y centenares de milisegundos en ejecutarse. Utiliza herramientas de desarrollador insertadas en el navegador para perfilar y optimizar el código. Para obtener una introducción de gran utilidad, echa un vistazo a nuestro curso interactivo para Herramientas de desarrollador de Chrome.

Preguntas frecuentes

¿Qué cambios suponen las redes 4G respecto a los criterios para móviles anteriores?
Las latencias menores en los trayectos de ida y vuelta son una de las mejoras esenciales en las redes 4G. Son de gran ayuda, ya que reducen el tiempo total de sobrecarga de la red, que en estos momentos supone el 50% de nuestro margen de un segundo en las redes 3G. Sin embargo, el tipo de red 3G es el dominante en todo el mundo y así será durante los próximos años, por lo que hay que optimizar las páginas teniendo en cuenta a los usuarios de redes 3G.
Utilizo jQuery como biblioteca JavaScript. ¿Qué me recomendáis?
Muchas bibliotecas JavaScript, como jQuery, se utilizan para mejorar la página y añadir más interactividad, 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 cambiar el momento de la ejecución y la carga del JavaScript correspondiente después de que cargue la página.
Uso un entorno de JavaScript para la construcción de la página. ¿Qué me recomendáis?
Si el contenido de la página se construye mediante JavaScript en el equipo cliente, entonces deberías probar a insertar los módulos de JavaScript correspondientes en el código HTML para evitar flujos de datos adicionales en la red. Del mismo modo, si el procesamiento se realiza en el servidor, es posible que mejore significativamente el tiempo de la primera carga de la página. Para ello, procesa las plantillas de JS en el servidor, inserta los resultados en el código HTML y luego usa las plantillas del equipo cliente cuando se haya cargado la aplicación.
¿Qué ayuda proporcionan SPDY y HTTP 2.0?
Tanto SPDY como HTTP 2.0 tienen como objetivo reducir la latencia de la carga de la página. Para ese fin, utilizan la conexión TCP subyacente de forma más eficiente (multiplexado, compresión del encabezado, priorización). Además, la inserción de servidor puede eliminar la latencia de red adicional para contribuir a mejorar el rendimiento. Te recomendamos que sigas estudiando la posibilidad de añadir compatibilidad con SPDY en los servidores y que cambies a HTTP 2.0 cuando la norma esté a punto.
¿Cómo identifico el CSS esencial 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, instrumenta 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 scripts, 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 del contenido, puede que tengas que actualizar la política predeterminada.
En primer lugar, los atributos CSS en línea de los elementos HTML (por ejemplo, &lt p style=...&gt) se deben evitar siempre que sea posible, ya que a menudo duplican el código sin necesidad. Además, la Política de seguridad del contenido los bloquea de forma predeterminada (se desactivan con “unsafe inline” en “style-src”). Si la Política de seguridad del contenido está activada, de forma predeterminada bloqueará todas las etiquetas de scripts en línea. Si tienes JavaScript en línea, tienes que actualizar la Política de seguridad del contenido para utilizar valores de seguridad (nonces) o hashes de script o tienes que utilizar “unsafe-inline” para activar todos los scripts en línea que se tienen que ejecutar. Si tienes estilos en línea, tendrás que actualizar la Política de seguridad del contenido para utilizar valores de seguridad (nonces) o hashes de estilo o tendrás que utilizar "unsafe-inline" para permitir que todos los bloques de estilo en línea se procesen.

¿Tienes alguna otra pregunta? No dudes en preguntar y en aportar comentarios en nuestro grupo de debate situado en pagespeed-insights-discuss.