Ridurre le emissioni di carbonio sul Web

Come nel caso di molti altri sviluppatori, i rapporti degli ultimi anni sull'enorme fabbisogno energetico del Web mi hanno spinto a dare un'occhiata ai miei siti Web e vedere cosa posso fare per ridurre al minimo il loro impatto. Questo pezzo tratterà alcune delle mie esperienze nel fare questo, così come i miei pensieri attuali sull'ottimizzazione dei siti Web per le emissioni di carbonio e alcuni esempi pratici di cose che puoi fare per migliorare le tue pagine.

Ma prima, una confessione: quando ho sentito parlare per la prima volta dell'impatto ambientale dei siti web, non ci credevo. Dopotutto, il digitale dovrebbe essere migliore per il pianeta, vero?

Sono stato coinvolto in vari gruppi ambientalisti e ambientalisti per decenni. In tutto questo tempo, non riesco a ricordare consapevolmente nessuno che abbia mai discusso dei possibili impatti ambientali del web . L'obiettivo è sempre stato quello di ridurre i consumi e di abbandonare la combustione di combustibili fossili. L'unico momento in cui Internet è stato menzionato è stato come strumento per comunicare tra loro senza la necessità di abbattere più alberi o per lavorare senza spostarsi.

Quindi, quando le persone hanno iniziato a parlare di Internet con emissioni di carbonio simili a quelle dell'industria aerea, ero un po' scettico.

Emissioni

Può essere difficile visualizzare l'enorme rete di hardware che ti consente di inviare una richiesta per una pagina a un server e quindi ricevere una risposta. La maggior parte di noi non vive nei data center e i cavi che trasportano i segnali da un computer all'altro sono spesso sepolti sotto i nostri piedi. Quando non riesci a vedere un processo in azione, l'intera faccenda può sembrare un po' magica, qualcosa che non è aiutato dall'insistenza di alcune aziende nell'aggiungere parole come "cloud" e "serverless" ai nomi dei loro prodotti.

Di conseguenza, la mia visione di Internet per molto tempo è stata un po' effimera, una sorta di miraggio. Quando ho iniziato a scrivere questo articolo, tuttavia, ho eseguito un piccolo esperimento mentale: quanti componenti hardware viaggia un segnale dal computer su cui sto scrivendo per uscire di casa?

La risposta è stata piuttosto scioccante: 3 cavi Cat, uno switch, 2 adattatori powerline, un router e un modem, un cavo RJ11 e diversi metri di cablaggio elettrico. Improvvisamente, quel miraggio cominciava a sembrare un po' più solido.

Naturalmente, il web (qualsiasi sito web che realizziamo per estensione) ha un'impronta di carbonio. Tutti i server, i router, gli switch, i modem, i ripetitori, gli armadi telefonici, i convertitori ottico-elettrici e gli uplink satellitari di Internet devono essere costruiti con metalli estratti dalla Terra e con plastica raffinata dal petrolio greggio. Per poi fornire dati ai circa 20 miliardi di dispositivi connessi in tutto il mondo, devono consumare elettricità, che rilascia anche carbonio quando viene generata (anche l'elettricità rinnovabile non è carbon neutral, sebbene sia molto meglio dei combustibili fossili).

Misurare esattamente quali sono queste emissioni è probabilmente impossibile — ogni dispositivo è diverso e l'energia che li alimenta può variare nel corso della giornata — ma possiamo avere un'idea approssimativa osservando i valori tipici per il consumo di energia, le basi di utenti e presto. Uno strumento che utilizza questi dati per stimare le emissioni di carbonio di una singola pagina è il Website Carbon Calculator. Secondo esso, la pagina media testata "produce 1,76 grammi di CO2 per pagina visualizzata".

Se sei stato abituato a pensare al lavoro che svolgi come essenzialmente innocuo per l'ambiente, questa consapevolezza può essere piuttosto scoraggiante. La buona notizia è che, come sviluppatori, possiamo fare molto al riguardo.

Letture consigliate : Come migliorare le prestazioni del sito Web può aiutare a salvare il pianeta

