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

Publicado: 2022-03-10
Resumen rápido ↬ Puede que el cambio climático no parezca un tema que deba preocupar a los desarrolladores web, pero la verdad es que nuestro trabajo sí tiene una huella de carbono, y ya es hora de que empecemos a pensar en eso.

Puede que no pienses en ello a menudo, pero Internet utiliza una cantidad colosal de electricidad. Esta electricidad debe producirse en alguna parte. En la mayoría de los países, esto significa la quema de combustibles fósiles. Esto, a su vez, significa que la huella de carbono de Internet ha crecido hasta el punto en que puede haber eclipsado los viajes aéreos globales, y esto convierte a Internet en la máquina de carbón más grande de la Tierra.

El Informe sobre la salud de Internet de Mozilla de 2018 establece que, especialmente a medida que Internet se expande a nuevos territorios, "la sostenibilidad debería ser una prioridad mayor". Pero tal como están las cosas, los sitios web se están volviendo cada vez más obesos, lo que significa que la demanda de energía de Internet continúa creciendo exponencialmente.

Mientras tanto, los impactos del cambio climático empeoran y son más numerosos con cada año que pasa. La gran mayoría de los científicos del clima atribuyen la creciente ferocidad y frecuencia de los fenómenos meteorológicos extremos en todo el mundo al cambio climático, que atribuyen en gran medida a la actividad humana. Si bien algunos cuestionan la ciencia, incluso las compañías petroleras más grandes del mundo ahora la aceptan y admiten que sus modelos comerciales deben cambiar.

Todos los países de la Tierra (con la excepción de los EE. UU.) están suscritos al Acuerdo Climático de París. Aunque EE. UU. se retiró de manera controvertida, muchas de las personas, ciudades, estados y empresas más influyentes de EE. UU., que representan a más de la mitad de la población y la economía de EE. UU., han mantenido su compromiso con el acuerdo a través de la iniciativa America's Pledge.

¡Más después del salto! Continúe leyendo a continuación ↓

Como desarrolladores web, es comprensible sentir que este no es un problema sobre el que tengamos influencia, pero no es cierto. Se están realizando muchos esfuerzos para mejorar la situación en la web. The Green Web Foundation mantiene una base de datos en constante crecimiento de servidores web que funcionan totalmente con energía renovable o que al menos están comprometidos con ser neutrales en carbono. En 2013, A List Apart publicó Diseño web sostenible de James Christie. Durante los últimos tres años, la conferencia SustainableUX ha visto a expertos en sostenibilidad web compartir sus conocimientos en una variedad de disciplinas basadas en la web.

Desde 2009, Greenpeace ha estado presionando a las grandes empresas de Internet para que limpien su matriz energética a través de su campaña Clicking Clean. En parte como resultado de esta campaña, Google anunció el año pasado que, por primera vez, había comprado suficiente energía renovable para igualar el 100 % de su consumo global para las operaciones.

Entonces, además de alimentar los servidores con energía renovable, ¿qué más pueden hacer los desarrolladores web sobre el cambio climático?

“No se puede gestionar lo que no se puede medir”

Quizás la mayor ventaja cuando se trata de hacer que los sitios web sean más sostenibles es que el rendimiento, la experiencia del usuario y la sostenibilidad están perfectamente entrelazados. La métrica clave para medir la sostenibilidad de un producto digital es su uso de energía. Esto incluye el trabajo realizado por el servidor, el cliente y las redes de comunicación intermediarias que transmiten datos entre los dos.

Con eso en mente, quizás lo primero a considerar es ¿cómo medimos el uso de energía de nuestro sitio web? En realidad, esta es una empresa más complicada de lo que podría imaginar, y es difícil obtener datos precisos aquí. Sin embargo, existen algunos buenos recursos alternativos que podemos usar para demostrar el uso de energía. Estos incluyen la transferencia de datos (es decir, cuántos datos tiene que descargar el navegador para mostrar su sitio web) y el uso de recursos del hardware que sirve y recibe el sitio web. Una métrica obvia aquí es el uso de la CPU, pero el uso de la memoria y otras formas de almacenamiento de datos también juegan su papel.

La transferencia de datos es algo que podemos medir con bastante facilidad. Todos los principales navegadores proporcionan herramientas de desarrollo que nos permiten medir la actividad de la red. En esta captura de pantalla a continuación, por ejemplo, podemos ver que cargar el sitio web de Smashing Magazine por primera vez incurre en poco menos de un megabyte de transferencia de datos. Las herramientas de desarrollo de Firefox en realidad nos proporcionan dos números: el primero es el tamaño sin comprimir de los archivos que se han transferido y el segundo es el tamaño comprimido.

