A typical WordPress site runs on a handful of plugins: a contact form, a gallery, a cookie banner, an SEO tool, perhaps a shop. Each one can add its own stylesheets, scripts, fonts and images to the pages visitors load. Your carbon report shows the total weight of a page, but not which plugin brought what. Here is a safe way to find out, using Chrome and a copy of your site. You don't need to be a developer.
Why plugin files are easy to spot
WordPress keeps plugins in their own folders. The WordPress.org guide to managing plugins describes them living in the wp-content/plugins directory, one folder each. When a plugin adds a file to a page, the address usually shows it: something like /wp-content/plugins/plugin-name/assets/style.css. The Plugin Handbook tells developers to build those addresses with plugins_url(), so the folder name is normally right there in the URL.
The handbook also sets out the polite way for a plugin to load its files: register them with wp_enqueue_script() or wp_enqueue_style() on the wp_enqueue_scripts hook. For the admin area it is blunt: “only enqueue your script on pages where it is needed”. In that spirit, a form plugin's script belongs on the contact page, not on every blog post. The Network panel shows whether yours behaves that way.
Step 1: list the page's files
Open the page in Chrome, press F12 to open DevTools and choose the Network panel. Tick Disable cache, which the DevTools Network reference says emulates a first-time visitor, then reload. That matches a GreenTracer check, which measures one first, uncached load. If you haven't used this panel before, how to check your page weight walks through the basics.
Every file the page fetched is now listed. The Size column is the one to watch: Chrome defines it as the response headers plus body “as delivered by the server”, which is the transferred size a carbon estimate is based on. The status bar at the bottom shows the total transferred for the whole page. Write that number down; it is your starting point.
Step 2: group and add up by plugin
Type /wp-content/plugins/ into the Filter box. The reference says plain text matches against the request URL, so only plugin files remain. The status bar then shows how many of the page's requests are left out of the total.
Now narrow it to one plugin at a time by typing its folder, for example /wp-content/plugins/plugin-name/, and add up the Size of each row; a spreadsheet with one line per plugin is enough. The JS, CSS, Img and Font buttons split a plugin's files by type, and the larger-than: filter (for example larger-than:100000, in bytes) picks out the big ones quickly.
Three things the folder filter won't catch, so check for them too:
- Files from other domains. A plugin may pull in a script or font from an outside service. Clear the filter and look for addresses on domains you don't recognise; the
domain:filter shows one at a time. - Inline code. WordPress lets a plugin attach code straight into the page with functions such as
wp_add_inline_script(). That code travels inside the HTML document, so it adds to the page row rather than appearing as its own file. - Images in your uploads. Files in your Media Library live in
wp-content/uploadsby default, even when a gallery plugin displays them. They are your content rather than the plugin's overhead; see image weight for those.
An illustrative example: if the files under one plugin's folder add up to 400 kB on a page that weighs 2 MB, that plugin is a fifth of the page. Using GreenTracer's Sustainable Web Design Model v4 figure of about 0.148 g CO₂e per MB on a standard host, those 400 kB are about 0.059 g of every view of that page.
Step 3: test without touching the live site
Once you have a suspect, you want to know what the page looks like without it. There are two safe ways.
Block it in your own browser first. Chrome's Network tutorial shows how: press Ctrl+Shift+P (Command+Shift+P on a Mac), type block, choose Show Request Blocking, click Add Pattern and enter the plugin's folder path, then reload. It answers the tutorial's own question, how a page looks and behaves when some of its resources aren't available, and nothing changes for your visitors. Untick Enable request blocking when you are done.
Deactivate it on a staging copy. Blocking files is only a preview. WordPress's own troubleshooting advice is to try “deactivating plugins one at a time”, but do that on a staging copy of the site, not the one your customers use. If you don't have one, ask your host or web person how to make one. Before any change, make a backup: the WordPress backup guide says a full backup has two parts, the database and the files, and that you need both to restore a site. Then deactivate one plugin, reload the same page with the cache disabled, and compare the status bar total with your starting figure.
What to do with what you find
For each plugin that adds noticeable weight, there are usually three choices, in this order:
- Check its settings. A plugin may have an option to load its files only on the pages that use it, or features you can switch off because you don't use them.
- Ask whether it earns its place. If it does one small job on one page, your web person may be able to limit where it loads, which is the “only where needed” principle from the handbook.
- Replace or remove it, after testing on staging, if the weight is high and the benefit low.
Plugin scripts are often only partly used on a given page; to see how much, read finding unused JavaScript. Page builders and big plugins often do the same with styles, covered in unused CSS and page builders. When you have made a change on the live site, check the page again so the report records the new weight.
Sources
- WordPress Plugin Handbook: Enqueuing
- WordPress code reference: wp_enqueue_style()
- WordPress code reference: wp_add_inline_script()
- WordPress.org documentation: Manage Plugins
- WordPress Advanced Administration: WordPress Backups
- Chrome DevTools: Network features reference
- Chrome DevTools: Inspect network activity (request blocking)
- WordPress.org documentation: Settings Media screen
