Usé la web por un día con un presupuesto de 50 MB

Este artículo es parte de una serie en la que intento usar la web bajo varias restricciones, que representan un grupo demográfico determinado de usuarios. Espero elevar el perfil de las dificultades que enfrentan las personas reales, que son evitables si diseñamos y desarrollamos de una manera que sea comprensiva con sus necesidades.

La última vez, navegué por la Web durante un día con Internet Explorer 8. Esta vez, navegué por la Web durante un día con un presupuesto de 50 MB.

¿Por qué 50 MB?

Muchos de nosotros tenemos la suerte de tener planes móviles que permiten varios gigabytes de transferencia de datos al mes. De lo contrario, generalmente podemos conectarnos a redes WiFi públicas o domésticas que tienen conexiones de banda ancha rápida y tienen datos ilimitados.

Pero hay partes del mundo donde los datos móviles son prohibitivamente costosos y donde hay poca o ninguna infraestructura de banda ancha.

Las personas a menudo compran paquetes de datos de solo decenas de megabytes a la vez, lo que hace que un gigabyte sea una cantidad de datos relativamente grande y, por lo tanto, costosa para comprar.
— Dan Howdle, analista de telecomunicaciones de consumo en Cable.co.uk

¿Qué tan caro estamos hablando?

El costo de los datos móviles

Un estudio de 2018 realizado por cable.co.uk encontró que Zimbabue era el país más caro del mundo para datos móviles, donde 1 GB cuesta un promedio de $75,20, que oscila entre $12,50 y $138,46. La enorme variedad de precios se debe a que las cantidades más pequeñas de datos son muy caras, y se vuelven proporcionalmente más baratas cuanto mayor es el plan de datos al que se compromete. Puedes leer la metodología del estudio para más información.

Zimbabue no es de ninguna manera una excepción. Guinea Ecuatorial, Santa Elena y las Islas Malvinas son los siguientes, con 1 GB de datos que cuestan $65,83, $55,47 y $47,39 respectivamente. Estos países generalmente tienen una combinación de infraestructura técnica deficiente y baja adopción, lo que significa que los datos son costosos de entregar y no tienen la economía de escala para reducir los costos.

Los datos también son caros en algunas partes de Europa. Un gigabyte de datos en Grecia te costará $32,71; en Suiza, $20.22. A modo de comparación, la misma cantidad de datos cuesta $ 6,66 en el Reino Unido o $ 12,37 en los EE. UU. En el otro extremo de la escala, India es el lugar más barato del mundo para datos, con un costo promedio de $0.26. Le siguen Kirguistán, Kazajstán y Ucrania a $0,27, $0,49 y $0,51 por GB respectivamente.

La velocidad de las redes móviles también varía considerablemente entre países. Quizás sorprendentemente, los usuarios experimentan velocidades más rápidas en una red móvil que WiFi en al menos 30 países en todo el mundo, incluidos Australia y Francia. Corea del Sur tiene la velocidad de descarga móvil más rápida, con un promedio de 52,4 Mbps, pero Irak tiene la más lenta, con un promedio de 1,6 Mbps de descarga y 0,7 Mbps de carga. Estados Unidos ocupa el puesto 40 en el mundo en velocidades de descarga móvil, con alrededor de 34 Mbps, y corre el riesgo de quedarse atrás a medida que el mundo avanza hacia 5G.

En cuanto al tipo de conexión de red móvil, el 84,7 % de las conexiones de usuarios en el Reino Unido son 4G, en comparación con el 93 % en EE. UU. y el 97,5 % en Corea del Sur. Esto se compara con menos del 50% en Uzbekistán y menos del 60% en Argelia, Ecuador, Nepal e Irak.

El costo de los datos de banda ancha

Mientras tanto, un estudio del costo de la banda ancha en 2018 muestra que una conexión de banda ancha en Níger cuesta $263 'por megabit por mes'. Esta métrica es un poco difícil de comprender, así que aquí hay un ejemplo: si el costo promedio de los paquetes de banda ancha en un país es de $22 y la velocidad de descarga promedio que ofrecen los paquetes es de 10 Mbps, entonces el costo 'por megabit por mes' sería ser $2.20.

Es una métrica interesante que reconoce que la velocidad de banda ancha es un factor tan importante como el límite de datos. Un costo de $263 sugiere una combinación de banda ancha extremadamente lenta y extremadamente costosa. Como referencia, la métrica es $1,19 en el Reino Unido y $1,26 en los EE. UU.

Lo que quizás sea más fácil de comprender es el costo promedio de un paquete de banda ancha. Tenga en cuenta que este estudio buscaba los paquetes de banda ancha más baratos en oferta, ignorando si estos paquetes tenían o no un límite de datos, por lo que proporciona una cifra aproximada útil en lugar del costo de los datos en sí.

