W kodzie naszej odznaki pokazującej szacowany ślad węglowy strony znalazłem dwa błędy we wzorze SWDM v4. Częściowo się znosiły, dlatego testy sprawdzające jedynie kierunek zmian nie wychwyciły problemu. Rozbieżność wyszła na jaw dopiero przy porównaniu z biblioteką referencyjną.
Kalkulatory CO₂e podają szacunki oparte na modelach. Ich wyników nie należy traktować jak bezpośredniego pomiaru energii pobranej przez konkretny telefon, sieć i serwer. Omawiam założenia SWDM v4, różnice między pierwszą a kolejną wizytą oraz sposób porównywania wyników po zmianach na stronie.
Kalkulator śladu węglowego strony (SWDM v4)
Kalkulator śladu węglowego strony mnoży transfer w GB przez 0,300 kWh/GB i 494 g CO₂e/kWh, czyli dla 1 MB pierwszej wizyty daje około 0,15 g CO₂e (SWDM v4). Możesz dodać miesięczne odsłony, udział powrotów i zielony hosting. Obliczenie działa w twojej przeglądarce, a wpisane wartości nigdzie nie trafiają.
Kalkulator śladu węglowego strony (SWDM v4)
Szacunek = transfer w GB × 0,300 kWh/GB × 494 g CO₂e/kWh. Przykład: 1 MB transferu pierwszej wizyty to około 0,15 g CO₂e na modelowaną odsłonę, a przy 10 000 odsłon miesięcznie około 1,48 kg CO₂e. To szacunek modelowy, nie pomiar energii infrastruktury. Pełny skan transferu i zasobów wykonuje moduł Ekologia w CometWeb Insight.
Transfer odczytasz w DevTools, w karcie Network, gdzie wyłączasz cache, przeładowujesz stronę i bierzesz sumę „przesłano” (transferred), bo nieskompresowana wielkość plików z dysku zawyży wynik.
Testy kalkulatora sprawdzają sześć przypadków z pakietu badań do szóstego miejsca po przecinku, np. 0,148200 g CO₂e dla 1 MB, 0,296400 g dla 2 MB i 0,155399 g dla 1 MiB (1 048 576 bajtów). Drobiazg? MiB jest o prawie 5% większy względem MB, a GiB o ponad 7% względem GB, i właśnie tak wyglądały oba błędy odznaki:
Co obejmuje ślad węglowy strony internetowej
Ślad węglowy strony internetowej to szacunek emisji gazów cieplarnianych związanych z dostarczeniem i używaniem strony, w określonej granicy i okresie. Krótką definicję znajdziesz w haśle ślad węglowy strony internetowej.
Szacunek obejmuje prąd całego łańcucha dostarczenia, od serwera po urządzenie odwiedzającego, oraz przypisaną część produkcji sprzętu. CO₂e to ekwiwalent dwutlenku węgla, czyli gazy cieplarniane we wspólnej jednostce. Wynik na odsłonę to intensywność, a ślad miesięczny wymaga jeszcze danych o ruchu. Projekt SCI for Web wprost obejmuje też usługi zewnętrzne.
| Część usługi | Co się tam dzieje | Czego test transferu nie mierzy bezpośrednio |
|---|---|---|
| Hosting i backend | dostarczanie treści, serwer aplikacji, baza danych, storage, przetwarzanie i generowanie odpowiedzi | energii konkretnego procesu, jego udziału w bezczynnej infrastrukturze (idle) oraz kosztu zaplecza użytego do obsługi tej wizyty |
| Sieć i CDN | sieć dostępowa, tranzyt, cache CDN i infrastruktura pośrednia | chwilowej mocy poszczególnych urządzeń sieciowych ani przyczynowej zmiany poboru energii po usunięciu 1 MB |
| Urządzenie użytkownika | pobieranie, dekodowanie, JavaScript, layout, rendering i ekran | rzeczywistego poboru energii konkretnego urządzenia i ekranu oraz pełnego czasu używania strony |
| Cykl życia sprzętu | produkcja, utrzymanie i wymiana urządzeń | pełnej inwentaryzacji materiałowej i przypisania konkretnego sprzętu do jednej wizyty |
Niski szacunek mówi tylko o emisji, a dostępność strony wymaga osobnych dowodów, podobnie jak woda i łańcuch dostaw sprzętu.
Kalkulator, standard i pomiar energii odpowiadają na różne pytania
Zacznij od transferu i profilu przeglądarki, bo to widać od razu, a model dołóż dopiero do porównań.
| Pytanie | Rozsądny punkt startu | Jak czytać wynik |
|---|---|---|
| Które strony lub zasoby są niepotrzebnie ciężkie? | inwentarz zasobów, transfer, liczba żądań, waterfall, profiler przeglądarki | obserwacje inżynierskie i sygnały do sprawdzenia |
| Jak porównać dostarczenie stron przy stałym modelu? | powtarzane scenariusze w SWDM v4 / CO2.js z zapisaną wersją i tymi samymi założeniami | modelowany szacunek CO₂e |
| Ile emisji przypada na wykonanie konkretnego zadania w aplikacji? | telemetria komponentów, dane o energii i podejście zgodne z SCI / SCI for Web | intensywność dla jawnej granicy i jednostki |
| Czy produkt stosuje praktyki zrównoważonego projektowania? | Web Sustainability Guidelines albo osobna checklista | pokrycie praktyk, nie gramy CO₂e |
| Jaki jest pełny wpływ cyklu życia? | LCA z odpowiednią inwentaryzacją i zasadami alokacji | badanie znacznie szersze niż skan URL-a |
Web Sustainability Guidelines (WSG, szkic noty grupy W3C, stan z września 2026) to lista praktyk projektowych, a emisje liczysz innymi narzędziami.
Jak działa SWDM v4
Sustainable Web Design Model v4 (SWDM v4) to otwarty model, który na podstawie transferu alokuje, czyli przypisuje stronie część energii i emisji trzech segmentów: centrum danych, sieci i urządzenia użytkownika. Każdy segment ma część operacyjną i wbudowaną (produkcja sprzętu), a CO2.js z Green Web Foundation to jedna z implementacji tego modelu.
| Segment | Operacyjnie, kWh/GB | Ekwiwalent dla emisji wbudowanych, kWh/GB | Razem dla 1 MB, g CO₂e |
|---|---|---|---|
| Centrum danych | 0,055 | 0,012 | 0,033098 |
| Sieć | 0,059 | 0,013 | 0,035568 |
| Urządzenie użytkownika | 0,080 | 0,081 | 0,079534 |
| Razem | 0,194 | 0,106 | 0,148200 |
Suma to 0,300 kWh-ekwiwalentu na 1 GB przy bazowym współczynniku 494 g CO₂e/kWh (metodologia SWDM v4). Część wbudowana to ekwiwalent energii przypisany przez model, bez pomiaru prądu strony, a liczba 494 to stała tej wersji modelu, a lokalny współczynnik dla części operacyjnej zmieni szacunek.
Przykład: 1 MB pierwszej wizyty
To czysta arytmetyka modelu dla 1 000 000 bajtów pierwszej wizyty, bez cache i korekty hostingu, bez pomiaru cometweb.io czy strony klienta.
1 000 000 B / 1 000 000 000 = 0,001 GB
0,001 GB ×
(0,055 + 0,059 + 0,080 + 0,012 + 0,013 + 0,081) kWh/GB
× 494 g CO₂e/kWh
= 0,1482 g CO₂e
W nagłówku albo leadzie napisz około 0,15 g CO₂e na modelowaną pierwszą odsłonę, bo sześć miejsc po przecinku służy tylko do odtworzenia obliczenia.
Wzór i ograniczenia są w notatkach obliczeniowych z odtwarzalnym skryptem, który liczy niezależnie od CO2.js.
SWDM v4 przypisuje emisje według transferu, a sieć zużywa prąd inaczej
SWDM v4 to szacunek atrybucyjny, czyli reguła podziału śladu większego systemu, a pobór energii sieci rośnie inaczej niż liczba megabajtów. Badanie Myttona i współautorów opisuje wysoki pobór bazowy urządzeń sieciowych i pokazuje, dlaczego proste kWh/GB źle oddaje przyczynową reakcję sieci na zmianę ruchu.
Green Web Foundation też opisuje transfer jako proxy z własnymi ograniczeniami, stąd dwa różne zdania:
- poprawne: „w modelu SWDM v4 zmniejszenie transferu z 2 MB do 1 MB obniża przypisany szacunek dla tych samych założeń o połowę”;
- zbyt mocne: „usunięcie 1 MB z tej strony powoduje dokładnie połowę mniejszy fizyczny pobór energii sieci”.
Po ludzku model mówi, ile emisji przypisać stronie, a ile prądu zaoszczędzisz naprawdę, pokaże dopiero pomiar w konkretnym systemie.
Dlaczego dwa kalkulatory śladu węglowego pokazują różne CO₂e
Wiele kalkulatorów stosuje podobne wzory, ale różni się założeniami. Przy porównywaniu sprawdź wersję modelu, sposób mierzenia transferu, cache, zasoby zewnętrzne, moment zakończenia testu, intensywność emisji energii, reguły hostingu i zakres obejmujący jeden URL lub całe zadanie. CO2.js v0.18.0 z lutego 2026 zmieniło domyślny model na SWDM v4 (przewodnik po wydaniu). Sama aktualizacja biblioteki potrafi więc przesunąć serię danych, dlatego zapisuj wersję modelu i surowy transfer, starych wyników nie nadpisuj, a do porównania przelicz oba okresy wspólną wersją jako rekalkulację.
Powtórzone skany pokażą zmienność transferu, ale trafności współczynnika nie sprawdzą, bo wszystkie go dzielą, i dlatego przeszły testy odznaki. Niepewne założenia badaj scenariuszami, bo przedział ufności wymaga obronionego modelu prawdopodobieństwa. Wyników różnych modeli, np. EcoIndex i SWDM, nie uśredniaj.
Cache: pierwsza wizyta i powrót to dwa scenariusze
W CO2.js ustawiasz udział powrotów i dataReloadRatio, czyli część danych pobieraną ponownie. W tym przykładzie powrót pobiera 20% danych względem pierwszej wizyty.
50% pierwszych wizyt
50% powrotów
powrót pobiera 20% danych pierwszej wizyty
mnożnik = 0,5 + 0,5 × 0,2 = 0,6
0,1482 × 0,6 = 0,08892 g CO₂e / modelowaną średnią wizytę
20% pobierane ponownie i 20% w cache to odwrotne założenia, co opisuje sama implementacja SWDM v4 w CO2.js. Przy 20% pobieranych ponownie w cache zostaje 80% danych względem pierwszej wizyty.
Albo zmierz zimną i ciepłą wizytę osobno i zważ je ruchem, albo weź bajty pierwszej wizyty i jawny model cache. Nie rób obu, bo podwójna „oszczędność cache” zaniży wynik, a strona z cache dalej renderuje i wykonuje kod.
Jak zbierać transfer
Zapisz metodę, bo Resource Timing, log przeglądarki i logi serwera widzą różny ruch. Według Resource Timing i MDN o 0 :
PerformanceResourceTiming.transferSizewynosi0, gdy zasób przyszedł z lokalnego cache;- zasoby cross-origin bez nagłówka
Timing-Allow-Originukrywają część danych; - redirect, service worker i cache CDN przesuwają granicę badania.
Brak danych to brak danych, a zero trzeba udowodnić. Sumę z niepełnej listy zasobów oznacz jako częściową.
W SWDM v4 zielony hosting obniża tylko operacyjną część centrum danych
Flaga greenHostingFactor zmienia w SWDM v4 operacyjną część centrum danych, a sieć, urządzenie i emisje wbudowane zostają w wyniku.
Dla pierwszej wizyty korekta zmienia wynik o około 18,3% wobec tego samego scenariusza bez korekty, czyli w tym modelu niecałą piątą, daleko od zera. To cecha wzoru i tych współczynników, nie zmierzony efekt zmiany dostawcy. W konkretnym środowisku wynik zależy od dokumentacji dostawcy oraz zakresu przyjętego do obliczenia.
Weryfikacja Green Web Foundation to rozliczenie energii dostawcy na podstawie jego dowodów, a pomiar przy konkretnym żądaniu wymaga innego narzędzia. Status obejmuje twój serwer, a zewnętrzne wideo, fonty czy API zostają poza nim.
Od 1 października 2026 Green Web Foundation nie przyjmuje offsetów jako podstawy weryfikacji. Status nadany wcześniej mógł na nich stać, więc przed publicznym twierdzeniem sprawdź okres dowodów dostawcy.
Ślad węglowy całej witryny: zważ grupy stron ruchem
Strona główna bywa lekka, a wyszukiwarka, checkout czy panel robią dużo więcej pracy. Pogrupuj trasy według zachowania, każdą grupę zmierz tym samym scenariuszem i zważ wyniki ruchem z tego samego okresu.
Szacowany wynik okresu = suma(liczba aktywności_i × CO₂e_na_aktywność_i)
Średnia ważona =
szacowany wynik okresu / liczba aktywności objętych zakresem
Nie mieszaj mianowników, bo odsłona to inna jednostka niż sesja czy zakup, a boty i zadania w tle oddziel od wizyt ludzi. Raport SCI for Web Assembly przypisuje granicę do zaobserwowanej aktywności, więc model ludzkiej odsłony przy każdym żądaniu serwera zawyży wynik.
Intensywność może spaść, a suma wzrosnąć
W zestawieniu są te same współczynniki i hipotetyczna zmiana z 2 MB do 1 MB na pierwszą wizytę.
Intensywność spadła o 50% względem okresu „przed”, a modelowana suma wzrosła o 25%, choć obliczenie nie wie, skąd wzrost ruchu. Raport „g CO₂e na odsłonę spadło o połowę” pokazuje więc tylko połowę obrazu, dlatego raportuj oba wyniki, czyli intensywność na jednostkę i sumę dla udokumentowanego wolumenu.
Co optymalizować, żeby zmniejszyć ślad węglowy strony
Najpierw wybierz zmianę, której efekt da się ponownie zmierzyć. Żadne z wymienionych działań nie daje uniwersalnego procentu redukcji emisji.
- Usuń niepotrzebny transfer, czyli wytnij za duże obrazy, nieużywane fonty, filmy startujące same i skrypty bez właściciela. Obraz, który prawdopodobnie będzie LCP, ładuj jednak od razu, bo według web.dev późno załadowany potrzebny obraz psuje doświadczenie, a jego transfer i tak zostaje.
- Nie psuj fontów, więc po subsettingu sprawdź pokrycie znaków, jak radzi web.dev. Szczegóły opisałem w porównaniu WOFF2 i TTF.
- Mierz pracę przeglądarki obok megabajtów, bo 100 kB obrazu i 100 kB JavaScriptu, który przez minuty odpytuje serwer, to różne obciążenia. Sprawdź długie zadania i polling, także na starszym urządzeniu.
- Sprawdzaj cache w działaniu, patrząc na rzeczywiste HIT/MISS i transfer na powrocie. Speculative loading licz osobno, bo według MDN nietrafiona predykcja zwiększa łączną pracę i transfer.
- Zajrzyj do backendu i third-party, bo model bajtów nie zobaczy drogiego zapytania do bazy, nieograniczonych retry ani wywołania AI z małą odpowiedzią. Licz zasoby na ukończone zadanie, z nieudanymi próbami.
- Oceń hosting na dowodach. Wskaźnik PUE opisuje narzut obiektu względem sprzętu IT. Stosuj go tylko wtedy, gdy energia wejściowa go nie zawiera, bo inaczej policzysz go dwa razy (specyfikacja SCI).
Napisy, teksty alternatywne i zabezpieczenia zostają, bo WSG łączy zrównoważenie z dostępnością i bezpieczeństwem. Próg wagi strony to twoja reguła produktowa, bo żaden standard zrównoważenia nie podaje uniwersalnego progu.
Ślad węglowy aplikacji webowej liczysz na zadanie (SCI)
Checkout albo wygenerowany raport angażuje przeglądarkę, kilka API i bazy danych. Tu lepiej pasuje obliczenie komponentowe według Software Carbon Intensity (SCI), standardu powiązanego z normą ISO/IEC 21031:2024 (SCI). SCI for Web w połowie września 2026 miał status Draft.
Intensywność węglowa = (suma emisji operacyjnych komponentów
+ przypisane emisje wbudowane) / udane zadania
Emisje operacyjne komponentu = energia × odpowiednia intensywność węglowa
Pełnego szacunku SWDM nie dodawaj do zmierzonego backendu bez sprawdzenia nakładania, bo model strony już przypisuje część centrum danych. Wynik praktyk trzymaj osobno od węgla, a pokrycie i niepewność podawaj obok, bo jedna sklejona „liczba zrównoważenia” prowadzi prosto do greenwashingu.
Jak raportować ślad węglowy strony bez greenwashingu
Przy każdym publicznym wyniku zapisz tyle, żeby ktoś inny mógł odtworzyć szacunek:
| Pole | Co zapisać |
|---|---|
| Zakres i jednostka | testowane URL-e albo zadanie, objęte komponenty i g CO₂e na zadeklarowaną jednostkę |
| Scenariusz | urządzenie i przeglądarka, zgody, interakcje, okno obserwacji i stan cache |
| Dowody | zmierzone dane o zasobach, komponenty modelowane, deklaracje dostawców i brakujące pokrycie |
| Obliczenie | model, wersje narzędzia i współczynników, założenia o energii i hostingu |
| Porównanie | baseline, równoważna jakość zadania, zmienność powtórzeń i ewentualne przeliczenie |
| Odpowiedzialność | data, właściciel, ograniczenia i warunek przeglądu twierdzenia |
Zdania, które wynik kalkulatora uzasadnia:
- „SWDM v4 szacuje 0,15 g CO₂e dla pierwszej odsłony przy 1 MB transferu i zapisanych założeniach.”
- „Transfer pierwszej wizyty spadł z 2,0 do 1,2 MB. Przy tej samej konfiguracji modelu szacunek SWDM spadł proporcjonalnie.”
- „Wynik obejmuje centrum danych, sieć i urządzenie zgodnie z granicą modelu. Nie jest bezpośrednim pomiarem poboru energii infrastruktury.”
- „Status hostingu sprawdzono w Green Web Foundation dnia X; zakres zewnętrznych dostawców nie został objęty tą weryfikacją.”
Obronione zdanie dla przykładu z 2 MB i 1 MB:
Przy opisanych założeniach SWDM v4 zmniejszenie transferu testowanej pierwszej wizyty z 2 MB do 1 MB obniża modelowany szacunek z 0,2964 do 0,1482 g CO₂e na odsłonę. To ilustracyjne obliczenie, bez zmierzonej oszczędności energii i bez pełnego śladu cyklu życia witryny.
Zdania, na które wynik kalkulatora jest za słaby:
- „strona emituje dokładnie 0,1482 g CO₂e”;
- „usunęliśmy 1 MB, więc sieć zużywa teraz o połowę mniej energii”;
- „green hosting oznacza zero emisji”;
- „strona jest neutralna klimatycznie”;
- „wynik A oznacza zgodność ze standardem W3C”;
- „oszczędność odpowiada dokładnie X lotom albo Y drzewom” bez własnej, jawnej metody tych ekwiwalentów.
Przy skali A+–F zapisz, czyja to skala i jakie ma progi. Digital Carbon Ratings SWDM/CO2.js mają własne progi, a narzędzie może mieć osobną skalę prezentacji.
Jak zrobić retest śladu węglowego po optymalizacji
Przed wdrożeniem zapisz punkt odniesienia. Uwzględnij zadanie, urządzenie i przeglądarkę, stan zgód, pierwszą wizytę lub powrót, surowy transfer i liczbę żądań. Dołącz wersję SWDM/CO2.js, reguły korekty hostingu, datę, wynik modelu i ograniczenia zakresu. Po wdrożeniu powtórz ten sam scenariusz i najpierw porównaj transfer, wykonanie JavaScriptu oraz powodzenie zadania, dopiero potem CO₂e tą samą metodą. Pomogą arkusz pomiaru i karta porównania przed/po.
Gdzie pomaga moduł Ekologia w CometWeb Insight
Przy wielu podstronach moduł Ekologia w CometWeb Insight liczy estymację modelową SWDM v4 z jawnymi założeniami, przy każdym znalezisku pokazuje zasób i jego wpływ na szacowane CO₂e, sprawdza hosting w Green Web Foundation i porównuje ponowny skan w tym samym scenariuszu. Litery A+–F to nasza skala prezentacji, a emisję liczy SWDM v4.
Wynik publicznie pokażesz otwartoźródłową odznaką CometWeb Carbon Badge, która powinna komunikować metodę i datę, choć certyfikatem ESG nie jest. To w niej siedziały dwa błędy z początku tekstu, a dziś jej testy sprawdzają wartość bezwzględną, bo 1 GB to 148,2 g CO₂e, czyli 0,1482 g na MB.
Strona może pobierać mniej danych i wykonywać droższy JavaScript, więc wynik ekologiczny zestaw z pomiarem wydajności strony. Jeśli chcesz sprawdzić wagę i szacowane CO₂e wielu podstron naraz, załóż konto w Insight i uruchom pierwszy audyt.
Trzy wnioski
- Liczba jest łatwa, bo to transfer w GB razy 0,300 kWh/GB razy 494 g CO₂e/kWh, a kalkulator zrobi to za ciebie.
- Trudne jest to, co wokół liczby, bo dwa wyniki porównasz tylko przy tej samej granicy, tym samym scenariuszu i tej samej wersji modelu.
- Wpływ na węgiel opisuj tak daleko, jak sięgają dowody. Mniejszy transfer zmierzysz w DevTools, a oszczędność prądu tylko pomiarem konkretnego systemu.
A jeśli piszesz własny kalkulator, przypnij go do liczb referencyjnych. Mój przez chwilę mylił się w dwie strony naraz.
Najczęstsze pytania
Czy można dokładnie zmierzyć ślad węglowy strony?
Ślad węglowy całej strony można oszacować modelem z zasadami alokacji, a zmierzyć da się tylko wybrane elementy, np. transfer, czas wykonania albo energię konkretnego urządzenia w kontrolowanym eksperymencie. Powtarzalny wynik kalkulatora potwierdza arytmetykę, a trafność samego modelu fizycznego trzeba oceniać osobno.
Jaki ślad węglowy strony jest dobry?
Jednej liczby, która czyni każdą stronę dobrą, nie ma. Porównuj równoważne zadania przy tym samym modelu, warunkach pomiaru i granicy. Próg ratingu należy do opublikowanej skali, która go definiuje. To nie fizyczny limit ani dowód ogólnej zrównoważoności. Ustal budżety zasobów dla konkretnych tras i ujawnij, czemu służą.
Czy szybsza strona zawsze zużywa mniej energii?
Nie zawsze. Szybkość z mniejszej pracy, np. z cache, zwykle zmniejsza zużycie zasobów. Szybkość z równoległego przetwarzania albo speculative loading zwiększa łączną pracę. Sprawdzaj całe zadanie i łączne zasoby, a wynik szybkości traktuj jako sygnał.
Czy tryb ciemny zmniejsza ślad węglowy strony?
Tryb ciemny to pytanie o konkretne urządzenie i ekran. Uniwersalnej korekty śladu strony z tego tytułu nie ma. Zanim przypiszesz mu oszczędność energii, przetestuj rzeczywisty sprzęt i warunki oglądania. Zmiana motywu przy tych samych danych wejściowych nie uzasadnia niższego szacunku opartego na transferze.
Czy wynik kalkulatora jest audytem ESG albo CSRD?
Nie. Wynik kalkulatora to techniczny szacunek w określonej granicy i metodzie. Może dostarczyć dane pomocnicze do szerszej analizy, ale inwentaryzację organizacji, zasady raportowania i niezależną weryfikację wymaganą w konkretnym procesie trzeba zrobić osobno.
Źródła
Przykłady i proces opierają się na materiałach CometWeb Web Sustainability v15 (5 września 2026, specyfikacja metody bez walidacji produkcyjnej) i źródłach poniżej.
- Sustainable Web Design: Estimating Digital Emissions. SWDM v4, segmenty, współczynniki i założenia o cache.
- CO2.js v0.18.0: wydanie. Zmiana domyślnego modelu na SWDM v4, luty 2026.
- CO2.js: implementacja SWDM v4. Cache, hosting i segmenty; identyfikator sprawdzonego blobu jest w notatkach obliczeniowych.
- Mytton, Lundén, Malmodin: Network energy use not directly proportional to data volume. Journal of Industrial Ecology, 2024; relacja ruch–energia w sieciach.
- Green Software Foundation: SCI. Software Carbon Intensity i ISO/IEC 21031:2024.
- Green Software Foundation: SCI for Web. Projekt w statusie Draft; granica webowa i relacja do SCI.
- Green Software Foundation: specyfikacja SCI. Jednostka funkcjonalna, emisje operacyjne i wbudowane, porównanie z baseline i wyłączenia.
- W3C: Web Sustainability Guidelines. Group Note Draft; stan z września 2026.
- W3C: Resource Timing. Semantyka danych timingowych, rozmiarów i ograniczeń dostępu.
- Green Web Foundation: evidence of green power. Dowody od dostawców i zakres weryfikacji hostingu.
- Green Web Foundation: offsets and verification. Zmiana kryteriów od 1 października 2026.
- Sustainable Web Design: Digital Carbon Ratings. Zewnętrzna skala A+–F oparta na SWDM v4.
Artykuł opisuje estymacje techniczne. To nie jest pomiar energii konkretnej infrastruktury, pełna ocena cyklu życia, audyt ESG ani deklaracja zgodności środowiskowej.