Reduzindo as emissões de carbono na web

Como é o caso de muitos outros desenvolvedores, os relatórios dos últimos anos sobre os enormes requisitos de energia da web me levaram a dar uma olhada em meus próprios sites e ver o que posso fazer para minimizar seu impacto. Este artigo abordará algumas das minhas experiências ao fazer isso, bem como meus pensamentos atuais sobre otimização de sites para emissões de carbono e alguns exemplos práticos de coisas que você pode fazer para melhorar suas próprias páginas.

Mas primeiro, uma confissão: quando ouvi pela primeira vez sobre o impacto ambiental dos sites, não acreditei muito. Afinal, o digital deveria ser melhor para o planeta, não é?

Estou envolvido em vários grupos verdes e ambientais há décadas. Em todo esse tempo, não consigo me lembrar conscientemente de ninguém discutindo os possíveis impactos ambientais da web . O foco sempre foi a redução do consumo e o afastamento da queima de combustíveis fósseis. A única vez que a Internet foi mencionada foi como uma ferramenta de comunicação uns com os outros sem a necessidade de derrubar mais árvores, ou para trabalhar sem deslocamento.

Então, quando as pessoas começaram a falar sobre a Internet ter emissões de carbono semelhantes às do setor aéreo, fiquei um pouco cético.

Emissões

Pode ser difícil visualizar a enorme rede de hardware que permite enviar uma solicitação de uma página para um servidor e receber uma resposta de volta. A maioria de nós não mora em centros de dados, e os cabos que transportam os sinais de um computador para outro geralmente estão enterrados sob nossos pés. Quando você não consegue ver um processo em ação, a coisa toda pode parecer um pouco mágica – algo que não é ajudado pela insistência de certas empresas em adicionar palavras como “nuvem” e “sem servidor” aos nomes de seus produtos.

Como resultado disso, minha visão da Internet por muito tempo foi um pouco efêmera, uma espécie de miragem. Quando comecei a escrever este artigo, no entanto, realizei um pequeno experimento mental: por quantas peças de hardware um sinal viaja do computador em que estou escrevendo para sair de casa?

A resposta foi bastante chocante: 3 cabos cat, um switch, 2 adaptadores powerline, um roteador e modem, um cabo RJ11 e vários metros de fiação elétrica. De repente, aquela miragem estava começando a parecer mais sólida.

Claro, a web (qualquer, por extensão, os sites que fazemos) tem uma pegada de carbono. Todos os servidores, roteadores, switches, modems, repetidores, cabines telefônicas, conversores óptico-elétricos e uplinks de satélite da Internet devem ser construídos a partir de metais extraídos da Terra e de plásticos refinados de petróleo bruto. Para fornecer dados aos estimados 20 bilhões de dispositivos conectados em todo o mundo, eles precisam consumir eletricidade, que também libera carbono quando é gerada (mesmo a eletricidade renovável não é neutra em carbono, embora seja muito melhor que os combustíveis fósseis).

Medir exatamente quais são essas emissões é provavelmente impossível – cada dispositivo é diferente e a energia que os alimenta pode variar ao longo de um dia – mas podemos ter uma ideia aproximada observando os números típicos de consumo de energia, bases de usuários e em breve. Uma ferramenta que usa esses dados para estimar as emissões de carbono de uma única página é o Website Carbon Calculator. Segundo ele, a página média testada “produz 1,76 gramas de CO2 por visualização de página”.

Se você está acostumado a pensar no trabalho que faz como essencialmente inofensivo ao meio ambiente, essa percepção pode ser bastante desanimadora. A boa notícia é que, como desenvolvedores, podemos fazer muito sobre isso.

Leitura recomendada : Como melhorar o desempenho do site pode ajudar a salvar o planeta

Desempenho e emissões

Se lembrarmos que a visualização de sites usa eletricidade e que a produção de eletricidade libera carbono, saberemos que as emissões de uma página devem depender muito da quantidade de trabalho que o servidor e o cliente precisam realizar para exibir a página. Além disso, a quantidade de dados necessária para a página e a complexidade da rota pela qual ela deve percorrer determinarão a quantidade de carbono liberada pela própria rede.

Por exemplo, baixar e renderizar example.com provavelmente consumirá muito menos eletricidade do que a página inicial da Apple e também será muito mais rápido. Na verdade, o que estamos dizendo é que altas emissões e carregamentos de página lentos são apenas dois sintomas das mesmas causas subjacentes.

Está tudo muito bem falar sobre esse relacionamento em teoria, é claro, mas ter alguns dados do mundo real para respaldá-lo seria bom. Para fazer exatamente isso, decidi realizar um pequeno estudo. Eu escrevi um programa simples de interface de linha de comando para obter uma lista dos 500 sites mais populares da Internet, de acordo com o MOZ, e verificar suas páginas iniciais com o PageSpeed ​​Insights do Google e o Website Carbon Calculator.