Solo en el costo del paquete, Mauritania tiene la banda ancha más cara del mundo, con un promedio de $ 768,16 (un rango de $ 307,26 a $ 1368,72). Este enorme costo incluye la construcción de líneas físicas a la propiedad, ya que existen pocas en Mauritania. Con 0,7 Mbps, Mauritania también tiene una de las redes de banda ancha más lentas del mundo.

Taiwán tiene la banda ancha más rápida del mundo, con una velocidad media de 85 Mbps. Yemen tiene el más lento, a 0,38 Mbps. Pero incluso los países con una infraestructura de banda ancha bien establecida tienen los llamados 'no puntos'. El Reino Unido ocupa el puesto 34 entre 207 países en velocidad de banda ancha, pero en julio de 2019 todavía había una escuela en el Reino Unido sin banda ancha.

El costo promedio de un paquete de banda ancha en el Reino Unido es de $39,58 y en los EE. UU. es de $67,69. El promedio más barato del mundo es el de Ucrania, con solo $ 5, aunque la oferta de banda ancha más barata de todas se encontró en Kirguistán ($ 1,27, frente al promedio del país de $ 108,22).

Zimbabue fue el país más costoso para datos móviles, y las estadísticas no son mucho mejores para su banda ancha, con un costo promedio de $128,71 y un costo "por megabit por mes" de $6,89.

Costo absoluto vs costo en términos reales

Todos los costos descritos hasta ahora son los costos absolutos en USD, basados ​​en las tasas de cambio en el momento del estudio. Estos costos no se han tenido en cuenta para el costo de vida, lo que significa que para muchos países el costo es mucho más alto en términos reales.

Voy a limitar mi navegación hoy a 50 MB, lo que en Zimbabue costaría alrededor de $3,67 con una tarifa de datos móviles. Puede que no parezca mucho, pero los maestros en Zimbabue estaban en huelga este año porque sus salarios habían caído a solo $2.50 por día.

A modo de comparación, $ 3,67 es aproximadamente la mitad del salario mínimo de $ 7,25 en los EE. UU. Como zimbabuense, tendría que trabajar alrededor de un día y medio para ganar el dinero para comprar estos datos de 50 MB, en comparación con solo media hora en los EE. UU. No es fácil comparar el costo de vida entre países, pero solo en salarios, el costo de $ 3.67 de 50 MB de datos en Zimbabue se sentiría como $ 52 para un estadounidense con salario mínimo.

Configuración del experimento

Inicié Chrome y abrí las herramientas de desarrollo, donde aceleré la red a una conexión 3G lenta. Quería simular una conexión lenta como las que experimentan los usuarios en Uzbekistán, para ver qué tipo de experiencia me brindan los sitios web. También aceleré mi CPU para simular estar en un dispositivo de gama baja.

Instalé ModHeader y configuré el encabezado 'Guardar datos' para que los sitios web sepan que quiero minimizar mi uso de datos. Este es también el encabezado establecido por Chrome para el 'modo Lite' de Android, que cubriré con más detalle más adelante.

Descargué TripMode; una aplicación para Mac que le permite controlar qué aplicaciones de su Mac pueden acceder a Internet. El acceso a Internet de cualquier otra aplicación se bloquea automáticamente.

¿Hasta dónde preveo que me llevará mi presupuesto de 50 MB? Dado que el peso promedio de una página web es de casi 1,7 MB, eso sugiere que tengo alrededor de 29 páginas en mi presupuesto, aunque probablemente algunas más si puedo permanecer en los mismos sitios y aprovechar el almacenamiento en caché del navegador.

A lo largo del experimento, sugeriré consejos de rendimiento para acelerar la primera pintura con contenido y el tiempo de carga percibido de la página. Es posible que algunos de estos consejos no afecten la cantidad de datos transferidos directamente , pero generalmente implican aplazar la descarga de recursos menos importantes, lo que en conexiones lentas puede significar que los recursos nunca se descargan y los datos se guardan.

El experimento

Sin más preámbulos, cargué google.com, usando 402 KB de mi presupuesto y gastando $0.03 (alrededor del 1% de mi presupuesto de Zimbabue).

En general, no es un mal tamaño de página, pero me preguntaba de dónde venían esas 24 solicitudes de red y si la página podría hacerse más ligera o no.

Página de inicio de Google — DOM

Mirando el marcado de la página, no hay hojas de estilo externas: todo el CSS está en línea.

Consejo de rendimiento n.º 1: CSS crítico en línea

Esto es bueno para el rendimiento, ya que evita que el navegador tenga que realizar una solicitud de red adicional para obtener una hoja de estilo externa, de modo que los estilos se puedan analizar y aplicar de inmediato para la primera pintura con contenido. Aquí se debe hacer una compensación, ya que las hojas de estilo externas se pueden almacenar en caché pero las en línea no (a menos que sea inteligente con JavaScript).

El consejo general es que sus estilos críticos (cualquier cosa que esté en la mitad superior de la página) estén en línea, y que el resto de su estilo sea externo y se cargue de forma asíncrona. La carga asincrónica de CSS se puede lograr en una línea de HTML notablemente inteligente:

 <link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

