let’s make something together

Give us a call or drop by anytime, we endeavour to answer all enquiries within 24 hours on business days.

Find us

PO Box 16122 Collins Street West
Victoria 8007 Australia

Email us

info@domain.com
example@domain.com

Phone support

Phone: + (066) 0760 0260
+ (057) 0760 0560

Comunicación digital: Reducir las emisiones de carbono en la web

  • By Redacción
  • 5 de septiembre de 2021
  • 5 Views
LOS sitios web, desafortunadamente, no son tan amigables con el medio ambiente como nos gustaría que fueran. Este artículo contiene algunos pensamientos y experiencias de tratar de limpiarlos.

Como es el caso de muchos otros desarrolladores, los informes de los últimos años sobre los enormes requisitos energéticos de la web me han llevado a echar un vistazo a mis propios sitios web y ver qué puedo hacer para minimizar su impacto. Esta pieza 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 ecológicos y ambientales durante décadas. En todo ese tiempo, no recuerdo conscientemente a nadie que haya discutido los posibles impactos ambientales de la web . La atención se centró siempre 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 la 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 , yo era 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 que no ayuda con la insistencia de ciertas empresas en agregar palabras como «nube» y «sin servidor» a los nombres de sus productos.

Como resultado 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: ¿Cuántas piezas de hardware atraviesa una señal desde la computadora en la que estoy escribiendo para salir de casa?

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

Por supuesto, la web (cualquiera, por extensión, los sitios web que hacemos) 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 a partir de metales extraídos de la Tierra y de 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 vista de página”.

Si ha estado acostumbrado a pensar que el trabajo que realiza 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.

Si recordamos que la visualización de sitios web usa electricidad y que la producción de electricidad libera carbono, entonces sabremos que las emisiones de una página deben depender en gran medida de la cantidad de trabajo que tanto el servidor como el cliente deben realizar 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.

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


Gráfico que muestra la tendencia de casi 6 gramos de carbono a 0 PageSpeed, cayendo a 1 gramo de carbono a 100 PageSpeed.
Carbon versus PageSpeed ​​de 400 sitios web populares. ( Vista previa grande )

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. El promedio de emisiones de los sitios web con una puntuación de PageSpeed ​​de 100 es de aproximadamente 1 gramo de carbono, que se eleva a casi 6 gramos proyectados para los sitios web con una puntuación de 0. Me parece un poco tranquilizador que, a pesar de que hay muchos sitios web con una puntuación muy baja 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 entendemos que gran parte de las emisiones de una página se deben a un rendimiento deficiente, podemos empezar 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 la infraestructura de red a través de la cual 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 muchos de los que leen esto probablemente tengan más experiencia que yo, pero me gustaría mencionar brevemente algunas cosas que he observado recientemente al optimizar la velocidad de carga de varias páginas y las emisiones de carbono.

EL PROCESAMIENTO ES MUCHO MÁS LENTO 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.


Imagen de altura completa de árboles en el sitio web.  No hay contenido visible.
La antigua página de inicio que muestra un encabezado de imagen de altura completa. ( Vista previa grande )

Si bien el diseño hizo un buen trabajo al mostrar mis fotografías, fue un completo dolor pasar por alto, 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 me decidí por usarla como fondo para el título de la página.


Página web con texto e imagen como fondo para el título.
La nueva página de inicio con una imagen muy reducida. ( Vista previa grande )

El encabezado de altura completa se había estado usando srcsetpara que la carga fuera lo más rápida posible, pero las imágenes seguían siendo 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 aproximadamente 1,5 segundos.

En las computadoras portátiles y de escritorio, la gente no habría notado una diferencia, porque ambas versiones duraron menos de un segundo, pero en dispositivos móviles mucho menos potentes, fue 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. Decodificar y renderizar 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 influir 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 contrarrestar ese beneficio. Como ocurre con la mayoría de las cosas, las pruebas son clave aquí.

De mis propias pruebas al tratar de agregar soporte para la codificación AVIF al generador de sitios estáticos de Zola, encontré que AVIF, que promete tamaños de archivo mucho más pequeños que JPG con la misma calidad , tomó órdenes de magnitud más para codificar; algo que la observación de bunny.net de que WebP supera a AVIF hasta 100 veces es compatible. Mientras hace esto, el servidor consumirá electricidad y me pregunto si, para los sitios web con un número bajo 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 tardan mucho en procesarse. Los archivos JavaScript pequeños, dependiendo de lo que estén haciendo, pueden tardar mucho en ejecutarse y se aplicarán los mismos errores potenciales que las imágenes.

VIAJES DE IDA Y VUELTA SUMAN  #