Prestazioni ed emissioni

Se ricordiamo che la visualizzazione di siti Web utilizza elettricità e che la produzione di elettricità rilascia carbonio, allora sapremo che le emissioni di una pagina devono dipendere fortemente dalla quantità di lavoro che sia il server che il client devono eseguire per visualizzare la pagina. Inoltre, la quantità di dati richiesta per la pagina e la complessità del percorso che deve percorrere determineranno la quantità di carbonio rilasciata dalla rete stessa.

Ad esempio, il download e il rendering di example.com consumerà probabilmente molta meno elettricità rispetto alla home page di Apple e sarà anche molto più veloce. In effetti, quello che stiamo dicendo è che le emissioni elevate e il caricamento lento delle pagine sono solo due sintomi delle stesse cause sottostanti.

Va benissimo parlare di questa relazione in teoria, ovviamente, ma avere alcuni dati del mondo reale per sostenerla sarebbe bello. Per fare proprio questo, ho deciso di condurre un piccolo studio. Ho scritto un semplice programma di interfaccia a riga di comando per prendere un elenco dei 500 siti Web più popolari su Internet, secondo MOZ, e confrontare le loro home page sia con PageSpeed ​​Insights di Google che con Website Carbon Calculator.

Alcuni dei controlli sono scaduti (spesso perché la pagina in questione ha semplicemente impiegato troppo tempo a caricarsi), ma in totale sono riuscito a raccogliere risultati per oltre 400 pagine il 14 luglio 2021. Puoi scaricare il riepilogo dei risultati per esaminarti ma per fornire un'indicazione visiva, li ho tracciati nella tabella seguente:

Come puoi vedere, mentre la variazione tra i singoli siti web è molto elevata, c'è una forte tendenza verso minori emissioni da pagine più veloci. Le emissioni medie medie per i siti Web con un punteggio PageSpeed ​​di 100 sono di circa 1 grammo di carbonio, che sale a quasi 6 grammi previsti per i siti Web con un punteggio di 0. Trovo leggermente rassicurante il fatto che, nonostante ci siano molti siti Web con un punteggio molto basso velocità ed emissioni elevate, la maggior parte dei risultati sono raggruppati in basso a destra nel grafico.

Prendere l'iniziativa

Una volta compreso che gran parte delle emissioni di una pagina derivano da scarse prestazioni, possiamo iniziare ad adottare misure per ridurle. Molte delle cose che contribuiscono alle emissioni di un sito web sono al di fuori del nostro controllo come sviluppatori. Non possiamo, ad esempio, scegliere i dispositivi da cui i nostri utenti accedono alle nostre pagine o decidere l'infrastruttura di rete attraverso la quale viaggiano le loro richieste, ma possiamo adottare misure per migliorare le prestazioni dei nostri siti web.

L'ottimizzazione delle prestazioni è un argomento ampio e molti di voi che stanno leggendo questo probabilmente hanno più esperienza di me, ma vorrei menzionare brevemente alcune cose che ho osservato di recente durante l'ottimizzazione della velocità di caricamento di varie pagine e delle emissioni di carbonio.

Il rendering è molto più lento sui dispositivi mobili

Di recente ho rielaborato il design del mio blog personale per renderlo un po' più user-friendly. Uno dei miei hobby è la fotografia e in precedenza il sito Web conteneva un'immagine di intestazione a tutta altezza.

Anche se il design ha fatto un buon lavoro nel mostrare le mie fotografie, è stato un vero dolore scorrere oltre, specialmente quando ci si sposta attraverso le pagine dei post del blog. Tuttavia, non volevo perdere la sensazione di avere una foto nell'intestazione e alla fine ho deciso di usarla come sfondo per il titolo della pagina.

L'intestazione a tutta altezza utilizzava srcset per rendere il caricamento il più veloce possibile, ma le immagini erano ancora molto grandi su schermi ad alta risoluzione e il mio tempo più lungo di contentful paint (LCP) su dispositivo mobile per il vecchio design era quasi 3 secondi. Un grande vantaggio del nuovo design era che mi permetteva di rendere le immagini molto più piccole, riducendo il tempo LCP a circa 1,5 secondi.