Los devtools muestran una versión embellecida del DOM. Si desea ver lo que realmente se descargó en el navegador, cambie a la pestaña Fuentes y busque el documento.

Puede ver que hay MUCHO JavaScript en línea aquí. Vale la pena señalar que se ha afeado en lugar de simplemente minimizado.

Consejo de rendimiento n.º 2: minimice y afee sus activos

La minificación elimina espacios y caracteres innecesarios, pero la fealdad en realidad 'destroza' el código para que sea más corto. El signo revelador es que el código contiene nombres de variables breves generados por máquinas en lugar de código fuente intacto. Esto es bueno porque significa que el script es más pequeño y más rápido de descargar.

Aun así, los scripts en línea parecen tener aproximadamente 120 KB del recurso de página de 210 KB (aproximadamente la mitad del tamaño comprimido con gzip de 60 KB). Además, hay cinco archivos JavaScript externos que suman 291 KB de los 402 KB descargados:

Esto significa que JavaScript representa alrededor del 80 por ciento del peso total de la página.

Esto no es JavaScript inútil; Google tiene que tener algunos para mostrar sugerencias a medida que escribe. Pero sospecho que gran parte es código de seguimiento y configuración de publicidad.

A modo de comparación, deshabilité JavaScript y volví a cargar la página:

La versión JS deshabilitada de la búsqueda de Google ocupa solo 102 KB, en lugar de 402 KB. Aunque Google no puede proporcionar sugerencias automáticas en estas condiciones, el sitio sigue funcionando y acabo de reducir mi uso de datos a una cuarta parte de lo que era. Si realmente tuviera que limitar mi uso de datos a largo plazo, una de las primeras cosas que haría sería deshabilitar JavaScript. No es tan malo como parece.

Consejo de rendimiento n.º 3: Menos es más

Incluir, afear y minimizar los activos está muy bien, pero el mejor rendimiento proviene de no enviar los activos en primer lugar.

• Antes de agregar nuevas funciones, ¿tiene un presupuesto de rendimiento?
• Antes de agregar JavaScript a su sitio, ¿se puede lograr su función usando HTML simple? (Por ejemplo, validación de formulario HTML5).
• Antes de incluir una gran biblioteca de JavaScript o CSS en su aplicación, use algo como bundlephobia.com para medir qué tan grande es. ¿Vale la pena la comodidad? ¿Puedes lograr lo mismo usando código Vanilla en un tamaño de datos mucho más pequeño?

Analizando la información del recurso

Hay mucho que desempacar aquí, así que empecemos. Solo tengo 50 MB para jugar, así que voy a aprovechar cada parte de la carga de esta página. Prepárese para un breve tutorial de Chrome Devtools.

402 KB transferidos, pero 1,1 MB de recursos: ¿qué significa eso realmente?

Significa que en realidad se descargaron 402 KB de contenido, pero en su forma comprimida (usando un algoritmo de compresión como gzip o brotli). Luego, el navegador tuvo que trabajar un poco para descomprimirlo en algo significativo. El tamaño total de los datos descomprimidos es de 1,1 MB.

Este desempaquetado no es gratuito: hay algunos milisegundos de sobrecarga al descomprimir los recursos. Pero eso es una sobrecarga insignificante en comparación con el envío de 1,1 MB por cable.

Consejo de rendimiento n.º 4: Comprimir recursos basados ​​en texto

Como regla general, siempre comprima sus activos usando algo como gzip. Pero no utilice la compresión en sus imágenes y otros archivos binarios; debe optimizarlos por adelantado en la fuente. La compresión en realidad podría terminar haciéndolos más grandes.

Y, si puede, evite comprimir archivos de 1500 bytes o menos. El tamaño de paquete TCP más pequeño es de 1500 bytes, por lo que al comprimir a, digamos, 800 bytes, no ahorra nada, ya que todavía se transmite en el mismo paquete de bytes. Nuevamente, el costo es insignificante, pero desperdicia tiempo de CPU de compresión en el servidor y tiempo de CPU de descompresión en el cliente.

Ahora volvamos a la pestaña Red en Chrome: profundicemos en esas prioridades. Tenga en cuenta que los recursos tienen prioridad de "más alta" a "más baja"; estas son las mejores conjeturas del navegador sobre cuáles son los recursos más importantes para descargar. Cuanto mayor sea la prioridad, antes intentará el navegador descargar el activo.

Consejo de rendimiento n.º 5: Proporcione sugerencias de recursos al navegador

El navegador adivinará cuáles son los activos de mayor prioridad, pero puede proporcionar una sugerencia de recurso utilizando la etiqueta <link rel="preload"> , indicando al navegador que descargue el activo lo antes posible. Es una buena idea precargar fuentes, logotipos y cualquier otra cosa que aparezca en la parte superior de la página.