SmashingMag - Edición para desarrolladores de Firefox
(Vista previa grande)

La herramienta más común para comprimir activos mientras viajan por la red es gzip, por lo que la diferencia entre esos dos números suele ser el resultado del trabajo de gzip. Este último número representa la cantidad de datos que se han transmitido realmente y es el que hay que vigilar.

Nota : Hay muchas otras herramientas que nos brindan una métrica para la transferencia de datos, incluida la muy venerada WebPagetest.

Para medir el uso de la CPU, Chrome nos proporciona un Administrador de tareas granular que muestra el consumo de memoria, el uso de la CPU y la actividad de la red de pestañas individuales. Para los más aventureros/técnicos, el comando superior (tabla de procesos) proporciona métricas similares en la mayoría de los sistemas operativos similares a Unix, como macOS y Ubuntu. En términos generales, también podemos ejecutar el comando superior en cualquier servidor al que tengamos acceso de shell.

Afortunadamente, existen esfuerzos como WebsiteCarbon y Ecograder que buscan traducir estas métricas en una cifra específica de CO2 (en el caso de WebsiteCarbon) o una puntuación (en el caso de Ecograder).

Diseño Web Sostenible

Ahora que sabemos cómo medir el impacto de nuestro sitio, es hora de pensar en cómo podemos optimizar las cosas para que sea más sostenible, más eficaz y, en general, una mejor experiencia de uso.

Hay algunos trabajos existentes en los que podemos basarnos para ayudarnos aquí. En 2016, O'Reilly publicó "Diseño para la sostenibilidad" de Tim Frick. En este libro, Tim nos hace un recorrido por los porqués y los cómos del diseño sustentable. Pero también podemos aprovechar una gran cantidad de ideas existentes, conferencias y artículos que, si bien no tienen un enfoque explícito en la sostenibilidad, tienen una gran superposición con la filosofía del diseño web sostenible. Ejemplos particularmente buenos aquí son el proyecto paralelo de Brad Frost, "Death To Bullshit", los artículos y charlas de Heydon Pickering sobre escribir menos maldito código, y la publicación de blog de Adam Silver, "Designing For Actual Performance".

Si estamos haciendo un rediseño completo de un sitio web, o comenzando uno nuevo desde cero, podemos comenzar con algunas preguntas de muy alto nivel aquí. Por ejemplo, ¿qué merece o necesita estar en una página de inicio? Y más concretamente, ¿qué valor aporta cada elemento de una página de inicio? Como dice Heydon Pickering:

“La característica más eficaz, accesible y fácil de mantener de un sitio web es la que no creas en primer lugar”.

Trabajo en el equipo VIP de WordPress.com, así que decidí desafiarme a mí mismo creando un tema de WordPress minimalista para ver hasta dónde podía llevar las técnicas del diseño web sostenible. El resultado es un tema llamado Susty, y se puede ver en acción en el sitio web adjunto que preparé: sustywp.com. En ese ejemplo en particular, el sitio web se entrega con poco más de 6 KB de transferencia de datos, lo que se siente bien dado que el sitio web promedio es de aproximadamente 1,5 MB.

¿Entonces qué hice? Bueno, te lo diré.

Reducir las solicitudes de red

Como describí anteriormente, las solicitudes de red son algo que podemos medir fácilmente, por lo que son un buen punto de partida. Al armar Susty, noté que había una cantidad de solicitudes HTTP en curso que no parecían ser necesarias. Por ejemplo, WordPress incluye algunos CSS y JavaScript que detectan el uso de emojis y se aseguran de que no aparezcan como caracteres ilegales. No hay nada intrínsecamente malo en esto, pero si no planea usar emojis, o si está feliz y seguro de que los diversos valores predeterminados del sistema lo cubrirán, puede evitar que se carguen.

