We made a fairly bold claim about our Deny All Firewall WordPress plugin:
On a heavily scanned WordPress site blocking around 50,000–100,000 unwanted requests per day, we estimate that Deny All Firewall could avoid approximately 100 kg of CO2 emissions per year … roughly comparable to the direct emissions attributable to one passenger on a one-way flight from London to Ibiza.
That sentence quite reasonably raises two questions:
- How on earth can a firewall reduce carbon emissions?
- Did somebody decide on Ibiza first and then invent the mathematics afterwards?
The short answers are “by stopping the server doing pointless work” and “no”.
Here is the longer answer … with the maths.
The internet is remarkably noisy
A public website does not receive requests only from prospective customers, loyal readers and your mum checking whether you have fixed that typo.
It also receives a constant stream of requests from vulnerability scanners, password crackers, content scrapers and bots looking for files that should never be public in the first place.
They request old WordPress exploits, environment files, database backups, private keys and thousands of entirely imaginary pages.
A conventional WordPress installation may pass many of those requests into PHP. WordPress then loads its core, connects to the database, loads active plugins, asks the theme for help and eventually concludes that /please-let-there-be-a-forgotten-database-backup.sql does not exist.
Deny All Firewall does the opposite.
It generates Apache .htaccess rules describing what the website genuinely needs to make public. Requests outside those rules can then be rejected by the web server before WordPress, PHP and the database get involved at all.
The cheapest WordPress request is the one WordPress never has to process.
So what does a WordPress request actually cost?
There is no single answer.
A small cached website and a large WooCommerce installation with dozens of plugins obviously do not require the same amount of work. Hosting hardware, PHP versions, database performance and the source of the electricity all vary too.
Fortunately, we are not completely without measurements.
A 2026 university study, Energy Consumption of Web Servers: A Comparison Between Dynamic and Static Approaches, compared dynamic WordPress with cached and statically generated versions running on Apache.
At 16 requests per second, its dynamic WordPress installation used approximately 27 watts. The static and cached versions used less than one watt. The dynamic installation reached a maximum of around 20 requests per second, while the static version handled thousands.
Using the deliberately cautious figure of one watt for static serving gives us:
(27 watts − 1 watt) ÷ 16 requests per second
= 1.625 joules per requestThat gives us a useful measured baseline. It does not mean every WordPress request magically uses exactly 1.625 joules.
A real site with more plugins, more database queries or a particularly expensive 404 template can use considerably more.
Our firewall response is not literally the same thing as serving a static copy of a page, but it shares the important bit: Apache can refuse the request without starting WordPress.
Processing is only part of it
Without that early rejection, the server may also send a complete HTML response back to the bot.
The bot will not usually go on to download all the images, fonts and JavaScript, but transferring even the initial HTML still uses data-centre and network energy.
The Sustainable Web Design Model version 4 estimates operational energy intensity at:
- 0.055 kWh per GB for data centres;
- 0.059 kWh per GB for networks; and
- 0.080 kWh per GB for visitors’ devices.
We exclude the visitor-device figure because these requests generally come from automated systems, not somebody sitting at home admiring the website on a laptop.
The model uses a global grid intensity of 494 grams of CO2 equivalent per kWh. It is also the model used by the Green Web Foundation’s CO2.js.
Combining the data-centre and network figures gives:
(0.055 + 0.059) kWh per GB × 494 gCO2e per kWh
= approximately 56.3 gCO2e per GB transferredSo how many blocked requests make 100 kg?
One hundred kilograms per year works out at approximately 274 grams per day.
The result then depends on how much processing and data each early rejection avoids.
To avoid counting the same data-centre energy twice, the following calculation uses the Sustainable Web Design Model’s combined data-centre and network estimate rather than adding our separate CPU estimate on top:
| Smaller HTML response avoided by each early rejection | Approximate blocked requests needed per day |
|---|---|
| 20 KB | 243,000 |
| 50 KB | 97,000 |
| 100 KB | 49,000 |
For example, avoiding a 50 KB response saves approximately 0.0028 gCO2e under the model.
About 35.5 million such responses add up to 100 kgCO2e. That is approximately 97,000 requests per day, or a little over one request per second on average.
This calculation does not separately add the measured WordPress-versus-static CPU difference, so we are not double counting average data-centre energy.
On the other hand, a particularly expensive WordPress request may consume more processing energy than a transfer-based model can see.
One request per second sounds bonkers until you look at the access logs of a public website.
Automated traffic does not sleep, take weekends off or get bored after trying /.env for the four-hundredth time.
Sites under sustained scanning can comfortably exceed these numbers.
Quiet sites will not.
That is why our claim says a heavily scanned WordPress site blocking around 50,000–100,000 unwanted requests per day could avoid approximately 100 kg of CO2 emissions per year, rather than pretending every WordPress installation automatically does so.
If a site receives only 5,000 relevant unwanted requests per day, the saving under the same assumptions may be nearer 5–15 kg per year.
That is less dramatic, obviously, but it is still electricity being spent doing absolutely nothing useful.
What about caching and Cloudflare?
Caching can substantially reduce the cost of legitimate page views and some unwanted requests. A request answered entirely by a CDN may never reach the hosting server at all.
However, scanners often deliberately request unique addresses, strange query strings, login files and sensitive filenames.
Those requests are less likely to benefit from an ordinary page cache. They can also bypass a cache because the response is personalised, uncached or simply has never been requested before.
Deny All Firewall is therefore not a replacement for good caching or a service such as Cloudflare.
They solve overlapping but different problems.
The useful principle is simply to reject unwanted work at the earliest reliable opportunity.
And the flight to Ibiza?
London to Ibiza is approximately 1,400 kilometres.
Applying the UK Government’s international short-haul aviation factors puts the direct emissions attributable to one economy passenger in broadly the same neighbourhood as 100 kg for a one-way journey.
Flight comparisons get confusing very quickly because different calculators include different things.
Some mainly report the direct greenhouse-gas emissions from burning and supplying the fuel. Others add a radiative-forcing uplift to account for aviation’s additional effects at altitude, including things such as contrails.
Include that uplift and the estimated climate effect of the same one-way journey can exceed 200 kgCO2e.
The UK Government publishes its greenhouse-gas conversion factors and methodology, so at least we can be clear about which basis we are using.
For that reason, our comparison specifically says:
Roughly comparable to the direct emissions attributable to one passenger on a one-way flight from London to Ibiza.
It is there to illustrate the scale.
It is not an argument that blocking WordPress malware scans somehow earns anybody a guilt-free holiday in Ibiza.
So is 100 kg guaranteed?
No … and any honest estimate of digital emissions needs to say so.
The result varies with:
- the number and type of unwanted requests;
- whether those requests would reach WordPress without the firewall;
- the processing cost of the particular WordPress installation;
- the difference between the normal and blocked response sizes;
- caching and CDN behaviour;
- server and data-centre efficiency; and
- the carbon intensity of the electricity being used.
The Sustainable Web Design Model is itself an estimation model.
Data transfer is used as a practical proxy because measuring the complete physical impact of every individual request across hosting and network infrastructure is extraordinarily difficult.
So our 100 kg figure should be read as an order-of-magnitude estimate for a heavily scanned site, not as some kind of laboratory-certified saving that magically applies to every installation.
The more important point
Whether a particular website saves 10 kg, 100 kg or more, the engineering principle is the same:
Do not run an entire content-management system merely to discover that an obviously unwanted request should be refused.
Early rejection improves security, frees up server capacity and reduces unnecessary processing and data transfer.
The carbon saving is not some separate green feature bolted onto the plugin afterwards.
It is simply a consequence of making the server do less pointless work.
Security software occasionally gets to say “no” for the good of the planet.
Admittedly, it mostly just enjoys saying “no”.
References and further reading
- Energy Consumption of Web Servers: A Comparison Between Dynamic and Static Approaches
- Sustainable Web Design Model version 4: Estimating Digital Emissions
- Green Web Foundation: CO2.js models
- International Energy Agency: Data centres and data transmission networks
- UK Government greenhouse-gas reporting conversion factors
Leave a Reply