Su laptop e desktop, le persone non avrebbero notato alcuna differenza, perché entrambe le versioni duravano ben meno di un secondo, ma su dispositivi mobili molto meno potenti, era piuttosto drammatico. Qual è stato l'effetto di questo cambiamento sulle emissioni di carbonio? 0,31 grammi per visualizzazione prima, 0,05 grammi dopo. La decodifica e il rendering delle immagini richiedono molte risorse e questo aumenta in modo esponenziale man mano che le immagini diventano più grandi.

La dimensione delle immagini non è l'unica cosa che può influire sui tempi di decodifica; anche il formato è importante. Il faro di Google consiglia spesso di offrire immagini nei formati di nuova generazione per ridurre la quantità di dati da scaricare, ma i nuovi formati sono spesso più lenti da decodificare, soprattutto sui dispositivi mobili. L'invio di meno dati via cavo è migliore per l'ambiente, ma è possibile che il consumo di più energia per la decodifica possa compensare tale vantaggio. Come per la maggior parte delle cose, il test è fondamentale qui.

Dai miei test nel tentativo di aggiungere il supporto per la codifica AVIF al generatore di siti statici di Zola, ho scoperto che AVIF, che promette dimensioni di file molto più piccole di JPG con la stessa qualità, ha richiesto ordini di grandezza più lunghi per la codifica; qualcosa che l'osservazione di bunny.net secondo cui WebP supera AVIF fino a 100 volte supporta. Durante questa operazione, il server consumerà elettricità e mi chiedo se, per i siti Web con un basso numero di visitatori, il passaggio al nuovo formato potrebbe effettivamente aumentare le emissioni e ridurre le prestazioni.

Le immagini, ovviamente, non sono l'unico componente delle pagine Web moderne che richiedono molto tempo per essere elaborate. Piccoli file JavaScript, a seconda di ciò che stanno facendo, possono richiedere molto tempo per essere eseguiti e si applicano le stesse potenziali insidie ​​delle immagini.

Letture consigliate : L'umile img Element e i core Web Vitals

I viaggi di andata e ritorno si sommano

Un'altra cosa che può avere un impatto sorprendente sulle prestazioni e sulle emissioni è la provenienza dei dati. La saggezza convenzionale ha da tempo affermato che la fornitura di risorse come i framework da una rete di distribuzione dei contenuti (CDN) centrale migliorerà le prestazioni perché ottenere dati dai nodi locali è generalmente più veloce per gli utenti rispetto a un server centrale. jQuery, ad esempio, ha la possibilità di essere caricato da una CDN e i suoi manutentori affermano che ciò può migliorare le prestazioni, ma i test nel mondo reale di Harry Roberts hanno dimostrato che le risorse di self-hosting sono generalmente più veloci.

Questa è stata anche la mia esperienza. Di recente ho aiutato un sito Web di giochi a migliorare le sue prestazioni. Il sito Web utilizzava un framework CSS abbastanza grande e caricava tutte le sue risorse di terze parti tramite una CDN. Siamo passati all'hosting automatico di tutte le risorse e abbiamo rimosso i componenti inutilizzati dal framework.

Nessuna delle ottimizzazioni ha comportato modifiche visive al sito Web, ma insieme hanno aumentato il punteggio di Lighthouse da 72 a 98 e ridotto le emissioni di carbonio da 0,26 grammi per visualizzazione a 0,15.

Invia solo ciò di cui hai bisogno

Questo porta bene all'argomento dell'invio agli utenti solo dei dati di cui hanno effettivamente bisogno. Ho lavorato (e visitato) moltissimi siti Web dominati da immagini di stock di persone in giacca e cravatta che si sorridono a vicenda. Sembra esserci una mentalità tra alcune organizzazioni secondo cui quello che fanno è davvero noioso e che l'aggiunta di foto in qualche modo convincerà il pubblico in generale del contrario.

