Reducción de las emisiones de carbono en la web

Como es el caso de muchos otros desarrolladores, los informes de los últimos años sobre los enormes requisitos de energía de la web me han llevado a echar un vistazo a mis propios sitios web y ver qué puedo hacer para minimizar su impacto. Este artículo cubrirá algunas de mis experiencias al hacer esto, así como mis pensamientos actuales sobre la optimización de sitios web para las emisiones de carbono y algunos ejemplos prácticos de cosas que puede hacer para mejorar sus propias páginas.

Pero primero, una confesión: cuando escuché por primera vez sobre el impacto ambiental de los sitios web, no lo creí del todo. Después de todo, se supone que lo digital es mejor para el planeta, ¿no es así?

He estado involucrado en varios grupos verdes y ambientalistas durante décadas. En todo ese tiempo, no puedo recordar conscientemente a nadie discutiendo los posibles impactos ambientales de la web . El enfoque siempre estuvo en reducir el consumo y alejarse de la quema de combustibles fósiles. La única vez que se mencionó Internet fue como una herramienta para comunicarse entre sí sin necesidad de talar más árboles, o para trabajar sin tener que desplazarse.

Entonces, cuando la gente comenzó a hablar de que Internet tiene emisiones de carbono similares a las de la industria de las aerolíneas, estaba un poco escéptico.

Emisiones

Puede ser difícil visualizar la enorme red de hardware que le permite enviar una solicitud de una página a un servidor y luego recibir una respuesta. La mayoría de nosotros no vivimos en centros de datos, y los cables que llevan las señales de una computadora a otra a menudo están enterrados bajo nuestros pies. Cuando no puede ver un proceso en acción, todo puede parecer un poco mágico, algo a lo que no ayuda la insistencia de ciertas empresas en agregar palabras como "nube" y "sin servidor" a los nombres de sus productos.

A raíz de esto, mi visión de Internet durante mucho tiempo fue un poco efímera, una especie de espejismo. Sin embargo, cuando comencé a escribir este artículo, realicé un pequeño experimento mental: ¿a través de cuántas piezas de hardware viaja una señal desde la computadora en la que estoy escribiendo para salir de la casa?

La respuesta fue bastante impactante: 3 cables cat, un switch, 2 adaptadores powerline, un router y módem, un cable RJ11 y varios metros de cableado eléctrico. De repente, ese espejismo comenzaba a parecer bastante más sólido.

Por supuesto, la web (cualquiera, por extensión, los sitios web que hacemos) sí tiene una huella de carbono. Todos los servidores, enrutadores, conmutadores, módems, repetidores, gabinetes telefónicos, convertidores ópticos a eléctricos y enlaces ascendentes satelitales de Internet deben construirse con metales extraídos de la Tierra y plásticos refinados del petróleo crudo. Para luego proporcionar datos a los aproximadamente 20 mil millones de dispositivos conectados en todo el mundo, necesitan consumir electricidad, que también libera carbono cuando se genera (incluso la electricidad renovable no es neutra en carbono, aunque es mucho mejor que los combustibles fósiles).

Probablemente sea imposible medir con precisión cuáles son esas emisiones: cada dispositivo es diferente y la energía que los alimenta puede variar en el transcurso de un día, pero podemos tener una idea aproximada al observar las cifras típicas de consumo de energía, bases de usuarios y pronto. Una herramienta que utiliza estos datos para estimar las emisiones de carbono de una sola página es la Calculadora de carbono del sitio web. Según él, la página promedio probada “produce 1,76 gramos de CO2 por página vista”.

Si ha estado acostumbrado a pensar que el trabajo que hace es esencialmente inofensivo para el medio ambiente, darse cuenta de esto puede ser bastante desalentador. La buena noticia es que, como desarrolladores, podemos hacer mucho al respecto.

Lectura recomendada : Cómo mejorar el rendimiento del sitio web puede ayudar a salvar el planeta

Rendimiento y emisiones