Algumas das verificações expiraram (geralmente porque a página em questão simplesmente demorou muito para carregar), mas, no total, consegui coletar resultados para mais de 400 páginas em 14 de julho de 2021. Você pode baixar o resumo dos resultados para examinar a si mesmo, mas para fornecer uma indicação visual, eu os plotei no gráfico abaixo:

Como você pode ver, embora a variação entre sites individuais seja muito alta, há uma forte tendência de redução de emissões de páginas mais rápidas. A média das emissões médias para sites com pontuação PageSpeed ​​de 100 é de cerca de 1 grama de carbono, o que sobe para uma projeção de quase 6 gramas para sites com pontuação 0. Acho um pouco tranquilizador que, apesar de haver muitos sites com uma pontuação muito baixa, velocidades e altas emissões, a maioria dos resultados está agrupada no canto inferior direito do gráfico.

Ação

Assim que entendermos que grande parte das emissões de uma página se originam de um desempenho ruim, podemos começar a tomar medidas para reduzi-las. Muitas das coisas que contribuem para as emissões de um site estão além do nosso controle como desenvolvedores. Não podemos, por exemplo, escolher os dispositivos pelos quais nossos usuários acessam nossas páginas ou decidir sobre a infraestrutura de rede pela qual suas solicitações trafegam, mas podemos tomar medidas para melhorar o desempenho de nossos sites.

A otimização de desempenho é um tópico amplo, e muitos de vocês que estão lendo isso provavelmente têm mais experiência do que eu, mas gostaria de mencionar brevemente algumas coisas que observei recentemente ao otimizar a velocidade de carregamento de várias páginas e as emissões de carbono.

A renderização é muito mais lenta em dispositivos móveis

Recentemente, reformulei o design do meu blog pessoal para torná-lo um pouco mais amigável. Um dos meus hobbies é a fotografia, e o site já havia apresentado uma imagem de cabeçalho de altura total.

Embora o design tenha feito um bom trabalho ao mostrar minhas fotos, foi uma dor completa percorrer as páginas, especialmente ao percorrer as páginas dos posts do blog. Eu não queria perder a sensação de ter uma foto no cabeçalho, no entanto, e acabei decidindo usá-la como plano de fundo para o título da página.

O cabeçalho de altura total estava usando srcset para tornar o carregamento o mais rápido possível, mas as imagens ainda eram muito grandes em telas de alta resolução, e meu maior tempo de pintura de conteúdo (LCP) no celular para o design antigo foi de quase 3 segundos. Uma grande vantagem do novo design foi que ele me permitiu tornar as imagens muito menores, o que reduziu o tempo de LCP para cerca de 1,5 segundos.

Em laptops e desktops, as pessoas não teriam notado a diferença, porque ambas as versões duravam menos de um segundo, mas em dispositivos móveis muito menos poderosos, era bastante dramático. Qual foi o efeito dessa mudança nas emissões de carbono? 0,31 gramas por visualização antes, 0,05 gramas depois. A decodificação e a renderização de imagens consomem muitos recursos , e isso cresce exponencialmente à medida que as imagens ficam maiores.

O tamanho das imagens não é a única coisa que pode afetar o tempo de decodificação; o formato também é importante. O Lighthouse do Google geralmente recomenda a exibição de imagens em formatos de última geração para reduzir a quantidade de dados que precisam ser baixados, mas os novos formatos geralmente são mais lentos para decodificar, especialmente em dispositivos móveis. Enviar menos dados pela rede é melhor para o ambiente, mas é possível que consumir mais energia para decodificar possa compensar esse benefício. Tal como acontece com a maioria das coisas, o teste é fundamental aqui.

De meus próprios testes na tentativa de adicionar suporte para codificação AVIF ao gerador de site estático Zola, descobri que AVIF, que promete tamanhos de arquivo muito menores que JPG com a mesma qualidade, levou muito mais tempo para codificar; algo que a observação do bunny.net de que o WebP supera o AVIF em até 100 vezes o suporte. Ao fazer isso, o servidor estará consumindo eletricidade, e eu me pergunto se, para sites com baixa contagem de visitantes, a mudança para o novo formato pode realmente acabar aumentando as emissões e reduzindo o desempenho.

As imagens, é claro, não são o único componente das páginas da web modernas que levam muito tempo para serem processadas. Pequenos arquivos JavaScript, dependendo do que estão fazendo, podem levar muito tempo para serem executados e as mesmas armadilhas potenciais que as imagens serão aplicadas.

Leitura recomendada : The Humble img Element And Core Web Vitals