Hablemos del almacenamiento en caché. Voy a mantener presionada la tecla ALT y hacer clic derecho para cambiar los encabezados de mis columnas para desbloquear más información interesante. Vamos a revisar Cache-Control.

Cache-Control indica si un recurso se puede almacenar en caché o no, durante cuánto tiempo se puede almacenar en caché y qué reglas debe seguir para revalidar. Establecer valores de caché adecuados es crucial para mantener bajo el costo de los datos de las visitas repetidas.

Sugerencia de rendimiento n.° 6: establezca encabezados de control de caché en todos los activos que se pueden almacenar en caché

Tenga en cuenta que el valor de control de caché comienza con una directiva de public o private , seguida de un valor de caducidad (por ejemplo max-age=31536000 ). ¿Qué significa la directiva y por qué el valor max-age extrañamente específico?

El valor 31536000 es el número de segundos que hay en un año y es el valor máximo teórico permitido por la especificación de control de caché. Es común ver este valor aplicado a todos los activos estáticos y significa efectivamente "este recurso no va a cambiar". En la práctica, ningún navegador almacenará en caché durante todo un año, pero almacenará en caché el activo durante el tiempo que tenga sentido.

Para explicar la directiva público/privado, debemos explicar los dos cachés principales que existen fuera del servidor. En primer lugar, está el caché del navegador tradicional, donde el recurso se almacena en la máquina del usuario (el 'cliente'). Y luego está la caché de CDN, que se encuentra entre el cliente y el servidor; los recursos se almacenan en caché en el nivel de CDN para evitar que la CDN solicite el recurso del servidor de origen una y otra vez.

Una directiva Cache-Control de public permite que el recurso se almacene en caché tanto en el cliente como en la CDN. Un valor de private significa que solo el cliente puede almacenarlo en caché; el CDN no se supone que lo haga. Este último valor generalmente se usa para páginas o activos que existen detrás de la autenticación, donde está bien almacenar en caché en el cliente, pero no queremos filtrar información privada al almacenarla en caché en la CDN y entregársela a otros usuarios.

Una cosa que me llamó la atención fue que el logotipo de Google tiene un control de caché de "privado". Otras imágenes en la página tienen un caché público, y no sé por qué el logotipo se trataría de manera diferente. Si tienes alguna idea, ¡házmelo saber en los comentarios!

Actualicé la página y la mayoría de los recursos se sirvieron desde el caché, además de la página en sí, que como ya ha visto es private, max-age=0 , lo que significa que no se puede almacenar en caché. Esto es normal para las páginas web dinámicas en las que es importante que el usuario obtenga siempre la última página cuando actualice.

Fue en este punto que accidentalmente hice clic en una URL de 'Explicación' en las herramientas de desarrollo, lo que me llevó a la referencia de análisis de red, lo que me costó alrededor de 5 MB de mi presupuesto. UPS.

Documentos para desarrolladores de Google

4,2 MB de esta nueva página de 5 MB se redujeron a imágenes; específicamente SVG. El más pesado de estos fue de 186 KB, que no es particularmente grande: había muchos de ellos y todos se descargaron a la vez.

Esa carga de página de 5 MB fue el 10% de mi presupuesto para hoy. Hasta ahora he usado 5,5 MB, incluida la recarga sin JavaScript de la página de inicio de Google, y gasté $0,40. Ni siquiera quise abrir esta página.

¿Cuál hubiera sido una mejor experiencia de usuario aquí?

Sugerencia de rendimiento n.° 7: Carga diferida de sus imágenes

Por lo general, si accidentalmente hago clic en un enlace, presiono el botón Atrás en mi navegador. No habría recibido ningún beneficio al descargar esas imágenes: ¡qué desperdicio de 4,2 MB!

Además del video, donde generalmente sabes en qué te estás metiendo, las imágenes son, con mucho, el mayor culpable del uso de datos en la web. Un estudio de los 500 sitios web más importantes del mundo encontró que las imágenes ocupan hasta el 53% del peso promedio de la página. “Esto significa que tienen un gran impacto en los tiempos de carga de la página y, posteriormente, en el rendimiento general”.

En lugar de descargar todas las imágenes en la carga de la página, es una buena práctica cargar las imágenes de forma diferida para que solo los usuarios que interactúan con la página paguen el costo de descargarlas. Los usuarios que eligen no desplazarse por debajo de la página no desperdician ancho de banda innecesario descargando imágenes que nunca verán.

Hay una excelente guía de css-tricks.com para implementar la carga diferida de imágenes que ofrece un buen equilibrio entre las que tienen buenas conexiones, las que tienen conexiones deficientes y las que tienen JavaScript deshabilitado.

Si esta página hubiera implementado la carga diferida según la guía anterior, cada uno de los 38 SVG se habría representado con una imagen de marcador de posición de 1 KB de forma predeterminada, y solo se habría cargado a la vista en el desplazamiento.

Consejo de rendimiento n.º 8: utilice el formato adecuado para sus imágenes

