Medir la huella de carbono de una web // Módulo 02

Cierras el módulo con la pieza que convierte todo lo anterior en práctica: medir. Sin un número, «esta web es más ligera» es una opinión. Esta unidad presenta la métrica de referencia para el software, un modelo sencillo para estimar la huella de una web y las herramientas con las que puedes hacerlo tú mismo.

1 // La SCI: intensidad de carbono del software

La SCI (Software Carbon Intensity) es la especificación de la Green Software Foundation para medir la huella de un software. Desde 2024 es también una norma internacional, la ISO/IEC 21031. Su fórmula es:

SCI = ((E × I) + M) por REnergía por intensidad de la red, más la parte del carbono incorporado del hardware, todo ello dividido por la unidad funcional.

Símbolo	Qué es	Unidad habitual
E	Energía consumida por el software	kWh
I	Intensidad de carbono de la electricidad	g CO₂e/kWh
M	Carbono incorporado del hardware, en la parte que le corresponde al software	g CO₂e
R	Unidad funcional: aquello por lo que se divide	por usuario, por petición, por minuto…

Fíjate en dos decisiones de diseño de la especificación:

Es una tasa, no un total. Se expresa por unidad funcional. Así, una aplicación que gana usuarios no «empeora» por crecer, y una que los pierde no «mejora» por encogerse. Sólo baja si cada unidad de trabajo cuesta menos.
No admite compensaciones. Comprar créditos de carbono no reduce la SCI. La única forma de bajarla es actuar sobre E, I o M, es decir, sobre las tres palancas de la unidad anterior.

Una API corre en un servidor dedicado con un consumo medio de 100 W, en una red de 120 g CO₂e/kWh. Suponemos que fabricar el servidor emitió 1.200 kg CO₂e y que durará 4 años. Atiende 200.000 peticiones al día. Calculamos la SCI por petición en un día.

E: 100 W × 24 h = 2,4 kWh.
E × I: 2,4 × 120 = 288 g CO₂e.
M: 1.200.000 g repartidos en unos 1.460 días ≈ 822 g CO₂e al día.
SCI: (288 + 822) / 200.000 ≈ 0,0056 g CO₂e por petición, unos 5,6 mg.

Con una red limpia, el carbono incorporado pesa casi tres veces más que la electricidad. Esa API mejoraría más aprovechando mejor el servidor, atendiendo más peticiones con la misma máquina, que recortando unos vatios.

2 // Estimar desde los datos transferidos

Medir la energía real de una web es difícil: no tienes acceso a la red ni a los dispositivos de tus usuarios. Por eso, para webs, se usan modelos que estiman la huella a partir de algo fácil de medir: los datos transferidos.

El más extendido es el Sustainable Web Design Model (SWDM). En su versión 4, publicada en 2024, asigna a cada gigabyte transferido una energía de unos 0,3 kWh, repartida entre centros de datos, redes y dispositivos (operativa e incorporada), que es el reparto que viste en el diagrama de la primera unidad del módulo.

El camino de un cálculo por modelo: de lo que mides en el navegador a una estimación de CO₂e. Cada flecha introduce un supuesto, y por eso el resultado es un orden de magnitud.

Una página pesa 2 MB y recibe 30.000 visitas al mes. Usamos 0,3 kWh/GB y una intensidad media mundial de unos 490 g CO₂e/kWh, como hacen estos modelos por defecto.

Datos al mes: 2 MB × 30.000 = 60.000 MB = 60 GB.
Energía: 60 GB × 0,3 kWh/GB = 18 kWh.
Emisiones: 18 kWh × 490 g/kWh ≈ 8,8 kg CO₂e al mes, unos 0,29 g por visita.
Si la página baja a 1 MB: todo se reduce a la mitad, unos 4,4 kg al mes.

El modelo es lineal: cada megabyte que quitas se nota directamente en la estimación. Los modelos reales afinan el cálculo (por ejemplo, tienen en cuenta que quien repite visita ya tiene recursos en caché, o si el alojamiento usa energía renovable), pero la lógica es esta.

3 // Herramientas

Hay herramientas para cada capa. Todas son gratuitas o tienen versión abierta:

Dónde mides	Herramienta	Qué te da
Navegador	Pestaña Red de las DevTools	Bytes transferidos y número de peticiones, el dato de partida
Navegador	Lighthouse	Peso de la página, recursos sin usar, rendimiento; no calcula carbono
Web completa	Website Carbon Calculator	Estimación de CO₂e por visita con el modelo SWDM
Web completa	EcoIndex	Nota de la A a la G según peso, peticiones y tamaño del DOM
Tu código	CO2.js	Librería JavaScript de The Green Web Foundation que implementa el modelo en tus scripts o en tu CI
Alojamiento	Green Web Check	Si el proveedor de un dominio declara usar energía renovable
Servidor	Medidores de energía como Scaphandre o Kepler	Estimación del consumo por proceso o por contenedor
Nube	Paneles de huella de cada proveedor	Emisiones de tu cuenta, con su propia metodología

Todas estas herramientas trabajan con modelos y supuestos, y dos herramientas distintas pueden dar cifras muy diferentes para la misma web. No las uses para anunciar que tu web «emite X gramos» como si fuera un dato exacto. Úsalas para lo que hacen bien: comparar versiones de tu propia web con la misma herramienta y saber si un cambio mejora o empeora.

4 // Qué no mide un número

Una última advertencia. Los modelos basados en bytes miden bien una cosa, el peso, pero se les escapan otras:

El trabajo del procesador en el dispositivo: un script pequeño que ejecuta una animación sin fin pesa poco y consume mucho.
El trabajo del servidor: una consulta mal hecha no aumenta los bytes de la respuesta, pero sí la CPU.
La vida útil del hardware: una web que funciona en móviles antiguos no suma puntos en ningún calculador.
La utilidad: una web muy ligera que nadie necesita sigue siendo un gasto.

Por eso, en los módulos siguientes combinarás estas estimaciones con mediciones más concretas en cada capa: el backend, el frontend y la infraestructura.

Medir es el primer paso para mejorar, pero cada métrica ve sólo una parte. Usa la SCI para razonar sobre energía, red y hardware; usa los modelos por bytes para comparar versiones de una web; y no olvides lo que ninguna de las dos mide.

Autoevaluación

¿Por qué la SCI se expresa por unidad funcional (por usuario, por petición…) y no como un total?

Para que crecer no parezca empeorar ni encogerse parezca mejorar. Un total sube si la aplicación gana usuarios aunque sea más eficiente. Una tasa por unidad de trabajo sólo baja si cada petición o cada usuario cuesta menos carbono, que es justo lo que el equipo puede mejorar con su código.

¿Por qué la SCI no permite restar compensaciones de carbono?

Porque quiere medir la eficiencia real del software, no lo que se paga fuera de él. Comprar compensaciones no cambia cuánta energía ni cuánto hardware consume la aplicación. Si se pudieran restar, un software ineficiente podría presentar una puntuación excelente sin haber mejorado nada.

¿Por qué las herramientas de medición de webs dan estimaciones y no valores exactos, y para qué sirven entonces?

Porque calculan a partir de un modelo, no de una medición directa de toda la cadena. Parten de los bytes transferidos y de valores medios de consumo y de intensidad de la red. No sirven para dar una cifra absoluta fiable, pero sí para comparar dos versiones de la misma web y saber si un cambio mejora o empeora.