Soma de ida e volta

Outra coisa que pode ter um impacto surpreendente no desempenho e nas emissões é a origem dos dados. A sabedoria convencional diz há muito tempo que servir ativos como estruturas de uma rede central de entrega de conteúdo (CDN) melhorará o desempenho porque obter dados de nós locais geralmente é mais rápido para os usuários do que de um servidor central. jQuery, por exemplo, tem a opção de ser carregado a partir de uma CDN, e seus mantenedores dizem que isso pode melhorar o desempenho, mas testes no mundo real de Harry Roberts mostraram que recursos de auto-hospedagem geralmente são mais rápidos.

Esta também tem sido a minha experiência. Recentemente, ajudei um site de jogos a melhorar seu desempenho. O site estava usando uma estrutura CSS bastante grande e carregando todos os seus recursos de terceiros por meio de um CDN. Mudamos para auto-hospedagem de todos os ativos e removemos componentes não utilizados da estrutura.

Nenhuma das otimizações resultou em alterações visuais no site, mas juntas elas aumentaram a pontuação do Lighthouse de 72 para 98 e reduziram as emissões de carbono de 0,26 gramas por visualização para 0,15.

Envie apenas o que você precisa

Isso leva muito bem ao assunto de enviar aos usuários apenas os dados de que eles realmente precisam. Trabalhei (e visitei) muitos, muitos sites que são dominados por imagens de pessoas de terno sorrindo umas para as outras. Parece haver uma mentalidade entre certas organizações de que o que elas fazem é realmente chato e que adicionar fotos de alguma forma convencerá o público em geral do contrário.

Eu meio que entendo o pensamento por trás disso, porque há vários artigos sobre como a quantidade de tempo que as pessoas passam lendo está diminuindo. O texto, dizem-nos repetidamente, está saindo de moda; todas as pessoas estão interessadas agora são vídeos e experiências interativas.

Desse ponto de vista, as fotos de banco de imagens podem ser vistas como uma ferramenta útil para animar as páginas, mas estudos de rastreamento ocular mostram que as pessoas ignoram imagens que não são relevantes. Quando as pessoas não estão olhando para suas imagens, as imagens também podem ser um espaço vazio. E quando cada byte custa dinheiro, contribui para a mudança climática e diminui o tempo de carregamento, seria melhor para todos se realmente existissem.

Novamente, o que pode ser dito para imagens pode ser dito para todo o resto que não seja o conteúdo central da página. Se algo não está contribuindo para a experiência de um usuário de maneira significativa, não deveria estar lá. Não estou nem por um momento defendendo que todos comecemos a servir páginas sem estilo – algumas pessoas, como as com dislexia, acham grandes blocos de texto difíceis de ler, e outros usuários quase certamente achariam essas páginas chatas e iriam para outro lugar – mas devemos olhar criticamente para cada parte de nossos sites para considerar se eles estão ganhando seu sustento.

Acessibilidade e Meio Ambiente

Outra área onde o desempenho e as emissões convergem é no campo da acessibilidade. Há um equívoco comum de que tornar sites acessíveis envolve adicionar atributos de aria e JavaScript a uma página, mas muitas vezes o que você deixa de fora é mais importante do que o que você coloca, tornando um site acessível relativamente leve e com desempenho.

Usando elementos padrão

O MDN Web Docs tem alguns tutoriais muito bons sobre acessibilidade. Em “HTML: A Good Basis for Accessibility”, eles abordam como a melhor base de um site acessível está no uso dos elementos HTML corretos para o conteúdo. Uma das seções mais interessantes do artigo é onde eles tentam recriar a funcionalidade de um elemento de button usando um div e JavaScript personalizado.

Este é obviamente um exemplo mínimo, mas achei que seria interessante comparar o tamanho desta versão de botão com um que usa elementos HTML padrão. O exemplo de botão falso neste caso pesa cerca de 1.403 bytes sem compactação, enquanto um button real com menos JavaScript e sem estilo pesa 746 bytes. O botão div também será semanticamente sem sentido e, portanto, muito mais difícil para as pessoas com leitores de tela usarem e para os bots analisarem.

Leitura recomendada : SVGs acessíveis: padrões perfeitos para usuários de leitores de tela

Quando ampliados, esses tipos de coisas fazem a diferença. Analisar marcação mínima e JavaScript é mais fácil para um navegador, assim como é mais fácil para desenvolvedores.

Em uma escala maior, recentemente refatorei o HTML de um site em que trabalho – fazendo coisas como remover atributos de título redundantes e substituir div s por mais equivalentes semânticos. A página original tinha uma estrutura como a seguinte (conteúdo removido para fins de privacidade e brevidade):

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