Si recordamos que ver sitios web usa electricidad y que producir electricidad libera carbono, entonces sabremos que las emisiones de una página deben depender en gran medida de la cantidad de trabajo que deben realizar tanto el servidor como el cliente para mostrar la página. Además, la cantidad de datos que se requieren para la página y la complejidad de la ruta por la que debe viajar determinarán la cantidad de carbono liberado por la propia red.

Por ejemplo, descargar y renderizar example.com probablemente consumirá mucha menos electricidad que la página de inicio de Apple, y también será mucho más rápido. En efecto, lo que estamos diciendo es que las altas emisiones y la carga lenta de páginas son solo dos síntomas de las mismas causas subyacentes.

Está muy bien hablar de esta relación en teoría, por supuesto, pero sería bueno tener algunos datos del mundo real para respaldarlo. Para hacer precisamente eso, decidí realizar un pequeño estudio. Escribí un programa de interfaz de línea de comandos simple para tomar una lista de los 500 sitios web más populares en Internet, según MOZ, y comparar sus páginas de inicio con PageSpeed ​​Insights de Google y Website Carbon Calculator.

Se agotó el tiempo de espera de algunas de las comprobaciones (a menudo porque la página en cuestión simplemente tardó demasiado en cargarse), pero en total logré recopilar los resultados de más de 400 páginas el 14 de julio de 2021. Puede descargar el resumen de los resultados para examinarlo usted mismo, pero para proporcionar una indicación visual, los he trazado en el cuadro a continuación:

Como puede ver, si bien la variación entre sitios web individuales es muy alta, existe una fuerte tendencia hacia menores emisiones de páginas más rápidas. La media de emisiones promedio para sitios web con un puntaje de PageSpeed ​​de 100 es de aproximadamente 1 gramo de carbono, que se eleva a casi 6 gramos proyectados para sitios web con un puntaje de 0. Me parece un poco tranquilizador que, a pesar de que hay muchos sitios web con muy bajo velocidades y altas emisiones, la mayoría de los resultados se agrupan en la parte inferior derecha del gráfico.

Tomando acción

Una vez que comprendemos que gran parte de las emisiones de una página se originan por un rendimiento deficiente, podemos comenzar a tomar medidas para reducirlas. Muchas de las cosas que contribuyen a las emisiones de un sitio web están fuera de nuestro control como desarrolladores. No podemos, por ejemplo, elegir los dispositivos desde los que nuestros usuarios acceden a nuestras páginas o decidir sobre la infraestructura de red por la que viajan sus solicitudes, pero podemos tomar medidas para mejorar el rendimiento de nuestros sitios web.

La optimización del rendimiento es un tema amplio y es probable que muchos de los que lean esto tengan más experiencia que yo, pero me gustaría mencionar brevemente algunas cosas que he observado recientemente al optimizar la velocidad de carga y las emisiones de carbono de varias páginas.

La renderización es mucho más lenta en dispositivos móviles

Recientemente modifiqué el diseño de mi blog personal para hacerlo un poco más fácil de usar. Uno de mis pasatiempos es la fotografía, y el sitio web había presentado anteriormente una imagen de encabezado de altura completa.

Si bien el diseño hizo un buen trabajo al mostrar mis fotografías, fue un dolor total pasar de largo, especialmente cuando se movía a través de las páginas de las publicaciones del blog. Sin embargo, no quería perder la sensación de tener una foto en el encabezado y finalmente decidí usarla como fondo para el título de la página.

El encabezado de altura completa había estado usando srcset para que la carga fuera lo más rápida posible, pero las imágenes aún eran muy grandes en pantallas de alta resolución, y mi tiempo de pintura con contenido (LCP) más largo en dispositivos móviles para el diseño anterior fue de casi 3 segundos. Una gran ventaja del nuevo diseño fue que me permitió hacer las imágenes mucho más pequeñas, lo que redujo el tiempo de LCP a alrededor de 1,5 segundos.

En las computadoras portátiles y de escritorio, la gente no habría notado la diferencia, porque ambas versiones duraban menos de un segundo, pero en dispositivos móviles mucho menos potentes, era bastante dramático. ¿Cuál fue el efecto de este cambio en las emisiones de carbono? 0,31 gramos por vista antes, 0,05 gramos después. La decodificación y renderización de imágenes requiere muchos recursos , y esto crece exponencialmente a medida que las imágenes se hacen más grandes.

