Sustainable Web Design v3 bills a phone's factory carbon as a fixed share of transferred bytes

The manufacturing term is expressed as a fixed proportion of transferred data, so halving a payload halves it alongside the datacentre, network and device-energy terms ^[2]. Nothing at the factory changed. Embodied carbon is spent once, then spread over however many years the handset stays in service, and what shortens that service life is the accumulated experience of a device that feels broken ^[3].

Put the model's own numbers on the well-built page. It comes in at roughly 0.014 g CO2e per visit, about 35 times below the HTTP Archive median ^[5]. The manufacturing line inside that figure is 0.0027 g, so cutting the page to 22 KB books a saving of about 0.0013 g per visit ^[1], with the phone's embodied carbon untouched.

The device-energy term has the same shape problem. The second 45 KB page scores identically while doing far more work on the handset. It blocks the main thread for over a second on first interaction, and its framework build target dropped Android WebView versions older than three years ^[6]. This page never goes quiet, so the CPU and the radio stay awake ^[10].

That makes the largest available front-end fixes invisible to the grade. The developer @giotramu measured a custom MultiSelect that mounted about 1,175 option components in one synchronous commit to display roughly six visible rows, at INP 1,256 ms under 4x CPU throttling in DevTools ^[7]. A hand-rolled virtual scroll hook of about 90 lines brought that to 13 mounted nodes and INP 96 ms ^[8]. That is roughly 90 times fewer nodes and 13 times lower INP ^[2], with the JS bundle barely moved and the carbon grade unchanged ^[8].

Before any of this is testable, someone has to write down the floor: a named phone, a named OS version, a named year, in the ticket template, not "we support modern browsers" ^[15]. Otherwise, the post's author wrote, "the answer is decided accidentally by whatever your build tool defaults to, which is a sustainability decision made by a config file" ^[12].

For the 1,256 ms figure to describe your users, they would need a comparable device class and a comparable option count on the page. The post is explicit that Lighthouse's 4x CPU slowdown approximates a mid-tier phone, not an old one, and it asks for the worst interaction to be run at 6x or 10x, or on a real five-year-old handset from a drawer ^[11]. Given the choice, I would spend the next hour on that test instead of shaving 5 KB off a bundle. The post presents INP, time to idle and background work as proxies for device service life. It does not report data linking any of them to replacement intervals ^[13].