Posso in qualche modo capire il pensiero alla base di questo perché ci sono numerosi pezzi su come la quantità di tempo che le persone trascorrono a leggere sta diminuendo. Il testo, ci viene ripetuto più volte, sta passando di moda; tutte le persone che sono interessate ora sono video ed esperienze interattive.

Da questo punto di vista, le foto d'archivio potrebbero essere viste come uno strumento utile per ravvivare le pagine, ma studi di eye-tracking mostrano che le persone ignorano le immagini che non sono rilevanti. Quando le persone non guardano le tue immagini, le immagini potrebbero anche essere uno spazio vuoto. E quando ogni byte costa denaro, contribuisce al cambiamento climatico e rallenta i tempi di caricamento, sarebbe meglio per tutti se lo fosse davvero.

Ancora una volta, ciò che si può dire per le immagini può essere detto per tutto il resto che non è il contenuto principale della pagina. Se qualcosa non sta contribuendo all'esperienza di un utente in modo significativo, non dovrebbe essere lì. Non sto sostenendo per un momento che tutti iniziamo a pubblicare pagine senza stile - alcune persone, come quelle con dislessia, trovano grandi blocchi di testo difficili da leggere e altri utenti quasi certamente troverebbero tali pagine noiose e andrebbero altrove - ma dovremmo esaminare in modo critico ogni parte dei nostri siti Web per valutare se si stanno guadagnando da vivere.

Accessibilità e Ambiente

Un altro settore in cui convergono prestazioni ed emissioni è quello dell'accessibilità. C'è un malinteso comune sul fatto che rendere accessibili i siti Web implichi l'aggiunta di attributi aria e JavaScript a una pagina, ma spesso ciò che si omette è più importante di ciò che si inserisce, rendendo un sito Web accessibile relativamente leggero e performante.

Utilizzo di elementi standard

MDN Web Docs ha degli ottimi tutorial sull'accessibilità. In "HTML: una buona base per l'accessibilità", spiegano come il miglior fondamento di un sito Web accessibile risiede nell'utilizzo degli elementi HTML corretti per il contenuto. Una delle sezioni più interessanti dell'articolo è dove cercano di ricreare la funzionalità di un elemento button utilizzando un div e JavaScript personalizzato.

Questo è ovviamente un esempio minimo, ma ho pensato che sarebbe stato interessante confrontare la dimensione di questa versione del pulsante con quella che utilizza elementi HTML standard. L'esempio del pulsante falso in questo caso pesa circa 1.403 byte non compresso, mentre un button reale con meno JavaScript e nessuno stile pesa 746 byte. Il pulsante div sarà anche semanticamente privo di significato e, quindi, molto più difficile da usare per le persone con lettori di schermo e da analizzare per i bot.

Letture consigliate : SVG accessibili: modelli perfetti per gli utenti di screen reader

Quando ingrandito, questo genere di cose fa la differenza. Analizzare il markup minimo e JavaScript è più facile per un browser, così come è più facile per gli sviluppatori.

Su una scala più ampia, stavo recentemente refactoring dell'HTML di un sito Web su cui lavoro, facendo cose come rimuovere gli attributi del titolo ridondanti e sostituire i div con più equivalenti semantici. La pagina originale aveva una struttura come la seguente (contenuto rimosso per privacy e brevità):

 <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 il contenuto completo, questo pesava 34.168 byte.

Dopo il refactoring, la struttura era simile a questa:

 <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>

Pesava 32.805 byte.

Le modifiche sono attualmente in corso, ma già il markup è molto più accessibile secondo WebAIM, Lighthouse e test manuali. Anche la dimensione del file è diminuita e, calcolando la media del tempo di cinque profili in Chrome, il tempo per analizzare l'HTML è diminuito di circa 2 millisecondi.

Questi sono ovviamente piccoli cambiamenti e probabilmente non faranno alcuna differenza percettiva per gli utenti. Tuttavia, è bello sapere che ogni byte costa agli utenti e all'ambiente : rendere accessibile un sito Web può anche renderlo un po' più leggero.

Video