El tamaño de las imágenes no es lo único que puede tener un impacto en el tiempo de decodificación; el formato también es importante. Lighthouse de Google a menudo recomienda servir imágenes en formatos de próxima generación para reducir la cantidad de datos que deben descargarse, pero los nuevos formatos suelen ser más lentos de decodificar, especialmente en dispositivos móviles. Enviar menos datos por cable es mejor para el medio ambiente, pero es posible que consumir más energía para decodificar pueda compensar ese beneficio. Como con la mayoría de las cosas, las pruebas son clave aquí.

A partir de mis propias pruebas al tratar de agregar soporte para la codificación AVIF al generador de sitios estáticos de Zola, descubrí que AVIF, que promete tamaños de archivo mucho más pequeños que JPG con la misma calidad, tomó mucho más tiempo para codificar; algo que apoya la observación de bunny.net de que WebP supera a AVIF hasta 100 veces. Mientras hace esto, el servidor consumirá electricidad, y me pregunto si, para los sitios web con un bajo número de visitantes, cambiar al nuevo formato podría terminar aumentando las emisiones y reduciendo el rendimiento.

Las imágenes, por supuesto, no son el único componente de las páginas web modernas que tarda mucho tiempo en procesarse. Los archivos pequeños de JavaScript, según lo que estén haciendo, pueden tardar mucho tiempo en ejecutarse y se producirán los mismos peligros potenciales que las imágenes.

Lectura recomendada : The Humble img Element y Core Web Vitals

Los viajes de ida y vuelta se suman

Otra cosa que puede tener un impacto sorprendente en el rendimiento y las emisiones es de dónde provienen los datos. La sabiduría convencional ha dicho durante mucho tiempo que servir activos como marcos desde una red central de entrega de contenido (CDN) mejorará el rendimiento porque obtener datos de los nodos locales es generalmente más rápido para los usuarios que desde un servidor central. jQuery, por ejemplo, tiene la opción de cargarse desde un CDN, y sus mantenedores dicen que esto puede mejorar el rendimiento, pero las pruebas del mundo real realizadas por Harry Roberts han demostrado que los activos de alojamiento propio son generalmente más rápidos.

Esta también ha sido mi experiencia. Hace poco ayudé a un sitio web de juegos a mejorar su rendimiento. El sitio web usaba un marco CSS bastante grande y cargaba todos sus activos de terceros a través de un CDN. Cambiamos al alojamiento propio de todos los activos y eliminamos los componentes no utilizados del marco.

Ninguna de las optimizaciones generó cambios visuales en el sitio web, pero juntas aumentaron el puntaje de Lighthouse de 72 a 98 y redujeron las emisiones de carbono de 0,26 gramos por vista a 0,15.

Envía solo lo que necesitas

Esto lleva muy bien al tema de enviar a los usuarios solo los datos que realmente necesitan. He trabajado (y visitado) muchos, muchos sitios web que están dominados por imágenes de archivo de personas en traje sonriendo el uno al otro. Parece haber una mentalidad entre ciertas organizaciones de que lo que hacen es realmente aburrido y que agregar fotos de alguna manera convencerá al público en general de lo contrario.

Puedo entender el pensamiento detrás de esto porque hay numerosas piezas sobre cómo está disminuyendo la cantidad de tiempo que la gente pasa leyendo. El texto, se nos dice repetidamente, está pasando de moda; lo único que le interesa a la gente ahora son los videos y las experiencias interactivas.

Desde ese punto de vista, las fotos de archivo podrían verse como una herramienta útil para animar las páginas, pero los estudios de seguimiento ocular muestran que las personas ignoran las imágenes que no son relevantes. Cuando las personas no están mirando sus imágenes, las imágenes también podrían ser espacios vacíos. Y cuando cada byte cuesta dinero, contribuye al cambio climático y ralentiza los tiempos de carga, sería mejor para todos que así fuera.

