La carga de JavaScript y CSS externos son las fuentes más comunes de retraso en la web
En los últimos años se han hecho grandes avances en la comprensión y optimización de rendimiento de la web móvil. Sin embargo, en la mayor parte, la navegación web móvil sigue siendo lenta. Datos de Google Analytics muestran que algunas página web tienen en promedio más de 10 segundos en cargar en el móvil. Sabemos que el proceso de pensamiento de un usuario se interrumpe normalmente después de esperar un segundo, lo que resulta en que el usuario empieza a estar a disgusto. Así que, como mínimo, el contenido de una página web "por encima del pliegue" debe mostrarse en menos de un segundo. Está claro que todavía tenemos mucho trabajo que hacer.
Pero ¿dónde debemos enfocar nuestra atención al optimizar el rendimiento web para móviles? Sabemos que las redes móviles tienen características de latencia y ancho de banda muy variables, y que en general la latencia de la red móvil es sustancialmente mayor que la de las conexiones de escritorio. También sabemos que para las redes modernas el tiempo de ida y vuelta, no el ancho de banda, es el factor dominante en el tiempo de carga de página. Ante esto, para que la web móvil vaya rápida, nuestra atención debe centrarse en reducir al mínimo el número de bloqueos en los viajes generados antes de que una página web pueda mostrar su contenido en la pantalla del dispositivo.
¿Qué bloques de una página web se representan en la pantalla?
En primer lugar, echemos un vistazo a la secuencia de eventos que se dan entre la vez que un usuario inicia una navegación de la página y el tiempo que el navegador puede hacer que la página se muestre en la pantalla. La ida y vuelta se puede incurrir para la resolución DNS, conexión TCP, y la solicitud de que se envían al servidor y la respuesta que se transmiten de vuelta. Lamentablemente no hay mucho que puedan hacer los desarrolladores para evitar estas idas y vueltas. Para los visitantes que repiten una TTL DNS puede ayudar, pero la conexión TCP y los gastos generales de solicitud/respuesta se incurren en cada nueva navegación a una página (suponiendo que no hay conexión TCP caliente lista para ser reutilizada por el cliente).
Una vez que se incurre en estos viajes iniciales el dispositivo móvil puede comenzar a analizar la respuesta HTML. Pero el navegador no puede pintar contenido a la pantalla por el momento. Antes de que contenido en el HTML se pueda pintar a la pantalla, el navegador debe construir el árbol de render para determinar donde aparecerán en la pantalla los elementos en el DOM. Y antes de que el árbol de render pueda ser construido, se debe construir el árbol DOM. El árbol DOM se construye a través de una combinación de análisis de HTML y posiblemente la ejecución de JavaScript.
¿Cuáles son las cosas que bloquean el análisis de HTML, la construcción del árbol DOM, y hacen la construcción del árbol? La mayoría de las veces, el análisis, el árbol DOM, y hacer la construcción del árbol son muy rápidos. Sin embargo, hay algunos antipatrones que pueden causar que estos procesos se bloquean en la red.
Fuentes de retraso durante la representación: JavaScript y CSS externo
La fuente más importante de retraso durante el análisis de HTML es el JavaScript externo. Cuando un navegador encuentra un script externo (no asíncrono) durante el análisis de HTML, debe detener el análisis sintáctico de HTML posterior hasta que el JavaScript esté descargado, analizado y ejecutado. Esto incurre en idas y vueltas adicionales, que son especialmente caras en el móvil. Si el script se carga desde un nombre de host que no sea el nombre de host que sirve el HTML, se puede incurrir en viajes adicionales para la resolución DNS y la conexión TCP.
Además, hacen que la construcción del árbol se bloquee en las hojas de estilo, por lo que al igual que el JavaScript externo introduce retrasos durante la construcción del árbol DOM, las hojas de estilo externas introducen retrasos durante la construcción del árbol de render.
En resumen, JavaScript y CSS externos cargados temprano en el documento (por ejemplo, en el <head> ) son asesinos del rendimiento, y son especialmente caros en el móvil debido a los tiempos de ida y vuelta más altos asociados a las redes móviles.
Creación de páginas móviles rápidas
Para ser rápida, una página web móvil debe incluir todo el contenido necesario para hacer que la región "por encima del pliegue" haga la carga útil HTML inicial sin bloqueat los recursos externos de JavaScript o CSS. Idealmente, todo el contenido necesario para hacer la carga por encima de la región de plegado debe estar en los primeros 15KB en la red (esto es el tamaño de compresión post-gzip; pre-gzip puede ser mayor), ya que este es el tamaño de la ventana inicial de saturación en núcleos modernos en Linux. Esto no significa simplemente que todo el JavaScript y CSS que se utiliza deba ser cargado externamente. En cambio, sólo el código JavaScript y CSS necesario para hacer que la región por encima del plegado debe ser inline y el JavaScript o CSS necesario para añadir funcionalidad adicional a la página se deben cargar de forma asincrónica. Por ejemplo, si tenemos una página como la siguiente:
<html>
<head>
<link rel="stylesheet" href="/my.css">
<script src="/my.js"></script>
</head>
<body>
<div class="main">
Here is my content.
</div>
<div class="leftnav">
Perhaps there is a left nav bar here.
</div>
...
</body>
</html>
Tenemos que identificar las partes de my.js y my.css necesarios para hacer que el contenido inicial inline esas partes, y retrasar o
cargar asincronamente el restante JavaScript y CSS necesario para la página. Esto puede terminar en algo como:
<html>
<head>
<style>
.main { ... }
.leftnav { ... }
/* ... cualquier otro estilo necesario inicial colocarlo aquí ... */
</style>
<script>
// Todos los script necesarios para inicial render aquí.
// Idealmente, no debería haber JS necesario para el render inicial
</script>
</head>
<body>
<div class="main">
Here is my content.
</div>
<div class="leftnav">
Tal vez hay una barra de navegación izquierda aquí.
</div>
...
<!--
NOTA: el retardo en la carga de la escritura y la hoja de estilo puede hacerse mejor
en una devolución de llamada asincrónica como `requestAnimationFrame`
en lugar de en línea en HTML, ya que la devolución de llamada se invoca
después de que el navegador ha renderizado el contenido HTML anterior a la pantalla.
-->
<link rel="stylesheet" href="/my_leftover.css">
<script src="/my_leftover.js"></script>
</body>
</html>
El estado actual de la web móvil
Un breve repaso de páginas web para móviles muestra que casi todas las páginas incluyen el bloqueo de JavaScript o CSS externos antes que aparezca cualquier contenido. Las excepciones incluyen Google Maps, Google Search, Yahoo! Noticias, y sitios como http://www.yummly.com/ y Kayak. Desafortunadamente, algunos de estos sitios tienen JavaScript y CSS que no es necesario para el procesamiento inicial, lo que retrasa innecesariamente el tiempo que se necesita para mostrar estas páginas.
Curiosamente, navegar por la web móvil con JavaScript deshabilitado revela que a pesar de que la mayoría de las páginas se cargan bloqueando el JavaScript externo en el head, algunas de estas páginas realmente necesitan JavaScript para renderizar su contenido inicial. Estas páginas se beneficiarían de con una carga retrasada o asíncrona de su JavaScript para obtener el código JavaScript de la ruta crítica al procesamiento inicial de la página.
¿Qué más puede bloquear el inicio de procesamiento de una página web?
La carga de JavaScript y CSS externos son las fuentes más comunes de retraso en la web. Sin embargo, hay otras fuentes comunes de retraso que los desarrolladores móviles deben tener en cuenta. Una fuente son las redirecciones HTTP del documento HTML principal. Estas redirecciones incurren viajes adicionales, y si la redirección se desplaza a un nombre de host diferente (por ejemplo www.example.com a m.example.com ), añaden aún mayores retrasos debidos a los plazos de resolución de DNS y de conexión TCP. Una segunda fuente de retardo es el tiempo gastado por el servidor en generar la respuesta HTML. Todo el tiempo dedicado a la generación de la respuesta HTML inicial bloqueará la representación en la pantalla, así que el tiempo backend del servidor debe mantenerse al mínimo.
Representación en menos de un segundo
Si estimamos que el tiempo de ida y vuelta de una red 3G es 250 ms, se puede calcular el tiempo estimado mínimo entre cuando un usuario inicia una navegación de la página web y cuando esa página hace se muestre el contenido por encima del pliege en la pantalla. Suponiendo que no hay bloqueo de JavaScript o CSS externos, incurrimos en tres circuitos para DNS, TCP, y solicitud/respuesta, para un total de 750 ms, más 100 ms para el tiempo de back-end. Esto nos lleva a 850ms. Mientras se bloquea el JavaScript y CSS, que se colocarán en línea y el tamaño de la carga útil HTML inicial se mantiene a un mínimo (por ejemplo, en virtud de 15kb comprimido), el tiempo que se necesita para analizar y hacer debe estar bien bajo 100 ms, con lo que nos colocamos en 950ms, justo por debajo de nuestra meta.
Resumen
En resumen, para que tu página web para móviles cargue en menos de un segundo, debes:
• mantener bajo el tiempo backend del servidor para generar HTML a un mínimo (menos de 100 ms)
• evitar redirecciones HTTP para el principal recurso HTML
• evitar el bloqueo de JavaScript y CSS externo de carga antes de la render inicial
• inline sólo el Javascript y CSS necesario para la render inicial
• cargar retrasada o asincrónica de cualquier JavaScript y CSS que no se precisan para la render inicial
• mantener la carga útil HTML necesaria para representar el contenido inicial de bajo 15KB comprimido
Si estás buscando mejorar el rendimiento de tus páginas web para móviles debes intentarlo con estas optimizaciones.