Com o conteúdo completo, isso pesava 34.168 bytes.

Após a refatoração, a estrutura ficou assim:

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

Ele pesava 32.805 bytes.

As mudanças estão em andamento, mas a marcação já é muito mais acessível de acordo com WebAIM, Lighthouse e testes manuais. O tamanho do arquivo também diminuiu e, ao calcular a média do tempo de cinco perfis no Chrome, o tempo para analisar o HTML caiu cerca de 2 milissegundos.

Essas são obviamente pequenas mudanças e provavelmente não farão nenhuma diferença perceptiva para os usuários. No entanto, é bom saber que cada byte custa aos usuários e ao meio ambiente – tornar um site acessível também pode torná-lo um pouco mais leve.

Vídeos

A versão HTML do Project Gutenberg de The Complete Works of William Shakespeare tem aproximadamente 7,4 MB sem compressão. De acordo com a Android Authority em "Quantos dados o YouTube realmente usa?", um vídeo 360p do YouTube pesa cerca de 5 a 7,5 MB por minuto de filmagem e 1080p cerca de 50 a 68. Portanto, para a mesma quantidade de largura de banda que todas as peças de Shakespeare , você terá apenas cerca de 7 segundos de vídeo de alta definição. O vídeo também é muito intensivo para codificar e decodificar, e esse é provavelmente um fator importante que contribui para as estimativas de que as emissões de carbono da Netflix chegam a 3,2 kg por hora.

A maioria dos vídeos conta com componentes visuais e auditivos para comunicar sua mensagem, e arquivos grandes exigem um certo nível de conectividade . Isso obviamente coloca limites sobre quem pode se beneficiar de tal conteúdo. Tornar o vídeo acessível é possível, mas está longe de ser simples, e muitos sites simplesmente não se incomodam.

Se o vídeo fosse tratado apenas como uma forma de aprimoramento progressivo, talvez isso não fosse um problema, mas já perdi a conta do número de vezes que procurei algo na web e a única maneira de encontrar a informação que queria era assistindo a um vídeo. No YouTube, o número médio de usuários mensais cresceu de 20 milhões em 2006 para 2 bilhões em 2020. O Vimeo também tem uma base de usuários em crescimento contínuo.

Apesar do grande número de visitantes dos sites de compartilhamento de vídeos, muitos dos mais populares parecem não estar totalmente em conformidade com a legislação de acessibilidade. Em contraste com isso, vários tipos de tecnologias assistivas são projetados para tornar o texto simples acessível ao maior número possível de pessoas. O texto também é fácil de converter de um formato para outro, por isso pode ser usado em vários contextos diferentes.

Como podemos ver no exemplo de Shakespeare, o texto simples também é incrivelmente eficiente em termos de espaço e tem uma pegada de carbono muito menor do que qualquer outra forma de informação amigável transmitida na web.

O vídeo pode ser ótimo, e muitas pessoas aprendem melhor assistindo a um processo em ação, mas também deixa algumas pessoas de fora e tem um custo ambiental. Para manter nossos sites o mais leves e inclusivos possível, devemos tratar o texto como a principal forma de comunicação sempre que possível e oferecer itens como áudio e vídeo como extra.

Leitura recomendada : Otimizando o tamanho e a qualidade do vídeo

Para concluir

Espero que esta breve análise da minha experiência na tentativa de tornar os sites melhores para o meio ambiente tenha dado a você algumas ideias de coisas para experimentar em seus próprios sites. Pode ser bastante desanimador percorrer uma página através do Website Carbon Calculator e ser informado de que pode estar a emitir centenas de quilogramas de CO2 por ano. Felizmente, o tamanho da web pode amplificar tanto as mudanças positivas quanto as negativas, e até mesmo pequenas melhorias logo se acumulam em sites com milhares de visitantes por semana.

Embora estejamos vendo coisas como um site de 25 anos aumentando 39 vezes de tamanho após um redesenho, também estamos vendo sites sendo feitos para usar o mínimo de dados possível, e pessoas inteligentes estão descobrindo como entregar o WordPress em 7 KB. Portanto, para reduzirmos as emissões de carbono de nossos sites, precisamos torná-los mais rápidos — e isso beneficia a todos .

Leitura adicional

• Resíduos Mundiais, Gerry McGovern
• “O WebP é realmente melhor que o JPEG?”, Johannes Siipola
• “Tornar o Jamstack lento? Desafio aceito.”, Steve Keep, CSS-Tricks
• “A Internet pode ser verde?”, The Climate Question, BBC
• “Seu data center poderia não apenas alimentar seu site, mas também cultivar sua salada?”, Tom Greenwood, Wholegrain Digital
• The Better Web Alliance (meu próprio projeto)
• Manifesto Web Sustentável