A pegada de carbono de um site: quanto CO2 produz realmente cada visualização

A pegada de carbono de um site é o gás com efeito de estufa emitido para entregar e apresentar as suas páginas — a energia consumida pelos centros de dados, a rede que transporta os bytes e o próprio dispositivo do visitante. Uma visualização típica situa-se algalgures entre 0,2 e 1,0 gramas de CO2, e a maior alavanca que controla é o peso da página: menos bytes, sobretudo menos JavaScript, significam menos energia em cada salto. O web design sustentável é, na sua maioria, engenharia de desempenho com consciência.

Construímos sites para viver na Amplified Creations, e descobrimos que as mesmas decisões que tornam um site rápido também o tornam mais leve para o planeta. Este artigo explica de onde vêm realmente as emissões, como medir a sua pegada de forma honesta e as reduções concretas que mexem com o número.

O que é a pegada de carbono de um site?

Quando alguém pergunta "quanto CO2 produz um site", está na verdade a perguntar sobre três custos de energia empilhados por visualização:

• Energia do servidor — o centro de dados que corre a sua aplicação, consulta a base de dados e gera a resposta. É amortizada por todos os visitantes, mas trabalho pesado no servidor (consultas sem cache, frameworks inchadas) acumula-se.
• Energia de rede / transferência de dados — cada byte viaja por routers, switches, cabos submarinos e antenas. É aproximadamente proporcional aos quilobytes que envia. É a parte mais diretamente sob o controlo de quem programa.
• Energia do dispositivo — o telemóvel ou portátil do visitante gasta CPU e bateria a descomprimir imagens, a interpretar e executar JavaScript e a desenhar a página. Um pacote de 2 MB de JavaScript não custa só transferência; obriga um telemóvel Android de gama média a trabalhar muito, repetidamente.

A estimativa frequentemente citada é que a internet é responsável por cerca de 2 a 4% das emissões globais de carbono, na mesma ordem de grandeza da aviação. Por visualização, modelos como o Sustainable Web Design colocam a maioria das páginas entre 0,2 g e 1 g de CO2. Multiplique pelo tráfego e deixa de ser abstrato: uma página vista um milhão de vezes por mês a 0,8 g são cerca de 800 kg de CO2 mensais — para uma única página.

Porque é que o peso da página e o JavaScript são as principais alavancas

O modelo mental mais limpo: as emissões escalam com os bytes transferidos e o trabalho feito no dispositivo. Isso aponta diretamente para dois culpados.

O peso da página é o total de quilobytes que uma página descarrega — HTML, CSS, JavaScript, imagens, tipos de letra, scripts de terceiros. A página web mediana já vai bem acima de 2 MB. A maior parte disso são imagens e JavaScript. Cada quilobyte que não envia é energia que não gasta em toda a cadeia.

O JavaScript é singularmente caro porque custa duas vezes. Primeiro a transferência, depois — ao contrário de uma imagem — o dispositivo tem de o interpretar, compilar e executar, muitas vezes a cada interação. Uma framework pesada de single-page-app pode significar enviar centenas de quilobytes de script para apresentar texto que HTML simples teria entregado por uma fração da energia. É por isto que "enviar menos JavaScript" é a decisão de sustentabilidade de maior alavancagem que a maioria das equipas pode tomar — e acontece ser também a decisão de desempenho de maior alavancagem.

A versão curta

• Carbono por visualização ≈ energia do servidor + transferência de rede + processamento no dispositivo.
• A maioria das páginas emite cerca de 0,2–1 g de CO2 por visualização.
• Peso da página e JavaScript são as alavancas dominantes e controláveis.
• Meça com a Website Carbon Calculator e um orçamento de bytes; reduza com menos JS, imagens eficientes, tipos de letra do sistema/subconjunto, cache forte na edge e alojamento eficiente.
• Rápido e verde são o mesmo problema de engenharia.

Como medir a pegada de carbono do seu site

Não pode reduzir o que não mede. Três ferramentas práticas, da rápida à rigorosa:

A Website Carbon Calculator (websitecarbon.com) dá uma estimativa rápida de gramas de CO2 por visualização com base no peso da página e numa suposição sobre a energia do seu alojamento. É indicativa, não de laboratório, mas é uma excelente primeira leitura e ótima para comparar antes/depois. A biblioteca associada co2.js da Green Web Foundation permite calcular as mesmas estimativas programaticamente contra números reais de transferência.

Os orçamentos de bytes são a disciplina que realmente muda resultados. Decida à partida quanto uma página pode pesar — digamos, 500 KB no total, com um teto rígido para JavaScript — e trate ultrapassá-lo como um defeito. Um orçamento transforma "devíamos ser mais leves" num número contra o qual uma build ou uma revisão pode falhar.

O Lighthouse (integrado no Chrome DevTools) não imprime gramas de CO2, mas mede aquilo que as causa: peso total em bytes, JavaScript e CSS não utilizados, imagens sobredimensionadas, recursos que bloqueiam a renderização e os Core Web Vitals que se correlacionam fortemente com uma página leve. Uma pontuação de desempenho na casa dos 90 e poucos no Lighthouse costuma significar uma página de baixo carbono por baixo.

Reduções práticas que mexem com o número

Nada disto é exótico. É engenharia disciplinada aplicada de forma consistente.

Enviar menos JavaScript

O maior ganho. Pergunte se a página precisa sequer de uma framework do lado do cliente. Um site institucional, um blog, um portefólio — são documentos, e documentos renderizam-se lindamente como HTML gerado no servidor com uma pitada de pequenos scripts dirigidos. Audite as tags de terceiros sem piedade; cada script de analítica, chat ou publicidade são bytes mais execução mais um custo de privacidade.

Renderizar no servidor