Esto representa un ahorro relativamente escaso, pero al establecer una filosofía de eliminar el código no deseado y las solicitudes de nuestras páginas, podemos lograr mejoras de rendimiento mucho más significativas. Por ejemplo:

  • ¿Estamos cargando todo jQuery para algunas operaciones DOM básicas?
    ¿Podríamos lograr los mismos fines con JavaScript puro? Puede leer sobre la eliminación de código inactivo más avanzada (también conocida como agitación de árboles) en esta publicación para Google de Jeremy Wagner.
  • ¿Tenemos un carrusel de imágenes?
    ¿Realmente necesitamos todas esas imágenes? ¿Están mejorando significativamente la experiencia del usuario? ¿O podríamos reducirlo a una sola imagen fuerte? ¿O incluso mostrar al azar una de una selección de imágenes, para dar una sensación de dinamismo a los usuarios que regresan? Por cierto, la investigación que se ha realizado aquí muestra que a la mayoría de los usuarios no les gustan ni interactúan con los carruseles.
  • Si estamos usando muchas imágenes, ¿nos beneficiaría proporcionar nuestras imágenes usando el formato WebP para aquellos navegadores que lo admitan?
    Durante mucho tiempo, el soporte de WebP ha sido frustrantemente limitado. Pero dado que Firefox debe comenzar a admitirlo en la versión 65 (que vence en enero de 2019), es solo cuestión de tiempo antes de que los rezagados restantes como Safari se pongan al día.
  • ¿Estamos cargando cientos de kilobytes de fuentes web?
    ¿Estamos utilizando todas las fuentes web que estamos cargando? ¿Necesitamos fuentes web? La mayoría de los dispositivos en estos días tienen una pila de fuentes medio decentes, ¿podríamos especificar una lista de fuentes que nos gustaría ver ordenadas por preferencia? Si debemos usar fuentes web, debemos asegurarnos de que nuestras fuentes tengan el mejor rendimiento posible.
  • ¿Incrustamos videos de YouTube?
    Un video incrustado de YouTube generalmente agrega alrededor de un megabyte de transferencia de datos antes de que alguien interactúe con él. Si solo una fracción de nuestros usuarios realmente se va a sentar y ver el video incrustado en nuestro sitio web, ¿podríamos vincularlo en su lugar?

examinar todo

En este sentido, también podemos interrogar cada aspecto de nuestras páginas. ¿Qué merece realmente estar ahí? ¿Nuestra barra lateral agrega algún valor real, o simplemente pusimos una allí porque la convención dicta que los sitios web tienen barras laterales? Entonces, agregamos uno y lo llenamos de basura.

Con Susty, experimenté con el enfoque poco ortodoxo de relegar la navegación a su propia página. Esto me permite tener páginas que se reducen literalmente a lo esencial, con contenido adicional que solo se carga a pedido explícito del usuario. Susty es tan ligero y tan rápido que me di cuenta a través de una investigación de usuarios (también conocido como mi socio) que la carga del menú realmente no se sentía como una página nueva, así que decidí hacer que pareciera una superposición, con una cruz para descartar que en realidad solo te lleva de vuelta a la página anterior.

Además de ayudarme a crear páginas agradablemente livianas, la navegación relegada también elimina la necesidad de cualquier código oculto/revelador sofisticado para mostrarlo. En este punto, me gustaría dejar claro que Susty es un ejemplo de cómo llevar al extremo las técnicas de diseño web sostenible (no estoy sugiriendo que sea un arquetipo de un buen sitio web).

Escribe CSS como tu abuela

Cuando se trata de una mejora seria del rendimiento, debemos tener en cuenta que, literalmente, cada carácter del código cuenta. Cada carácter representa un byte, e incluso después de haber sido comprimidos por gzip, siguen ocupando peso. CSS es un dominio en el que a menudo vemos mucha hinchazón. Afortunadamente, existe un número creciente de herramientas cada vez más complejas que pueden ayudarlo a eliminar el CSS no utilizado. ¡Esta fantástica publicación de Sarah Dayan describe cómo redujo su paquete de CSS de 259 KB a 9 KB!

Si estamos comenzando desde cero, tal vez deberíamos pensar más profundamente en cómo escribimos CSS en primer lugar. Heydon Pickering escribió una excelente publicación sobre cómo podemos escribir CSS de una manera que aproveche las fortalezas de cómo se diseñó la sintaxis y cómo esto puede ayudar a los desarrolladores a evitar la repetición. Heydon también señala cuánto desperdicio se produce con el uso excesivo de divs y clases, tanto en HTML como en CSS.

¿Qué estás analizando?

Parece haberse vuelto más o menos omnipresente en la web para que todos analicen lo que hacen los visitantes de su sitio web a través de herramientas como Google Analytics, KISSmetrics, Piwik, etc. Si bien no tengo dudas de que existen casos de uso legítimos, ¿realmente ¿Necesita análisis en cada sitio web? Yo, por mi parte, normalmente he agregado Google Analytics a todos los sitios que administro de manera rutinaria. Pero hace relativamente poco me di cuenta de que para la mayoría de los sitios web en cuestión, este ha sido un esfuerzo casi completamente inútil: "Oh, seis personas llegaron a esta publicación a través de Facebook hoy". ¿A quien le importa?