Pensé que Google se había perdido un truco al no usar WebP, que es un formato de imagen que es un 26 % más pequeño en tamaño en comparación con PNG (sin pérdida de calidad) y un 25-34 % más pequeño en tamaño en comparación con JPEG (y de una calidad comparable). Pensé que intentaría convertir SVG a WebP.

La conversión a WebP redujo uno de los SVG de 186 KB a solo 65 KB, pero en realidad, al mirar las imágenes una al lado de la otra, el WebP salió granulado:

Luego intenté convertir uno de los PNG a WebP, que se supone que no tiene pérdidas y debería salir más pequeño. Sin embargo, la salida de WebP fue *más pesada* (127 KB, de 109 KB)!

Esto me sorprendió. WebP no es necesariamente la bala de plata que creemos que es, e incluso Google se ha olvidado de usarlo en esta página.

Entonces, mi consejo sería: cuando sea posible, experimente con diferentes formatos de imagen imagen por imagen. El formato que conserva la mejor calidad para el tamaño más pequeño puede no ser el que esperas.

Ahora volvamos al DOM. Me encontré con esto:

¿Observe la palabra clave async en el script de análisis de Google?

A pesar de ser una de las primeras cosas en el encabezado del documento, se le dio una prioridad baja, ya que optamos explícitamente por no ser una solicitud de bloqueo mediante el uso de la palabra clave async .

Una solicitud de bloqueo es aquella que detiene la representación de la página. Una llamada <script> está bloqueando de forma predeterminada, deteniendo el análisis del HTML hasta que el script se haya descargado, compilado y ejecutado. Esta es la razón por la que tradicionalmente colocamos las llamadas <script> al final del documento.

Sugerencia de rendimiento n.º 9: evite escribir llamadas de secuencias de comandos de bloqueo

Al agregar el atributo async a nuestra etiqueta <script> , le estamos diciendo al navegador que no deje de mostrar la página, sino que descargue el script en segundo plano. Si el HTML aún se está analizando en el momento en que se descarga el script, el análisis se detiene mientras se ejecuta el script y luego se reanuda. Esto es significativamente mejor que bloquear la representación tan pronto como se encuentre <script> .

También hay un atributo defer , que es sutilmente diferente. <script defer> le dice al navegador que procese la página mientras la secuencia de comandos se carga en segundo plano, e incluso si el HTML aún se está analizando en el momento en que se descarga la secuencia de comandos, la secuencia de comandos debe esperar hasta que la página se procese antes de poder ejecutarse. . Esto hace que el script no bloquee en absoluto. Lea "Cargar JavaScript de manera eficiente con aplazamiento y asíncrono" para obtener más información.

De todos modos, basta de disección de Google. Es hora de probar otro sitio. ¡Todavía me quedan casi 45 MB de mi presupuesto!

Amazonas

La página de inicio de Amazon cargó con un peso total de unos 6 MB. Uno de estos era una imagen de 587 KB que ni siquiera pude encontrar en la página. Este era un PNG, presumiblemente para tener un texto nítido, pero sobre un fondo fotográfico, una combinación clásica que es terrible para el rendimiento.

De hecho, había algunas imágenes de varios cientos de kilobytes en mi pestaña de red que en realidad no podía ver en la página. Sospecho que hay una configuración incorrecta en algún lugar de Amazon, pero estas imágenes invisibles combinadas masticaron al menos 1 MB de mis datos.

¿Qué hay de la imagen del héroe? Es la imagen principal de la página y solo se transfieren 94 KB, pero su tamaño podría reducirse en aproximadamente un 15 % si se recortara directamente alrededor del texto y los futbolistas. Entonces podríamos aplicar el mismo color de fondo en CSS que en la imagen. Esto tiene la ventaja adicional de ser redimensionable a pantallas más pequeñas mientras conserva la legibilidad del texto.

Lo dije una vez, y lo diré nuevamente: optimizar y cargar de forma diferida sus imágenes es el mayor beneficio que puede obtener para el peso de la página de su sitio .

La optimización de imágenes proporcionó, con mucho, la reducción de datos más significativa. Puede argumentar que JavaScript es más importante para el rendimiento general, pero no para la reducción de datos. Optimizar o eliminar imágenes es la forma más segura de garantizar una experiencia mucho más ligera y esa es la optimización principal en la que se basa Data Saver.
— Tim Kadlec, Dar sentido a las páginas de Chrome Lite

Para ser justos con Amazon, si cambio el tamaño del navegador a un tamaño móvil y actualizo la página, el sitio está optimizado para dispositivos móviles y el peso total de la página es de solo 2,1 MB.

Pero esto me lleva al siguiente punto...

Consejo de rendimiento n.º 10: no haga suposiciones sobre las conexiones de datos

Es difícil detectar si alguien en una computadora de escritorio tiene una conexión de banda ancha o se conecta a través de un dongle o un dispositivo móvil con datos limitados. Muchas personas trabajan así en el tren o viven en un área donde la infraestructura de banda ancha es deficiente pero la señal móvil es fuerte. En el caso de Amazon, hay espacio para hacer grandes ahorros de datos en el sitio de escritorio y no debemos ser complacientes solo porque el tamaño de la pantalla sugiere que no estoy en un dispositivo móvil.

Sí, deberíamos esperar una carga de página mayor si nuestra ventana gráfica tiene el "tamaño de una computadora de escritorio", ya que las imágenes serán más grandes y estarán mejor optimizadas para la pantalla que una imagen móvil más granulada. Pero la página no debería ser mucho más grande.

Además, estaba enviando el encabezado Save-Data con mi solicitud. Este encabezado indica explícitamente una preferencia por el uso reducido de datos, y espero que más sitios web comiencen a notarlo en el futuro.

La carga inicial del 'escritorio' puede haber sido de 6 MB, pero después de sentarse y mirarla durante un minuto, subió a 8,6 MB cuando los recursos de menor prioridad y el seguimiento de eventos entraron en acción. El peso de esta página incluye casi 1,7 MB de JavaScript minimizado. Ni siquiera quiero empezar a mirar eso.

Sugerencia de rendimiento n.º 11: use Web Workers para su JavaScript

¿Qué sería peor, 1,7 MB de JavaScript o 1,7 MB de imágenes? La respuesta es JavaScript: los dos activos no son equivalentes en lo que respecta al rendimiento.

Una imagen JPEG debe decodificarse, rasterizarse y pintarse en la pantalla. Un paquete de JavaScript debe descargarse y luego analizarse, compilarse, ejecutarse, y hay una serie de otros pasos que un motor debe completar. Tenga en cuenta que estos costos no son del todo equivalentes.
— Addy Osmani, El costo de JavaScript en 2018

Si debe enviar tanto JavaScript, intente ponerlo en un trabajador web. Esto mantiene la mayor parte de JavaScript fuera del hilo principal, que ahora está libre para volver a pintar la interfaz de usuario, lo que ayuda a que su página web siga respondiendo en dispositivos de baja potencia.

Ahora tengo alrededor de 15,5 MB en mi presupuesto y he gastado $1,14 de mi presupuesto de datos de Zimbabue. Tendría que haber trabajado medio día como maestro para ganar el dinero y llegar tan lejos.

Pinterest

Escuché cosas buenas sobre el desempeño de Pinterest, así que decidí ponerlo a prueba.

Quizás esta no sea la más justa de las pruebas; Me llevaron a la página de inicio de sesión, en la que un proceso asincrónico encontró que había iniciado sesión en Facebook y me conectó automáticamente. La página se cargó relativamente rápido, pero las solicitudes aumentaron a medida que se cargaba más y más contenido.

Sin embargo, vi que en cargas de página subsiguientes, el trabajador del servicio mostró gran parte del contenido, lo que ahorró aproximadamente la mitad del peso de la página:

El sitio de Pinterest es una aplicación web progresiva; instaló un trabajador de servicio para manejar manualmente el almacenamiento en caché de CSS y JS. Ahora podría apagar mi WiFi y continuar usando el sitio (aunque no muy útil):

Sugerencia de rendimiento n.° 12: use trabajadores de servicio para brindar soporte fuera de línea

¿No sería genial si solo tuviera que cargar un sitio web una vez a través de la red y ahora obtener toda la información que necesito incluso si no estoy conectado?

Un gran ejemplo sería un sitio web que muestra el pronóstico del tiempo para la semana. Solo debería necesitar descargar esa página una vez. Si apago mis datos móviles y luego vuelvo a la página en algún momento, debería poder mostrarme el último contenido conocido. Si me vuelvo a conectar a Internet y cargo la página, obtendría un pronóstico más actualizado, pero los recursos estáticos, como CSS e imágenes, aún deberían ser atendidos localmente por el trabajador del servicio.

Esto es posible configurando un trabajador de servicio con una buena estrategia de almacenamiento en caché para que se pueda volver a acceder sin conexión a las páginas almacenadas en caché. El sitio web de documentación de lodash es un buen ejemplo de un trabajador de servicio en la naturaleza:

El contenido que rara vez se actualiza y es probable que se use con bastante frecuencia es un candidato perfecto para el tratamiento del trabajador de servicios. Los sitios dinámicos con fuentes de noticias en constante cambio no son tan adecuados para las experiencias fuera de línea, pero aún pueden beneficiarse.

Los trabajadores de servicio realmente pueden salvar el día cuando tiene un presupuesto de datos ajustado. No estoy convencido de que la experiencia de Pinterest fuera la más óptima en términos de uso de datos: las páginas posteriores tenían alrededor de 0,5 MB incluso en páginas con pocas imágenes, pero permití que tu JavaScript maneje las solicitudes de página por ti y mantuviera los mismos elementos de navegación en su lugar. puede ser muy eficaz. La BBC administra un tamaño de transferencia de solo 3,1 KB para las visitas de regreso a los artículos que se pueden representar a través de la aplicación de una sola página.

