Your servers are not the problem: devices are 65–92% of digital's footprint

Sébastien — Thu, 17 Sep 2026 10:46:22 +0000

Most "green software" conversations I see start at the server. Pick a greener host, move to a cleaner region, trim your bundle, measure grams of CO₂ per page view. All of it is real work, and almost none of it is where the impact is.
The French environment agency (ADEME) and the telecoms regulator (Arcep) ran a joint study on the environmental footprint of digital technology in France. The headline number is uncomfortable if you're an engineer: user devices account for 65% to 92% of the total footprint, depending on which indicator you look at — and the bulk of that is manufacturing, not electricity.
Your servers are in the remainder.
What that actually implies
If devices dominate, and manufacturing dominates devices, then the single biggest environmental lever in a digital product is not efficiency. It's not pushing your users to replace their hardware.
A service that still runs acceptably on a six-year-old Android phone does more for its footprint than any hosting migration you will ever run. And that decision is almost never made by the infrastructure team. It's made in a refinement session, when someone says "we can drop support for that, nobody's on it anyway," and nobody asks how many people "nobody" is.
Here's the hierarchy I now use, most powerful first:

Rank	Lever	Who decides	Cost
1	Don't build the feature	Product	negative — you save
2	Don't exclude old devices	Product + Eng	low to medium
3	Cut media and data weight	Design + Eng	low
4	Simplify the flow (fewer screens, fewer requests)	Product + Design	low
5	Optimise architecture and hosting	Eng	medium to high
6	Offset	Nobody — this is not a lever	—

Rank 6 is not a joke. Offsetting doesn't reduce your service's footprint, it buys the reduction somewhere else. If it comes up as the answer in a steering committee, it's a reliable signal that ranks 1 to 5 were never worked.
And rank 1 is the whole thing in one line: the feature you don't ship is the only one whose impact is zero. No engineer can optimise a feature that shouldn't have existed.
Why the existing frameworks don't get used
France has a public, free, genuinely good reference framework for this: the RGESN (référentiel général de l'écoconception des services numériques), version 2, published 17 May 2024 by Arcep and Arcom together with ADEME. Seventy-eight criteria, each with a practice sheet, three priority levels. The W3C's Web Sustainability Guidelines cover similar ground for an English-speaking audience — that work now sits with the W3C Sustainable Web Interest Group, and the guidelines are developed in the open on GitHub.
Both are built for auditing. Neither is built for the thing that actually happens on a Tuesday afternoon, which is a product manager with fifteen minutes and a backlog, deciding whether a feature ships.
Seventy-eight criteria is not a decision tool. It's a conformance tool. Those are different objects, and conflating them is why most teams read the framework once and never open it again.
Eight questions instead of seventy-eight
So I compressed it into what a refinement session can absorb. Eight questions, roughly four minutes, asked before anything gets built. If the answer to the first one is weak, the other seven are moot.
What measured usage justifies this feature? Not expected usage — observed usage on something comparable. Failing that, what test will measure it before you generalise.
What are you removing in exchange? A team that has deleted nothing in six months isn't making trade-offs, it's accumulating.
Does this exclude any device currently in your user base? If yes: which one, how many users, and who owns that call by name.
How many network requests and kilobytes does this add to the main flow? An order of magnitude is enough. Having no answer at all is the real signal.
What new data does it collect, and how long is that data kept?
Does the degraded version stay usable without this feature? If not, you just created a hard dependency.
What triggers its removal? A usage threshold and a date. A feature with no kill criterion is permanent by default.
What's the likely rebound effect? A per-user gain multiplied by an increase in usage you caused can be a net loss.
Question 7 is the one that changes behaviour fastest, in my experience. Most backlogs have no deletion mechanism at all, so everything that ships stays forever, and the footprint only goes one way.
The traps, in order of how often I see them
Measuring what's easy instead of what matters. Hosting emissions are simple to obtain and small. Device impact is hard to obtain and is most of it. A sustainability page that talks only about hosting is a tell.
Confusing eco-design with offsetting. One reduces, the other purchases. Mixing them in the same communication invites a greenwashing critique that will be entirely fair.
Ignoring rebound. A lighter service that triggers three times the usage has increased its total footprint. Gains have to be reasoned in absolute terms, not per user.
Chasing the label before the practice. Publishing a sustainability declaration on top of an empty process is the most expensive reputational risk on this list.
If you want to run it
I built a free version of the eight questions as a single static page — no signup, no tracker, no network request after load, and it gives you a score out of 100 plus your two highest-priority levers: https://perennova-eco.github.io/en/
It's open and it costs nothing. The MIT-licensed source is on GitHub. There's no buy button on it: I do sell a longer kit built on the same method, but it exists in French only, and pointing English readers at a document they can't read would be a waste of their click.
Disclosure, since it matters here: I'm one person doing this in the open, and I use AI tooling to draft and translate. The numbers, the sources and the method are mine and are checkable — the ADEME-Arcep study and the RGESN are both public.
The question I'd actually like answered: for those of you who've tried to get this onto a roadmap — what got you a yes? In my experience the regulatory argument lands badly and the cost argument lands well, but I've only got my own sample. What worked in yours?

DEV Community: Sébastien

Your servers are not the problem: devices are 65–92% of digital's footprint