JavaScript is the code that makes menus open, sliders slide and forms check what you typed. Every visitor downloads it before it can do anything. On many sites, a good share of that code is never used on the page the visitor is looking at: a gallery script on a page with no gallery, a booking widget's code on the “About us” page. Chrome has free tools that show you how much, and the fixes are often decisions rather than programming.
Where unused code comes from
Few people set out to send code nobody needs. It usually builds up over time:
- Plugins and add-ons that load their scripts on every page, even if their feature only appears on one.
- Features that were switched off but whose code is still loaded: an old popup, a slider replaced by a still image, a trial that ended.
- Themes and page builders that bundle code for every possible layout, whether or not you use it.
- One large bundle containing the code for the whole site, delivered to every page.
Third-party tags such as analytics and chat widgets add JavaScript too. They have their own considerations, including cookie consent, which we cover in cookie banners, tags and your carbon test. This article focuses on the code your own site loads.
Look for yourself with Coverage
Chrome DevTools has a Coverage panel that records which parts of your JavaScript and CSS files actually run.
- Open your page in Chrome and open DevTools (F12, or Cmd+Option+I on a Mac).
- Press Ctrl+Shift+P (Cmd+Shift+P on a Mac), start typing “coverage” and choose Show Coverage. You can also find it under More options, More tools, Coverage.
- Click the Reload button in the middle of the panel to record the page loading.
- Read the table. For each file it shows the type (CSS or JavaScript), the total bytes and the unused bytes. In the bar, green is code that ran and grey is code that didn't.
- Click a row to open the file and see unused lines marked with grey lines next to the line numbers. This part is mainly useful to a developer.
One caution: “unused” means unused during this recording. The panel keeps recording while you interact, so open the menu, use the form and click around, then stop the recording to see what is still unused. Code that only runs when someone opens a menu isn't waste, but it may not need to load before they do.
Look at the file names too. They often reveal which plugin or feature a file belongs to, which is the information you need to decide what to do with it.
What PageSpeed Insights flags
If you'd rather not open DevTools, run your page through PageSpeed Insights and look in the diagnostics for “Reduce unused JavaScript”. Lighthouse, which powers the report, flags every JavaScript file with more than 20 KiB of unused code and lists them with their sizes. Its guidance for WordPress sites is to consider reducing, or switching, the plugins that load unused JavaScript on the page.
Because it's a single load with no clicking, this list will include code that is needed later, after an interaction. Treat it as a list of questions, not a list of things to delete.
What you can do about it
- Remove plugins and widgets you don't use. Uninstall what you've finished with, then run the Coverage panel again to confirm its files have gone.
- Load features only where they appear. Ask whether a feature's script can be limited to the pages where the feature appears. Lighthouse's Drupal guidance makes the same point: a theme or module should only attach a script if it is actually used on the page.
- Choose lighter alternatives. If one plugin does a small job with a lot of code, it's fair to ask whether a simpler one, or a few lines of HTML and CSS, would do.
- Ask your developer about code splitting. web.dev describes code splitting as splitting the bundle into pieces and only sending what's necessary at the very beginning; the rest is fetched when it's needed. On a custom-built site, a fair question is: “Does each page only load the code it needs?”
Test on a copy of the site, or at a quiet time, and click through the important journeys afterwards, such as enquiry forms and checkout. Removing a script that something else depends on is the main risk here.
How it shows up in your result
GreenTracer measures one first, uncached load of the page with PageSpeed Insights, on mobile and desktop, and uses the heavier run. JavaScript that downloads during that load is counted, at its compressed transfer size, whether or not it runs. Code that only loads after a click or a scroll isn't counted, because the test doesn't click or scroll.
Under the Sustainable Web Design Model v4, each megabyte removed from the load lowers the estimate by about 0.148 g CO₂e per page view (about 0.121 g on a host listed as green). Treat the “unused” figures as a guide rather than a promised saving: some of that code may still be needed, and files can only be trimmed so far. The way to know is to check your page again after the change. Saved reports keep the earlier check as history, so the before-and-after sits in one place. See how the grades work for what a change in weight means for your rating.
