I recently ran goodrich.digital through Website Carbon and the result came back as A+, with an estimated 0.03g of CO2 produced each time someone visits the page.
That’s great, but I don’t think the useful part is the badge. The useful part is the clue.
A low-carbon page is often a lean page. It tends to have fewer oversized images, fewer unnecessary scripts, fewer third-party requests and less work for the browser. That doesn’t automatically mean the page will rank, convert or sell, because a fast, lightweight website can still have a weak offer, unclear copy, poor forms or the wrong traffic. But a leaner technical foundation usually gives SEO, PPC and CRO work a cleaner starting point.
That’s why I think website carbon scores are useful for ecommerce and lead generation brands, even when sustainability isn’t the main commercial driver. They can reveal avoidable page weight, and that same weight often shows up elsewhere: slower page speed, weaker Core Web Vitals, poorer mobile experience, noisier measurement and more fragile paid traffic.
What a website carbon score is actually measuring
A website carbon calculator gives an estimate of the emissions associated with loading a web page. It isn’t a full environmental audit of a business, a website or a supply chain.
The Sustainable Web Design Model describes itself as a model for estimating digital emissions. It uses data transfer as a main input, while also acknowledging that there’s ongoing debate in the research community about using data transfer as the core measurement unit.
That caveat is important, because a website carbon score should be treated as a signal, not a verdict. It can tell you something useful about how much data a page transfers and, depending on the calculator, whether the hosting appears to run on cleaner energy. It can’t tell you whether a page is persuasive, whether leads are qualified, whether the business is sustainable, or whether the website is commercially effective.
Still, data transfer is worth paying attention to. A page that transfers less data is usually asking less of the network, the browser and the user’s device. That’s where the performance link becomes useful.
When Website Carbon reports a very low estimated CO2 figure for a page, I don’t read that as proof of overall sustainability. I read it as a good sign: the page probably isn’t carrying much unnecessary weight, which gives the commercial work around it a cleaner starting point.
Why sustainable web design is also a performance issue
Sustainable web design is sometimes discussed as though it belongs in a separate environmental conversation. I think that misses the most practical point for commercial websites.
A lower-impact page often comes from the same decisions that make a website easier and faster to use: images sized to the space they actually occupy, fewer unnecessary scripts, fewer third-party tools loading before the main content, fonts delivered without avoidable network steps, cleaner templates, less unused CSS and JavaScript, and fewer decorative assets that don’t help the visitor decide.
Those are sustainability decisions, but they’re also performance decisions.
Google describes Core Web Vitals as metrics that measure real-world user experience across loading performance, interactivity and visual stability. Google also recommends that site owners achieve good Core Web Vitals for Search and user experience, while making clear that page experience is only one part of broader search quality.
A good Core Web Vitals report doesn’t guarantee rankings. A low-carbon score doesn’t guarantee conversions. But both can point towards the same underlying discipline: a page that loads cleanly, behaves predictably and doesn’t make the visitor wait while the business ships unnecessary weight.
For ecommerce and lead generation sites, the difference shows up after the click.
SEO may earn the visit. PPC may buy the visit. Email may return the visit. Social may prompt the visit. Once the visitor lands, the page has to carry its part of the job. A heavy page makes that harder, especially on mobile, where connection quality, device power and patience can all be limited.
Carbon scores and PageSpeed scores often point to the same accumulation
I’ve written separately about how goodrich.digital achieved 100/100 on PageSpeed Insights.
The useful lesson from that work wasn’t the final score, but the work behind it: smaller image variants, better loading priority, cleaner font delivery, less JavaScript work and testing the article templates that actually carry search visibility.
A website carbon score and a PageSpeed score are measuring different things, but they often expose the same accumulation.
On goodrich.digital, the PageSpeed work included reducing the mobile hero image payload from 67 KB to 15 KB with responsive WebP variants, using preload hints for the LCP image, removing a forced reflow caused by scroll behaviour, self-hosting fonts and auditing unused font weights.
Those changes were made for performance, but they also reduced avoidable transfer and unnecessary browser work.
That’s the overlap I care about: not the badge, but the build decisions.
A page can look polished and still be inefficient. The design can feel finished while the browser is downloading desktop-sized images on mobile, loading unused font weights, waiting on third-party scripts, processing old tracking tags or dealing with JavaScript that adds very little to the visitor’s decision.
This kind of weight rarely appears as one dramatic problem. It builds up in small decisions: one oversized image, one extra plugin, a chat widget added for a campaign, a review tool that appears on every page, a cookie banner that loads too early, a page builder that ships more code than the template needs, or a font library carrying five weights when two would do.
A carbon score gives you another reason to question that accumulation.
Why bloated WordPress builds create commercial drag
WordPress isn’t automatically slow. Plenty of WordPress sites are fast, useful and commercially sound.
The problem is usually what gets added over time.
A site starts with a flexible theme. Then a page builder is added because the business wants quicker content changes. Then come forms, pop-ups, cookie tools, sliders, analytics tags, call tracking, chat, reviews, heatmaps, social embeds, CRM scripts, A/B testing tools and plugins for features that could have been handled more simply in the template.
Each addition may have a reason to exist. Together, they can leave the browser doing far more work than the visitor or the business needs.
The real cost isn’t the lower Lighthouse score, but a site that becomes harder to maintain, harder to measure and slower at the exact point someone has shown intent.
On a lead generation site, that might mean the service page takes too long to become usable on mobile. The visitor waits, scrolls, hesitates and leaves before the enquiry form has done its job.
On a paid search landing page, it might mean the business pays for a good click, then loses value because the page is carrying scripts, tracking and visual furniture that don’t help the visitor decide.
On a content-led SEO site, it might mean the article earns visibility but the reading experience is weaker than it needs to be. Search got the person there, but the page didn’t respect the visit.
A website carbon score won’t diagnose all of that on its own. But a poor score, especially when paired with a poor PageSpeed report, should make you ask what the page is loading, why it’s loading, and whether the visitor or the business actually needs it.
Those are commercial questions, not just technical ones.
Magento, ecommerce complexity and the cost of every extra feature
Magento is a good example, and one I know well, having worked with Magento websites for over 10 years. Ecommerce sites carry more operational complexity than a simple brochure site, and that complexity usually finds its way onto the front end.
Product media, layered navigation, faceted filters, site search, reviews, recommendations, payment scripts, stock data, promotions, analytics, product feeds, affiliate tracking, consent tools and personalisation can all be part of the commercial requirement.
The issue isn’t Magento itself, but how much gets layered onto the front end without a clear performance budget.
On an ecommerce site, page weight is rarely only a technical issue. It affects how quickly product pages become usable, how easily shoppers move through categories and how much paid traffic is wasted before someone has even seen the offer properly.
Deloitte’s Milliseconds Make Millions research with Google found that a 0.1 second improvement in mobile site speed was associated with an 8.4% increase in conversion rate for retail sites and 10.1% for travel sites. I wouldn’t treat those figures as a forecast for every website, but they do show why small speed improvements can make a real commercial difference when there’s enough traffic and intent.
For ecommerce managers, the decision is rarely whether the site should have features. Of course it should. The more useful question is whether each feature earns the weight it adds.
A review widget may help conversion. A recommendation engine may increase average order value. A promotion tool may support merchandising. A payment script is essential. But when every team adds something to the page and nobody owns the combined cost, the site gets heavier.
The visitor feels that before it appears in a performance report.
Why a performance plugin isn’t a strategy
Caching and optimisation plugins can help. So can CDNs, image compression tools, minification, lazy loading and script delay settings.
But a performance plugin can’t make every build decision commercially sensible.
It can tidy parts of the mess, but it can’t answer whether the mess should exist.
That distinction is sharpest on bloated WordPress, WooCommerce and Magento builds. If the page is shipping oversized images, loading unused JavaScript, carrying old marketing tags and asking several third-party tools to wake up before the main content, a plugin may improve the report. It might not solve the underlying issue.
HTTP Archive’s 2024 Web Almanac reported that JavaScript overtook images as the dominant file type, with the median page requesting 24 JavaScript files on desktop and 22 on mobile.
That’s significant because JavaScript is more than a download. It can also mean parsing, compiling and executing code on the user’s device. On a newer laptop with a strong connection, the page may feel acceptable. On a mid-range mobile device on a patchy connection, the same page can feel slow, sticky or unstable.
This is where performance work needs judgement.
Compressing images is useful. Delaying non-essential scripts is useful. Caching is useful. But the higher-value work is often deciding what the page should stop doing.
That might mean removing an animation library, limiting chat to pages where it helps, stopping old campaign tags from firing, reducing font weights, simplifying a slider, or delaying non-essential tools until after the main content is usable.
A lower-carbon, higher-performance page usually comes from restraint. Not stripping the site bare. Just making every asset justify its place.
What I’d check on a heavy website
If a business came to me with a poor website carbon score, weak mobile PageSpeed results or complaints about slow landing pages, I wouldn’t start by looking for one magic fix.
I’d start by checking the pages that count commercially.
That usually means product pages, category pages, service pages, lead generation landing pages, high-traffic articles and PPC landing pages. The homepage is worth testing, but it’s often not the page doing the hardest commercial work.
In my own PageSpeed work, the homepage reached 100/100 before an SEO-important article was checked. That article was still scoring 74 on mobile because it carried oversized images, missing image dimensions and separate template-level issues.
It’s often the pages bringing in the most traffic, rather than the homepage, that are carrying the most weight.
Page weight on mobile
The first check would be mobile page weight. How much data is the page transferring on a fresh load, and which assets account for most of it?
Heavy pages aren’t automatically bad, but every extra megabyte should have a reason. This is where a carbon score can be useful, because it encourages a simple question: what is the page asking the visitor’s device to carry?
LCP and image sizing
Then I’d look at the Largest Contentful Paint element. On many commercial pages, it’s the hero image, a heading block or a large product image. If that element is late-discovered, oversized or competing with other high-priority assets, the user waits longer for the main content to feel ready.
Image sizing is usually close behind. Mobile visitors shouldn’t be downloading images far larger than their screens need. On goodrich.digital, one of the biggest wins came from changing what the browser downloaded, not what the visitor saw.
Scripts, plugins and extensions
JavaScript and third-party scripts need a separate review. Tracking, testing, chat, reviews, consent, forms and personalisation tools can all have a place. The question is whether they need to load immediately, everywhere and for every visitor.
I’d also check which WordPress plugins, WooCommerce extensions or Magento modules affect the front end. A plugin that only supports admin workflows might not affect page speed. A plugin that loads scripts and styles on every page does.
Fonts and templates
Fonts are another common source of quiet weight. I’d check how many files load, whether they’re self-hosted or fetched from a third party, and how many weights and styles are actually used. Fonts are part of brand presentation, but that doesn’t mean every weight needs to be shipped to every visitor.
Template-level fixes go further than page-by-page ones. If article images need width and height attributes, build that into the content pipeline. If product images need better responsive handling, fix the product template. If every landing page inherits the same unnecessary scripts, fix the layout.
Commercial evidence after the technical work
After the technical work, I’d still come back to commercial evidence. A better score is useful, but I’d want to know what changed in conversion rate, qualified leads, revenue, average order value, cost per qualified lead, CRM feedback or sales quality where the data exists.
The score should inform a decision, but it shouldn’t be the whole decision.
What a website carbon score doesn’t prove
A website carbon score can be useful, but it’s easy to overclaim it.
A carbon score doesn’t prove the business is sustainable, the whole site is fast, or the content converts. It doesn’t tell you whether leads are qualified, whether SEO will improve, or whether paid media will become more profitable. It also doesn’t replace PageSpeed Insights, Search Console, analytics, CRM data, heatmaps, user testing or sales feedback.
That’s why I wouldn’t use a carbon score in isolation. I’d use it as a prompt.
If the score is poor, ask what’s making the page heavy. If the score is good, ask whether the same discipline holds across the pages that actually drive visibility, enquiries and revenue. If the page is lightweight but not converting, look beyond performance and review the offer, intent match, copy, proof, form friction, pricing clarity, trust signals and follow-up process.
A lean site gives commercial work a cleaner foundation, but it doesn’t do the commercial work by itself.
Practical takeaways
A website carbon score is most useful when it leads to better questions about performance and page weight.
For a WordPress site, I’d look closely at page builders, plugins, unused CSS, third-party scripts, tracking tags, cookie tools, fonts and media handling.
For a Magento or ecommerce site, I’d look at product imagery, category templates, layered navigation, reviews, search, recommendations, payment scripts and promotional tools.
For a lead generation site, I’d test the pages closest to enquiry: service pages, PPC landing pages, contact pages and embedded forms.
For a content-led SEO site, I’d test the articles and templates that bring in organic visibility, not only the homepage.
For any site, I’d connect technical improvements to commercial measures. Faster pages are useful, but the follow-up question is what changed in qualified enquiries, sales, revenue, cost per sale, conversion quality or user behaviour.
Final thoughts
A website carbon score won’t tell you whether a page is persuasive, profitable or strategically useful. But it can reveal how much unnecessary weight sits between the visitor and their next step.
For many WordPress, WooCommerce and Magento sites, that’s a useful place to start. Smaller pages, cleaner templates, fewer unnecessary scripts and better loading priorities tend to support both sustainability and commercial performance.
The carbon score isn’t the prize, it’s a clue. The value comes from what you decide to check, remove, improve or leave alone after seeing it.