Otra cosa que puede tener un impacto sorprendente en el rendimiento y las emisiones es de dónde provienen sus datos. La sabiduría convencional ha dicho durante mucho tiempo que el servicio de activos como los marcos de una red de entrega de contenido central (CDN) mejorará el rendimiento porque obtener datos de los nodos locales es generalmente más rápido para los usuarios que de 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 autohospedaje son generalmente más rápidos .

Esta también ha sido mi experiencia. Recientemente 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 a autohospedar todos los activos y eliminamos los componentes no utilizados del marco.

Ninguna de las optimizaciones dio lugar a cambios visuales en el sitio web, pero juntas aumentaron la puntuación de Lighthouse de 72 a 98 y redujeron las emisiones de carbono de 0,26 gramos por visualización a 0,15.

ENVÍE SOLO LO QUE NECESITA  #

Esto conduce 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 numerosos artículos sobre cómo está disminuyendo la cantidad de tiempo que la gente dedica a la lectura . 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 la gente no está mirando tus imágenes, las imágenes también pueden ser un espacio vacío. Y cuando cada byte cuesta dinero, contribuye al cambio climático y ralentiza los tiempos de carga, sería mejor para todos si realmente lo fueran.

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 comencemos a publicar páginas sin estilo; algunas personas, como las que tienen dislexia, encuentran dificultades para leer grandes bloques de texto, y es casi seguro que otros usuarios encontrarán esas páginas aburridas y se irán a otra parte, pero deberíamos mirar críticamente cada parte de nuestros sitios web para considerar si se están ganando el sustento.

Accesibilidad Y Medio Ambiente  #

Otro ámbito en el que convergen rendimiento y emisiones es el de la accesibilidad. Existe la idea errónea de que hacer que los sitios web sean accesibles implica agregar ariaatributos y JavaScript a una página, pero a menudo lo que omite es más importante que lo que ingresa, lo que hace que un sitio web accesible sea relativamente liviano y de rendimiento.

USO DE ELEMENTOS ESTÁNDAR  #

MDN Web Docs tiene muy buenos tutoriales sobre accesibilidad. En » HTML: una buena base para la accesibilidad «, cubren 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 buttonelemento usando un divJavaScript 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 1.403 bytes sin comprimir, mientras que uno real buttoncon menos JavaScript y sin estilo pesa 746 bytes. El divbotón también carecerá de significado semántico y, por lo tanto, será mucho más difícil de usar para las personas con lectores de pantalla y para que los robots lo analicen.

Cuando se amplía, 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.

A mayor escala, recientemente estaba refactorizando el HTML de un sitio web en el que trabajo, haciendo cosas como eliminar atributos de título redundantes y reemplazar divs con equivalentes más semánticos. La página original tenía una estructura como la siguiente (contenido eliminado por motivos 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, 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 es mucho más accesible según WebAIM, Lighthouse y las pruebas manuales. El tamaño del archivo también se ha reducido y, al promediar el tiempo de cinco perfiles en Chrome, el tiempo para analizar el HTML se ha reducido en aproximadamente 2 milisegundos.

Obviamente, se trata de pequeños cambios y probablemente no supongan ninguna diferencia de percepción para los usuarios. Sin embargo, es bueno saber que cada byte cuesta a los usuarios y al medio ambiente ; hacer que un sitio web sea accesible también puede hacerlo un poco más liviano.

VÍDEOS  #

La versión HTML del Proyecto Gutenberg de Las obras completas de William Shakespeare tiene aproximadamente 7,4 MB sin comprimir. Según la Autoridad de Android en » ¿Cuántos datos utiliza YouTube en realidad?» ”, 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 intenso para codificar y decodificar, y este es probablemente un factor importante que contribuye a las estimaciones de que las emisiones de carbono de Netflix son tan altas como 3.2 KG por hora.

La mayoría de los videos se basan en componentes visuales y auditivos para comunicar su mensaje, y los archivos de gran tamaño requieren un cierto nivel de conectividad . Obviamente, esto pone límites a 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.

Si el video solo fuera tratado como una forma de mejora progresiva, esto quizás 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 he encontrado. lo que quería era ver un video. En YouTube, el número promedio de usuarios mensuales aumentó 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ñadas 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 plano también es increíblemente eficiente en el 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 al ver un proceso en acción, pero también deja fuera a algunas personas y tiene un costo ambiental. Para mantener nuestros sitios web lo más ligeros 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.

En Conclusión  #

Con suerte, esta breve mirada a mi experiencia al tratar de mejorar los sitios web para el medio ambiente le ha 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 tamaño de la web puede amplificar los cambios tanto positivos como negativos, e incluso las pequeñas mejoras pronto se suman en los sitios web con miles de visitantes a la semana.

A pesar de que 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 vemos sitios web que se hacen 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 acelerarlos, y eso beneficia a todos .

Fuente:

Reducir las emisiones de carbono en la web

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *