Can a WordPress Firewall Really help save the planet?

We made a fairly bold claim about our Deny All Firewall WordPress plugin:

On a WordPress site receiving substantial unwanted traffic, we estimate that Deny All Firewall could avoid around 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 invites two questions:

How can a firewall reduce carbon emissions?
Did somebody choose Ibiza first and invent the mathematics on the flight home?

The short answers are “by preventing unnecessary work” and “no”. Here is the longer, fully worked answer.

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 continuous stream of requests from vulnerability scanners, password crackers, content scrapers and bots looking for files that should never be public. 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 its 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 takes the opposite approach. It generates Apache .htaccess rules describing what the website genuinely needs to make public. Requests outside those rules can be rejected by the web server before WordPress, PHP and the database are involved.

The cheapest WordPress request is the one WordPress never has to process.

What does a dynamic WordPress request cost?

There is no universal answer. A small cached website and a large WooCommerce installation with dozens of plugins do not require the same work. Hosting hardware, PHP versions, database performance and electricity generation also differ.

Fortunately, we are not entirely 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 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 about 20 requests per second, while the static version handled thousands.

Using the deliberately cautious one-watt figure for static serving, the difference is:

(27 watts − 1 watt) ÷ 16 requests per second
= 1.625 joules per request

That is a useful measured baseline, not a promise that every WordPress request uses precisely 1.625 joules. A real site with more plugins, more database queries or an expensive not-found template can use considerably more.

Our firewall response is not literally a static copy of the requested page, but it shares the important characteristic: Apache can refuse the request without starting WordPress.

Processing is only part of the story

Without an early rejection, the server may also send a complete HTML response to the bot. The bot normally will not download the page’s 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 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 transferred

So how many blocked requests make 100kg?

One hundred kilograms per year is approximately 274 grams per day.

The result depends on how much processing and data each 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 amount to 100 kgCO2e: approximately 97,000 requests per day, or a little over one request per second on average.

This does not separately add the measured WordPress-versus-static CPU difference, so it avoids double counting average data-centre energy. Conversely, a particularly expensive WordPress request may consume more processing energy than a transfer-based model can see.

One request per second sounds extraordinary until you inspect the access logs of a public website. Automated traffic does not sleep, take weekends off or become bored after trying /.env for the four-hundredth time.

Sites under sustained scanning can exceed these numbers comfortably. Quiet sites will not. That is why our claim now says a WordPress site receiving substantial unwanted traffic could avoid around 100 kg, rather than claiming that 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, but still represents electricity 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, unusual 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 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 an economy passenger in broadly the same neighbourhood as 100 kg for a one-way journey.

Flight comparisons become confusing because different calculators include different things. Some report principally the direct greenhouse-gas emissions from burning and supplying fuel. Others include a radiative-forcing uplift to represent aviation’s additional effects at altitude, such as contrails. Including that uplift can push the estimated climate effect of the same one-way journey above 200 kgCO2e.

The UK Government publishes its greenhouse-gas conversion factors and methodology so that the chosen basis can be stated clearly.

For that reason, we describe our comparison specifically as:

Roughly comparable to the direct emissions attributable to one passenger on a one-way flight from London to Ibiza.

It is an illustration of scale, not an assertion that deleting WordPress malware scans earns anybody a guilt-free holiday.

Is 100kg 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 itself is an estimation model. Data transfer is used as a practical proxy because measuring the complete physical impact of every request across hosting and network infrastructure is extraordinarily difficult.

Our 100 kg figure should therefore be read as an order-of-magnitude estimate for a substantially scanned site, not a laboratory-certified saving for every installation.

The more important point

Whether a particular website saves 10 kg, 100 kg or more, the engineering principle remains sound:

Do not run an entire content-management system merely to discover that an obviously unwanted request should be refused.

Early rejection improves security, frees server capacity and reduces unnecessary processing and data transfer. The carbon saving is not a separate green feature bolted onto the plugin. It is 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”.