Una vez más, lo que se puede decir de las imágenes se puede decir de todo lo demás que no sea el contenido principal de la página. Si algo no contribuye a la experiencia de un usuario de manera significativa, no debería estar ahí. No estoy defendiendo ni por un momento que todos empecemos a publicar páginas sin estilo; algunas personas, como las que tienen dislexia, encuentran grandes bloques de texto difíciles de leer, y otros usuarios seguramente encontrarán aburridas esas páginas y se irán a otra parte, pero debemos mirar críticamente cada parte de nuestros sitios web para considerar si se están ganando el sustento.

Accesibilidad y Medio Ambiente

Otro ámbito donde confluyen prestaciones y emisiones es en el campo de la accesibilidad. Hay una idea errónea común de que hacer que los sitios web sean accesibles implica agregar atributos aria y JavaScript a una página, pero a menudo lo que se deja fuera es más importante que lo que se pone, lo que hace que un sitio web accesible sea relativamente ligero y eficaz.

Uso de elementos estándar

MDN Web Docs tiene muy buenos tutoriales sobre accesibilidad. En “HTML: una buena base para la accesibilidad”, explican cómo la mejor base de un sitio web accesible radica en el uso de los elementos HTML correctos para el contenido. Una de las secciones más interesantes del artículo es donde intentan recrear la funcionalidad de un elemento de button usando un div y JavaScript personalizado.

Obviamente, este es un ejemplo mínimo, pero pensé que sería interesante comparar el tamaño de esta versión de botón con una que usa elementos HTML estándar. El ejemplo del botón falso en este caso pesa alrededor de 1403 bytes sin comprimir, mientras que un button real con menos JavaScript y sin estilo pesa 746 bytes. El botón div tampoco tendrá sentido semántico y, por lo tanto, será mucho más difícil de usar para las personas con lectores de pantalla y de análisis para los bots.

Lectura recomendada : SVG accesibles: patrones perfectos para usuarios de lectores de pantalla

Cuando se amplían, este tipo de cosas marcan la diferencia. Analizar el marcado mínimo y JavaScript es más fácil para un navegador, al igual que es más fácil para los desarrolladores.

En una escala mayor, recientemente estaba refactorizando el HTML de un sitio web en el que trabajo, haciendo cosas como eliminar atributos de título redundantes y reemplazar div s con más equivalentes semánticos. La página original tenía una estructura como la siguiente (contenido eliminado por razones de privacidad y brevedad):

 <div class="container"> <section> <div class="row"> <div class="col-md-3"> <aside> <!-- Sidebar content here --> </aside> </div> <div class="col-md-9"> <!-- Main content here --> <h4>Content piece heading</h4> <p> Some items;<br> Item 1 <br> Item 2 <br> Item 3 <br> <br> </p> <!-- More main content here --> </div> </div> </section> </div>

Con el contenido completo, este pesaba 34.168 bytes.

Después de la refactorización, la estructura se parecía a esto:

 <div class="container"> <div class="row"> <main class="col-md-9 col-md-push-3"> <!-- Main content here --> <h3>Content piece heading</h3> <p>Some items;</p> <ul> <li>Item 1</li> <li>Item 2</li> <li>Item 3</li> </ul> <!-- More main content here --> </main> <aside class="col-md-3 col-md-pull-9"> <!-- Sidebar content here --> </aside> </div> </div>

Pesaba 32.805 bytes.

Los cambios están actualmente en curso, pero el marcado ya es mucho más accesible según WebAIM, Lighthouse y las pruebas manuales. El tamaño del archivo también se redujo y, al promediar el tiempo de cinco perfiles en Chrome, el tiempo para analizar el HTML se redujo en aproximadamente 2 milisegundos.

Obviamente, estos son cambios pequeños y probablemente no harán ninguna diferencia perceptiva para los usuarios. Sin embargo, es bueno saber que cada byte le cuesta a los usuarios y al medio ambiente : hacer que un sitio web sea accesible también puede hacerlo un poco más ligero.

Vídeos