A menos que realmente lo necesite, y vaya a analizar y actuar sobre los datos, simplemente deshágase de los análisis y encuentre una mejor manera de pasar su tiempo que quedarse boquiabierto ante la mundanidad de cuántas personas visitaron el sitio web X hoy.

Además de aumentar el peso de su página, el uso de algo como Google Analytics plantea cuestiones éticas sobre los datos que recopila sobre sus usuarios en nombre de Google, es decir, hay una razón por la que Google le proporciona Analytics de forma gratuita.

No olvidemos lo básico

Hay tanta información en estos días sobre lo siguiente, pero nunca debemos caer en la complacencia y olvidarnos de ellos. Además de todo lo anterior, siempre debemos minimizar HTML, CSS y JavaScript, y concatenar cuando corresponda. También debemos comprimir todas las imágenes para asegurarnos de que sean lo más pequeñas posible, usar los formatos correctos en las configuraciones correctas y usar el renderizado progresivo.

Rendimiento del lado del servidor

Hasta ahora, nuestro enfoque se ha centrado casi por completo en el front-end, pero mucho de esto se vuelve irrelevante si no optimizamos también las cosas en el lado del servidor. Ya lo mencioné un par de veces, pero deberíamos habilitar la compresión gzip en todo momento.

Debemos hacer que el servicio de nuestro sitio web sea lo más fácil posible para nuestro servidor. Predominantemente uso Nginx, y tengo un cariño particular por el caché FastCGI y he encontrado que es especialmente eficiente. Si tiene acceso de shell a su propio servidor, aquí hay una publicación que explica cómo configurarlo. Hay opciones menos técnicas si no tiene (o no quiere) tanto control sobre su servidor. Un favorito particular en el espacio de WordPress es WP Super Cache.

Deberíamos usar HTTP2 sobre HTTPS. El uso de HTTPS abre un mundo de nuevas tecnologías web, como los trabajadores de servicios, que nos permiten tratar la red en sí como algo agradable. Si desea obtener más información sobre esto, le recomiendo el nuevo libro de Jeremy Keith, "Going Offline".

Nota : también puede investigar el módulo PageSpeed ​​de Google, disponible tanto para Apache como para Nginx.

Finalmente, el mayor impacto que podemos tener aquí es alojar nuestros sitios web en centros de datos alimentados por energía renovable. En el Reino Unido, puedo recomendar Krystal y Kualo en términos de empresas con las que alojo directamente mis sitios. (Para obtener un directorio completo de servidores web ecológicos, consulte The Green Web Foundation).

En conclusión

Espero haberte convencido de que vale la pena esforzarse para que nuestros sitios web sean más sostenibles. Especialmente dado que en el proceso también hacemos nuestros sitios web:

  • Más rendimiento,
  • Más fácil de usar,
  • Más accesible,
  • Más amigable para el servidor,
  • Mejor optimizado para motores de búsqueda.

Una respuesta que algunas personas tienen a la idea del diseño web sostenible, lo cual no es descabellado, es que parece ser una concesión muy pequeña a la causa ambiental. Por supuesto, el impacto que puede tener depende de cuán ocupados estén los sitios web en los que trabaja. Pero además de ayudar a que la web se vuelva un poco más respetuosa con el medio ambiente, el diseño web sostenible es fundamentalmente un diseño web de mejores prácticas.

También vale la pena pensar en compensar las emisiones de carbono que no puedes evitar. A veces se ridiculiza la compensación de carbono, y con razón. El principal problema con la compensación es que, por lo general, el plazo durante el cual se compensará el carbono es bastante largo. Por ejemplo, con la plantación de árboles, la cifra dada para la cantidad de carbono secuestrado generalmente se basa en un período de 100 años. Entonces, en términos de reducir las emisiones de carbono ahora, no es realmente una solución. Pero es mejor que nada.

El lema de myclimate es hacer lo mejor posible y compensar el resto. He escrito una publicación de blog sobre la implementación de su propio esquema de compensación de carbono. También recomiendo encarecidamente la iniciativa 1% For The Planet. Finalmente, si usted es dueño de un negocio y le gustaría unirse a una alianza de empresas que quieren ver una mejor justicia social, ambiental y económica, consulte el esquema de Empresa B Certificada.