Hasta ahora, solo Pinterest ha consumido 14 MB, lo que significa que he gastado alrededor de 30 MB de mi presupuesto, o $2,20 (casi el salario de un día) de mi presupuesto de Zimbabue.

Será mejor que tenga cuidado con mis últimos 20 MB... pero ¿dónde está la diversión en eso?

Punto de juego

Elegí este porque se sentía notablemente lento en mi móvil en el pasado y quería profundizar en las razones por las cuales. Efectivamente, cargar la página de inicio consume 8,5 MB de datos.

6.5 MB de esto se redujeron a un video de reproducción automática en la mitad de la página, que, para ser justos, no pareció descargarse hasta que comencé a desplazarme. Sin embargo…

Solo pude ver la mitad del video en mi ventana gráfica: el lado derecho estaba recortado. También duró 30 segundos, y apostaría a que la mayoría de la gente no se sentará a mirar todo. Este único recurso triplicó con creces el tamaño de la página.

Consejo de rendimiento n.° 13: no precargue el video

Como regla general, a menos que el principal modo de comunicación de su sitio sea el video, no lo precargue.

Si eres YouTube o Netflix, es razonable suponer que alguien que visite tu página querrá que el video se cargue y reproduzca automáticamente. Existe la expectativa de que el video analice algunos datos, pero que sea un intercambio justo por el contenido. Pero si tiene un sitio cuyo medio principal es el texto y la imagen, y simplemente ofrece contenido de video adicional, entonces no cargue el video.

Piense en artículos de noticias con videos incrustados. Muchos usuarios solo quieren hojear el título del artículo antes de pasar a lo siguiente. Otros leerán el artículo pero ignorarán cualquier inserción. Y otros harán clic diligentemente y verán cada video incrustado. No deberíamos acaparar el ancho de banda de cada usuario asumiendo que van a querer ver estos videos.

Para reiterar: a los usuarios no les gusta la reproducción automática de videos. Como desarrolladores, solo lo hacemos porque nuestros gerentes nos dicen que lo hagamos, y solo nos dicen que lo hagamos porque las aplicaciones más geniales lo hacen, y las aplicaciones más geniales solo lo hacen porque los anuncios de video generan entre 20 y 50 veces más ingresos que los tradicionales. anuncios Google Chrome ha comenzado a bloquear videos de reproducción automática para algunos sitios, según las preferencias personales, por lo que incluso si desarrolla su sitio para reproducir videos automáticamente, no hay garantía de que esa sea la experiencia que obtienen sus usuarios.

Si estamos de acuerdo en que es una buena idea hacer que el video sea una experiencia opcional (hacer clic para reproducir), podemos dar un paso más y hacer que también haga clic para cargar. Eso significa burlarse de una imagen de marcador de posición de video con un botón de reproducción sobre ella, y solo descargar el video cuando hace clic en el botón de reproducción. People on fast connections should notice no difference in buffer speed, and people on slow connections will appreciate how fast the rest of your site loaded because it didn't have to preload a large video file.

Anyway, back to Gamespot, where I was indeed forced to preload a large video file I ended up not watching. I then clicked through to a game review page that weighed another 8.5 MB, this time with 5.4 MB of video, before I even started scrolling down the page.

What was really galling was when I looked at what the video actually was. It was an advert for a Samsung TV! This advert cost me $0.40 of my Zimbabwe wages. Not only was it pre-loaded, but it also didn't end up playing anywhere as far as I'm aware, so I never actually saw it.

The 'real' video — the gameplay footage (in other words, the content) — wasn't actually loaded until I clicked on it. And that ploughed through my remaining data in seconds.

Eso es todo. That's my 50 MB gone. I'll need to work another 1.5 days as a Zimbabwean schoolteacher to repeat the experience.

Performance Tip #14: Optimize For First Page Load

What's striking is that I used 50 MB of data and in most cases, I only visited one or two pages on any given site. If you think about it, this is true of most user journeys today.

Think about the last time you Googled something. You no doubt clicked on the first search result. If you got your answer, you closed the tab, or else you hit the back button and moved onto the next search result.

With the exception of a few so-called 'destination sites' such as Facebook or YouTube, where users habitually go as a starting point for other activities, the majority of user journeys are ephemeral. We stumble across random sites to get the answers to our questions, never to return to those sites again.

Web development practices are heavily skewed towards optimising for repeat visitors. “Cache these assets — they'll come in handy later”. “Pre-load this onward journey, in case the user clicks to read more”. “Subscribe to our mailing list”.

Instead, I believe we should optimize heavily for one-off visitors. Call it a controversial opinion, but maybe caching isn't really all that important. How important can a cached resource that never gets surfaced again be ? And perhaps users aren't actually going to subscribe to your mailing list after reading just the one article, so downloading the JavaScript and CSS for the mail subscription modal is both a waste of data and an annoying user experience.

The Decline Of Proxy Browsers

