La huella de carbono de un sitio web: cuánto CO2 produce realmente cada visita
La huella de carbono de un sitio web proviene de mover y procesar bytes — energía del servidor, transferencia de red y el dispositivo del visitante. El peso de la página y el JavaScript son las palancas principales. Así se mide y se entrega más ligero.
La huella de carbono de un sitio web es el gas de efecto invernadero emitido para entregar y mostrar sus páginas — la energía consumida por los centros de datos, la red que transporta los bytes y el propio dispositivo del visitante. Una visita típica se sitúa en algún punto entre 0,2 y 1,0 gramos de CO2, y la mayor palanca que controlas es el peso de la página: menos bytes, sobre todo menos JavaScript, significan menos energía en cada salto. El diseño web sostenible es, en su mayoría, ingeniería de rendimiento con conciencia.
Construimos sitios web para vivir en Amplified Creations, y hemos comprobado que las mismas decisiones que hacen rápido un sitio también lo hacen más ligero para el planeta. Este artículo explica de dónde proceden realmente las emisiones, cómo medir tu huella de forma honesta y las reducciones concretas que mueven la cifra.
¿Qué es la huella de carbono de un sitio web?
Cuando alguien pregunta "cuánto CO2 produce un sitio web", en realidad pregunta por tres costes de energía apilados por visita:
- Energía del servidor — el centro de datos que ejecuta tu aplicación, consulta tu base de datos y genera la respuesta. Se amortiza entre todos los visitantes, pero el trabajo pesado en el servidor (consultas sin caché, frameworks recargados) se acumula.
- Energía de red / transferencia de datos — cada byte viaja por routers, switches, cables submarinos y antenas. Es aproximadamente proporcional a los kilobytes que envías. Es la parte más directamente bajo el control de quien programa.
- Energía del dispositivo — el móvil o portátil del visitante gasta CPU y batería descomprimiendo imágenes, interpretando y ejecutando JavaScript y pintando la página. Un paquete de 2 MB de JavaScript no solo cuesta transferencia; obliga a un móvil Android de gama media a trabajar mucho, repetidamente.
La estimación citada con frecuencia es que internet es responsable de aproximadamente el 2–4% de las emisiones globales de carbono, en el mismo orden de magnitud que la aviación. Por visita, modelos como el Sustainable Web Design sitúan la mayoría de las páginas entre 0,2 g y 1 g de CO2. Multiplica por el tráfico y deja de ser abstracto: una página vista un millón de veces al mes a 0,8 g son unos 800 kg de CO2 mensuales — para una sola página.
Por qué el peso de la página y el JavaScript son las palancas principales
El modelo mental más limpio: las emisiones escalan con los bytes transferidos y el trabajo hecho en el dispositivo. Eso apunta directamente a dos culpables.
El peso de la página es el total de kilobytes que descarga una página — HTML, CSS, JavaScript, imágenes, tipografías, scripts de terceros. La página web mediana ya supera con holgura los 2 MB. La mayor parte son imágenes y JavaScript. Cada kilobyte que no envías es energía que no gastas en toda la cadena.
El JavaScript es singularmente caro porque cuesta dos veces. Primero la transferencia, luego — a diferencia de una imagen — el dispositivo debe interpretarlo, compilarlo y ejecutarlo, a menudo en cada interacción. Un framework pesado de single-page-app puede significar enviar cientos de kilobytes de script para mostrar texto que el HTML plano habría entregado por una fracción de la energía. Por eso "enviar menos JavaScript" es la decisión de sostenibilidad de mayor palanca que la mayoría de los equipos puede tomar — y resulta ser también la decisión de rendimiento de mayor palanca.
La versión corta
- Carbono por visita ≈ energía del servidor + transferencia de red + procesamiento en el dispositivo.
- La mayoría de las páginas emite alrededor de 0,2–1 g de CO2 por visita.
- Peso de la página y JavaScript son las palancas dominantes y controlables.
- Mide con la Website Carbon Calculator y un presupuesto de bytes; reduce con menos JS, imágenes eficientes, tipografías del sistema/subconjunto, caché fuerte en el edge y alojamiento eficiente.
- Rápido y verde son el mismo problema de ingeniería.
Cómo medir la huella de carbono de tu sitio web
No puedes reducir lo que no mides. Tres herramientas prácticas, de la rápida a la rigurosa:
La Website Carbon Calculator (websitecarbon.com) da una estimación rápida de gramos de CO2 por visita basada en el peso de la página y una suposición sobre la energía de tu alojamiento. Es orientativa, no de laboratorio, pero es una excelente primera lectura y muy útil para comparar antes/después. La biblioteca asociada co2.js de The Green Web Foundation permite calcular las mismas estimaciones de forma programática contra cifras reales de transferencia.
Los presupuestos de bytes son la disciplina que de verdad cambia los resultados. Decide de antemano cuánto puede pesar una página — digamos, 500 KB en total, con un tope rígido para JavaScript — y trata superarlo como un defecto. Un presupuesto convierte "deberíamos ser más ligeros" en una cifra contra la que una build o una revisión puede fallar.
Lighthouse (integrado en Chrome DevTools) no imprime gramos de CO2, pero mide lo que los causa: peso total en bytes, JavaScript y CSS sin usar, imágenes sobredimensionadas, recursos que bloquean el renderizado y los Core Web Vitals que se correlacionan estrechamente con una página ligera. Una puntuación de rendimiento en los 90 y pico en Lighthouse suele significar una página de bajo carbono por debajo.
Reducciones prácticas que mueven la cifra
Nada de esto es exótico. Es ingeniería disciplinada aplicada de forma consistente.
Enviar menos JavaScript
La mayor victoria. Pregúntate si la página necesita siquiera un framework del lado del cliente. Un sitio corporativo, un blog, un portafolio — son documentos, y los documentos se renderizan estupendamente como HTML generado en el servidor con una pizca de pequeños scripts dirigidos. Audita las etiquetas de terceros sin piedad; cada script de analítica, chat o publicidad son bytes más ejecución más un coste de privacidad.
Renderizar en el servidor
Generar HTML en el servidor y enviar marcado ya terminado significa que el dispositivo pinta el contenido de inmediato, en lugar de descargar un framework, arrancarlo, traer datos y solo después renderizar. Menos trabajo en el dispositivo, primer pintado más rápido, menos carbono.
Usar imágenes eficientes y bien dimensionadas
Las imágenes suelen ser la categoría individual más pesada. Sirve formatos modernos — WebP o AVIF — que son drásticamente más pequeños que JPEG o PNG a igual calidad. Dimensiónalas bien: nunca envíes una imagen de 3000px a un hueco de 600px. Usa srcset responsivo para que los móviles reciban archivos a su medida, y aplica lazy-load a todo lo que esté por debajo del pliegue.
Tipografías del sistema o un subconjunto ajustado
Un único peso de tipografía personalizada puede ocupar 50–150 KB, y una familia completa lo multiplica. Las pilas de tipografías nativas del sistema cuestan cero bytes y se ven nítidas. Si una tipografía de marca es innegociable, crea un subconjunto con los caracteres y pesos que realmente usas y sirve woff2 con font-display: swap.
Cachear fuerte en el edge
Una petición servida desde un nodo de edge de un CDN cercano al visitante recorre un camino de red más corto y nunca despierta tu servidor de origen. La caché agresiva de recursos estáticos y, cuando es posible, de páginas enteras recorta energía de servidor repetida y distancia de transferencia. Aplica fingerprint a los recursos y cachéalos prácticamente para siempre.
Elegir alojamiento verde o eficiente
El alojamiento alimentado por renovables, o simplemente una infraestructura muy eficiente y bien aprovechada, reduce la energía por byte en el origen. The Green Web Foundation mantiene un directorio que puedes consultar para verificar un alojamiento. Siendo honestos, sin embargo, un sitio ligero y eficiente en un alojamiento medio suele ganar a un sitio recargado en alojamiento "verde" — los bytes pesan más que el sello.
Cómo abordamos esto en Amplified Creations
Nuestro estilo de la casa es ligero por defecto, y es una postura deliberada, no una frase de marketing. Nuestros sitios funcionan con PHP 8.3 en alojamiento compartido de OVH detrás de Cloudflare, y se renderizan en el servidor sin paso de build — no hay framework del lado del cliente enviando cientos de kilobytes para mostrar texto. El HTML llega terminado; el navegador lo pinta; añadimos pequeños scripts dirigidos solo donde justifican su peso. El contenido vive en Cockpit CMS sobre SQLite, que es de los CMS con menos sobrecarga que existen.
El dividendo de carbono cae por sí solo de esa arquitectura. Como las páginas son sobre todo HTML y CSS, con imágenes servidas en formatos modernos y caché fuerte en el edge de Cloudflare, nuestras páginas de journal típicas quedan en los pocos cientos de kilobytes y puntúan Lighthouse ~95+ en rendimiento. Nuestra analítica es sin cookies y centrada en la privacidad, lo que significa que no cargamos el cúmulo de scripts de rastreo de terceros que silenciosamente inflan el peso y las emisiones de la mayoría de los sitios — menos scripts, menos transferencia de datos, menos trabajo en el dispositivo y una postura de privacidad más amable, todo de la misma decisión. No reivindicamos una cifra precisa en gramos para cada cliente, porque una medición honesta depende de datos reales de tráfico y de energía de alojamiento que no vamos a inventar — pero las palancas están accionadas en la dirección correcta por construcción.
La sostenibilidad también aparece a nivel de producto para nuestros clientes. Delicious Diamonds, la marca de joyería de lujo para la que construimos, mantiene un compromiso climático del 1% — una parte de los ingresos dedicada a trabajo climático — de modo que la responsabilidad ambiental está integrada en el negocio, y no colgada como un banner. Un sitio ligero y rápido es la expresión digital de ese mismo valor: respeto por el ancho de banda, la batería y la atención del cliente.
Preguntas frecuentes
¿Cuánto CO2 produce una sola página web?
La mayoría de las páginas emite alrededor de 0,2 a 1 gramo de CO2 por visita, dependiendo mucho del peso de la página y del alojamiento. Una página ligera, renderizada en el servidor, queda cerca del fondo de ese rango; una app pesada de JavaScript cargada de scripts de terceros queda bastante por encima. Multiplica por tu tráfico mensual para ver el total real.
¿Cuál es la forma más eficaz de reducir la huella de carbono de un sitio web?
Enviar menos JavaScript y menos bytes en total. El JavaScript cuesta dos veces — transferencia más ejecución en el dispositivo — así que recortarlo reduce emisiones en toda la cadena, además de hacer el sitio más rápido. El renderizado en el servidor y las imágenes eficientes y bien dimensionadas vienen justo detrás.
¿Diseño web sostenible significa un sitio de peor aspecto?
No. Un sitio de bajo carbono es simplemente un sitio bien hecho: rápido, ligero y accesible. Imágenes eficientes, tipografías inteligentes y renderizado en el servidor mejoran la experiencia en lugar de degradarla. El diseño visual no queda condicionado; lo que cambia es la disciplina detrás de cómo se entrega.
¿Cómo mido la huella de carbono de mi sitio web?
Empieza con la Website Carbon Calculator para una estimación rápida de gramos por visita, luego usa Lighthouse en Chrome DevTools para encontrar el peso en bytes, el JavaScript sin usar y las imágenes sobredimensionadas que la causan. Define un presupuesto de bytes por página y trata superarlo como un defecto.
¿Importa más el alojamiento verde que el peso de la página?
El peso de la página suele importar más. El alojamiento alimentado por renovables baja la energía por byte, lo que ayuda, pero un sitio recargado en alojamiento verde puede aun así emitir más que un sitio ligero en alojamiento medio. Reduce primero los bytes, luego elige alojamiento eficiente o renovable — se suman.