Gerar HTML no servidor e enviar marcação já pronta significa que o dispositivo desenha o conteúdo imediatamente, em vez de descarregar uma framework, arrancá-la, ir buscar dados e só depois renderizar. Menos trabalho no dispositivo, primeiro desenho mais rápido, menos carbono.

Usar imagens eficientes e bem dimensionadas

As imagens são normalmente a categoria individual mais pesada. Sirva formatos modernos — WebP ou AVIF — que são dramaticamente mais pequenos do que JPEG ou PNG com igual qualidade. Dimensione-as bem: nunca envie uma imagem de 3000px para um espaço de 600px. Use srcset responsivo para que os telemóveis recebam ficheiros à medida do telemóvel, e faça lazy-load de tudo abaixo da dobra.

Tipos de letra do sistema ou um subconjunto apertado

Um único peso de tipo de letra personalizado pode ter 50–150 KB, e uma família completa multiplica isso. As pilhas de tipos de letra nativos do sistema custam zero bytes e ficam nítidas. Se um tipo de letra de marca for inegociável, crie um subconjunto com os caracteres e pesos que realmente usa e sirva woff2 com font-display: swap.

Fazer cache forte na edge

Um pedido servido a partir de um nó de edge de um CDN perto do visitante percorre um caminho de rede mais curto e nunca acorda o seu servidor de origem. Cache agressiva de recursos estáticos e, quando possível, de páginas inteiras corta energia de servidor repetida e distância de transferência. Faça fingerprint dos recursos e guarde-os em cache praticamente para sempre.

Escolher alojamento verde ou eficiente

Alojamento alimentado por renováveis, ou simplesmente infraestrutura muito eficiente e bem utilizada, reduz a energia-por-byte na fonte. A Green Web Foundation mantém um diretório que pode consultar para verificar um alojamento. Sendo honestos, porém, um site leve e eficiente num alojamento médio costuma bater um site inchado num alojamento "verde" — os bytes contam mais do que o selo.

Como abordamos isto na Amplified Creations

O nosso estilo da casa é leve por omissão, e é uma postura deliberada e não uma frase de marketing. Os nossos sites correm em PHP 8.3 em alojamento partilhado da OVH atrás da Cloudflare, e são renderizados no servidor sem passo de build — não há framework do lado do cliente a enviar centenas de quilobytes para apresentar texto. O HTML chega pronto; o navegador desenha-o; acrescentamos pequenos scripts dirigidos apenas onde justificam o seu peso. O conteúdo vive no Cockpit CMS sobre SQLite, que é dos CMS com menos sobrecarga que há.

O dividendo de carbono cai por si dessa arquitetura. Como as páginas são sobretudo HTML e CSS, com imagens servidas em formatos modernos e cache forte na edge da Cloudflare, as nossas páginas de journal típicas ficam na casa das baixas centenas de quilobytes e pontuam Lighthouse ~95+ em desempenho. A nossa analítica é sem cookies e centrada na privacidade, o que significa que não carregamos o aglomerado de scripts de rastreio de terceiros que silenciosamente inflam o peso e as emissões da maioria dos sites — menos scripts, menos transferência de dados, menos trabalho no dispositivo e uma postura de privacidade mais amigável, tudo da mesma decisão. Não reivindicamos um valor preciso em gramas para cada cliente, porque uma medição honesta depende de dados reais de tráfego e de energia de alojamento que não vamos inventar — mas as alavancas estão puxadas na direção certa por construção.

A sustentabilidade também aparece ao nível do produto para os nossos clientes. A Delicious Diamonds, a marca de joalharia de luxo para quem construímos, mantém um compromisso climático de 1% — uma fatia da receita dedicada a trabalho climático — pelo que a responsabilidade ambiental está integrada no negócio, e não pendurada como um banner. Um site leve e rápido é a expressão digital desse mesmo valor: respeito pela largura de banda, pela bateria e pela atenção do cliente.

Perguntas frequentes

Quanto CO2 produz uma única página web?

A maioria das páginas emite cerca de 0,2 a 1 grama de CO2 por visualização, dependendo muito do peso da página e do alojamento. Uma página leve, renderizada no servidor, fica perto do fundo desse intervalo; uma app pesada de JavaScript carregada de scripts de terceiros fica bastante acima. Multiplique pelo seu tráfego mensal para ver o total real.

Qual é a forma mais eficaz de reduzir a pegada de carbono de um site?

Enviar menos JavaScript e menos bytes no total. O JavaScript custa duas vezes — transferência mais execução no dispositivo — por isso cortá-lo reduz emissões em toda a cadeia, tornando o site também mais rápido. A renderização no servidor e imagens eficientes e bem dimensionadas vêm logo a seguir.

Web design sustentável significa um site com pior aspeto?

Não. Um site de baixo carbono é simplesmente um site bem feito: rápido, leve e acessível. Imagens eficientes, tipos de letra inteligentes e renderização no servidor melhoram a experiência em vez de a degradar. O design visual não fica condicionado; o que muda é a disciplina por detrás de como é entregue.

Como meço a pegada de carbono do meu site?

Comece pela Website Carbon Calculator para uma estimativa rápida de gramas por visualização, depois use o Lighthouse no Chrome DevTools para encontrar o peso em bytes, o JavaScript não utilizado e as imagens sobredimensionadas que a causam. Defina um orçamento de bytes por página e trate ultrapassá-lo como um defeito.

O alojamento verde importa mais do que o peso da página?

O peso da página costuma importar mais. Alojamento alimentado por renováveis baixa a energia por byte, o que ajuda, mas um site inchado em alojamento verde pode ainda assim emitir mais do que um site leve em alojamento médio. Reduza primeiro os bytes, depois escolha alojamento eficiente ou renovável — somam-se.