La versione HTML di Project Gutenberg di The Complete Works of William Shakespeare è di circa 7,4 MB non compresso. Secondo Android Authority in "Quanti dati utilizza effettivamente YouTube?", un video YouTube a 360p pesa da 5 a 7,5 MB per minuto di metraggio e 1080p da 50 a 68. Quindi, per la stessa quantità di larghezza di banda di tutte le opere di Shakespeare , otterrai solo circa 7 secondi di video ad alta definizione. Anche il video è molto impegnativo da codificare e decodificare, e questo è probabilmente un importante fattore che contribuisce alle stime delle emissioni di carbonio di Netflix fino a 3,2 kg all'ora.

La maggior parte dei video si basa su componenti sia visivi che uditivi per comunicare il proprio messaggio e file di grandi dimensioni richiedono un certo livello di connettività . Questo ovviamente pone dei limiti a chi può beneficiare di tali contenuti. Rendere i video accessibili è possibile ma tutt'altro che semplice e molti siti Web semplicemente non si preoccupano.

Se il video fosse trattato solo come una forma di miglioramento progressivo, questo forse non sarebbe un problema, ma ho perso il conto del numero di volte in cui ho cercato qualcosa sul web e l'unico modo per trovare le informazioni che ho voluto era guardando un video. Su YouTube, il numero medio di utenti mensili è cresciuto da 20 milioni nel 2006 a 2 miliardi nel 2020. Vimeo ha anche una base di utenti in continua crescita.

Nonostante l'enorme numero di visitatori dei siti Web di condivisione video, molti di quelli più popolari non sembrano essere pienamente conformi alla legislazione sull'accessibilità. In contrasto con ciò, numerosi tipi di tecnologie assistive sono progettati per rendere il testo semplice accessibile al maggior numero possibile di persone. Il testo è anche facile da convertire da un formato all'altro, quindi può essere utilizzato in diversi contesti.

Come possiamo vedere dall'esempio di Shakespeare, il testo normale è anche incredibilmente efficiente in termini di spazio e ha un'impronta di carbonio di gran lunga inferiore rispetto a qualsiasi altra forma di informazione umana trasmessa sul web.

Il video può essere fantastico e molte persone imparano meglio guardando un processo in azione, ma esclude anche alcune persone e ha un costo ambientale. Per mantenere i nostri siti Web il più leggeri e inclusivi possibile, dovremmo trattare il testo come la principale forma di comunicazione ove possibile e offrire elementi come audio e video come extra.

Letture consigliate : Ottimizzazione del video per dimensioni e qualità

In conclusione

Si spera che questo breve sguardo alla mia esperienza nel tentativo di rendere i siti Web migliori per l'ambiente ti abbia dato alcune idee su cose da provare sui tuoi siti Web. Può essere abbastanza scoraggiante scorrere una pagina attraverso il Website Carbon Calculator e sentirsi dire che potrebbe emettere centinaia di chilogrammi di CO2 all'anno. Fortunatamente, la vastità del web può amplificare i cambiamenti positivi oltre a quelli negativi, e anche piccoli miglioramenti si sommano presto sui siti web con migliaia di visitatori alla settimana.

Anche se stiamo vedendo cose come un sito Web di 25 anni che aumenta di 39 volte le dimensioni dopo una riprogettazione, stiamo anche vedendo siti Web realizzati per utilizzare il minor numero di dati possibile e persone intelligenti stanno cercando di capire come fornire WordPress in 7 KB. Quindi, per poter ridurre le emissioni di carbonio dei nostri siti Web, dobbiamo renderli più veloci e questo va a vantaggio di tutti .

Ulteriori letture

• I rifiuti in tutto il mondo, Gerry McGovern
• "WebP è davvero meglio di JPEG?", Johannes Siipola
• “Rendi Jamstack lento? Sfida accettata.", Steve Keep, CSS-Tricks
• "Internet può mai essere verde?", The Climate Question, BBC
• "Il tuo data center potrebbe non solo alimentare il tuo sito web, ma anche far crescere la tua insalata?", Tom Greenwood, Wholegrain Digital
• The Better Web Alliance (il mio progetto)
• Manifesto del web sostenibile