La versión HTML del Proyecto Gutenberg de Las obras completas de William Shakespeare ocupa aproximadamente 7,4 MB sin comprimir. Según Android Authority en "¿Cuántos datos usa YouTube realmente?", un video de YouTube de 360p pesa alrededor de 5 a 7.5 MB por minuto de metraje y 1080p alrededor de 50 a 68. Por lo tanto, para la misma cantidad de ancho de banda que todas las obras de Shakespeare. , obtendrá solo unos 7 segundos de video de alta definición. El video también es muy intensivo para codificar y decodificar, y este es probablemente un factor importante que contribuye a las estimaciones de que las emisiones de carbono de Netflix alcanzan los 3,2 kg por hora.

La mayoría de los videos se basan en componentes tanto visuales como auditivos para comunicar su mensaje, y los archivos de gran tamaño requieren cierto nivel de conectividad . Obviamente, esto impone límites sobre quién puede beneficiarse de dicho contenido. Hacer que el video sea accesible es posible, pero está lejos de ser simple, y muchos sitios web simplemente no se molestan en hacerlo.

Si el video solo se tratara como una forma de mejora progresiva, quizás esto no sería un problema, pero he perdido la cuenta de la cantidad de veces que he estado buscando algo en la web, y la única forma de encontrar la información que quería era viendo un video. En YouTube, la cantidad promedio de usuarios mensuales creció de 20 millones en 2006 a 2 mil millones en 2020. Vimeo también tiene una base de usuarios en continuo crecimiento.

A pesar de la gran cantidad de visitantes a los sitios web para compartir videos, muchos de los más populares no parecen cumplir completamente con la legislación de accesibilidad. En contraste con esto, numerosos tipos de tecnologías de asistencia están diseñados para hacer que el texto sin formato sea accesible para la mayor variedad de personas posible. El texto también es fácil de convertir de un formato a otro, por lo que se puede utilizar en varios contextos diferentes.

Como podemos ver en el ejemplo de Shakespeare, el texto sin formato también es increíblemente eficiente en el uso del espacio y tiene una huella de carbono mucho menor que cualquier otra forma de información amigable para los humanos transmitida en la web.

El video puede ser excelente y muchas personas aprenden mejor observando un proceso en acción, pero también excluye a algunas personas y tiene un costo ambiental. Para mantener nuestros sitios web lo más livianos e inclusivos posible, debemos tratar el texto como la forma principal de comunicación siempre que sea posible, y ofrecer cosas como audio y video como un extra.

Lectura recomendada : Optimización de video para tamaño y calidad

En conclusión

Con suerte, esta breve mirada a mi experiencia al tratar de mejorar los sitios web para el medio ambiente le haya dado algunas ideas sobre cosas que puede probar en sus propios sitios web. Puede ser bastante desalentador pasar una página a través de la Calculadora de carbono del sitio web y que le digan que podría estar emitiendo cientos de kilogramos de CO2 al año. Afortunadamente, el gran tamaño de la web puede amplificar tanto los cambios positivos como los negativos, e incluso las pequeñas mejoras pronto se acumulan en los sitios web con miles de visitantes a la semana.

Aunque estamos viendo cosas como un sitio web de 25 años que aumenta 39 veces su tamaño después de un rediseño, también estamos viendo sitios web creados para usar la menor cantidad de datos posible, y personas inteligentes están descubriendo cómo entregar WordPress en 7 KB. Entonces, para que podamos reducir las emisiones de carbono de nuestros sitios web, debemos hacerlos más rápidos, y eso beneficia a todos .

Otras lecturas

• Residuos en todo el mundo, Gerry McGovern
• "¿Es WebP realmente mejor que JPEG?", Johannes Siipola
• “¿Hacer que Jamstack sea lento? Desafío aceptado”, Steve Keep, CSS-Tricks
• “¿Puede Internet alguna vez ser verde?”, The Climate Question, BBC
• "¿Podría su centro de datos no solo potenciar su sitio web, sino también hacer crecer su ensalada?", Tom Greenwood, Wholegrain Digital
• The Better Web Alliance (mi propio proyecto)
• Manifiesto Web Sostenible