I had hoped to try out Opera Mini as part of this experiment. Opera Mini is a mobile web browser which proxies web pages through Opera's compression servers. It accounts for 1.42% of global traffic as of June 2019, according to caniuse.com.

Opera Mini claims to save up to 90% of data by doing some pretty intensive transcoding. HTML is parsed, images are compressed, styling is applied, and a certain amount of JavaScript is executed on Opera's servers. The server doesn't respond with HTML as you might expect — it actually transcodes the data into Opera Binary Markup Language (OBML), which is progressively loaded by Opera Mini on the device. It renders what is essentially an interactive 'snapshot' of the web page — think of it as a PDF with hyperlinks inside it. Read Tiffany Brown's excellent article, “Opera Mini and JavaScript” for a technical deep-dive.

It would have been a perfect way to eek my 50 MB budget as far as possible. Unfortunately, Opera Mini is no longer available on iOS in the UK. Attempting to visit it in the app store throws an error:

It's still available “in some markets” but reading between the lines, Opera will be phasing out Opera Mini for its new app — Opera Touch — which doesn't have any data-saving functionality apart from the ability to natively block ads.

Opera desktop used to have a 'Turbo mode', acting as a traditional proxy server (returning a HTML document instead of OBML), applying data-saving techniques but less intensively than Opera Mini. According to Opera, JavaScript continues to work and “you get all the videos, photos and text that you normally would, but you eat up less data and load pages faster”. However, Opera quietly removed Turbo mode in v60 earlier this year, and Opera Touch doesn't have a Turbo mode either. Turbo mode is currently only available on Opera for Android.

Android is where all the action is in terms of data-saving technology. Chrome offers a 'Lite mode' on its mobile browser for Android, which is not available for iPhones or iPads because of “platform constraints“. Outside of mobile, Google used to provide a 'Data Saver' extension for Chrome desktop, but this was canned in April.

Lite mode for Chrome Android can be forcibly enabled, or automatically kicks in when the network's effective connection type is 2G or worse, or when Chrome estimates the page will take more than 5 seconds to reach first contentful paint. Under these conditions, Chrome will request the lite version of the HTTPS URL as cached by Google's servers, and display this stripped-down version inside the user's browser, alongside a “Lite” marker in the address bar.

I'd love to try it out — apparently it disables scripts, replaces images with placeholders, prevents loading of non-critical resources and shows offline copies of pages if one is available on the device. This saves up to 60% of data. However, it isn't available in private (Incognito) mode, which hints at some of the privacy concerns surrounding proxy browsers.

El modo Lite comparte la URL HTTPS con Google, por lo que tiene sentido que este modo no esté disponible en Incógnito. Sin embargo, otra información como las cookies, la información de inicio de sesión y el contenido de la página personalizada no se comparte con Google, según ghacks.net, y "nunca interrumpe las conexiones seguras entre Chrome y un sitio web". Uno se pregunta por qué aparentemente ninguno de estos servicios de ahorro de datos está permitido en iOS (y no hay noticias sobre si el modo Lite estará alguna vez disponible en iOS).

Los proxies de ahorro de datos requieren mucha confianza; su actividad de navegación, las cookies y otra información confidencial se confían a algún servidor, a menudo en otro país. Muchos proxies simplemente ya no funcionarán porque muchos sitios se han movido a HTTPS, lo que significa que iniciativas como el modo Turbo se han convertido en gran medida en una "característica inútil". HTTPS evita este tipo de comportamiento de hombre en el medio, lo cual es bueno, aunque ha significado la desaparición de algunos de estos servicios proxy y ha hecho que los sitios sean menos accesibles para aquellos con malas conexiones.

No pude encontrar ninguna herramienta para guardar datos compatible con OSX o iOS, excepto Bandwidth Hero para Firefox (que requiere configurar su propio servicio de compresión de datos, ¡mucho más allá de las capacidades técnicas de la mayoría de los usuarios!) y skyZIP Proxy (que, actualizado por última vez en 2017 y plagado de errores tipográficos, simplemente no podía confiar en mí mismo).

Conclusión

La reducción de la huella de datos de su sitio web va de la mano con la mejora del rendimiento de la interfaz. Es lo más confiable que puede hacer para acelerar su sitio.

Además del costo de los datos, hay muchas buenas razones para centrarse en el rendimiento, como se describe en una publicación de blog de GOV.UK sobre el tema:

• El 53 % de los usuarios abandonará un sitio móvil si tarda más de 3 segundos en cargarse.
• Las personas tienen que concentrarse un 50% más cuando intentan completar una tarea simple en un sitio web con una conexión lenta.
• Las páginas web de mayor rendimiento son mejores para la duración de la batería del dispositivo del usuario y, por lo general, requieren menos energía en el servidor para su entrega. Un sitio eficaz es bueno para el medio ambiente.

No tenemos el poder de cambiar el costo global de la desigualdad de datos. Pero tenemos el poder de disminuir su impacto, mejorando la experiencia para todos en el proceso.