Plugins That Load on Every Page

The privacy policy that loads a map

Open the privacy policy on a typical small business WordPress site and look at what arrives with it. Some text, and a great deal of code that has nothing to do with privacy.

The script for the home page slider. The styles and scripts for the contact form. The map from the contact page, and the booking widget from the reservations page.

None of them appear on the privacy policy. All of them load there anyway, and on every other page of the site.

How plugins end up everywhere

WordPress gives plugins a standard way to add their scripts and styles to a page, and the theme prints that list into every page it builds.

A plugin could check whether the page actually contains a form, a slider or a map before adding its files. Many skip the check, since loading everywhere is the simplest way to be sure they work.

Outside services often arrive the same way by a different route. The booking service's instructions say to paste its code into the site header, and the header is on every page.

What usually loads where it is not needed

• The slider, with its script and styles, on pages that have no slider.
• The form plugin, whose files arrive even where there is no form.
• A map embedded in the footer, and therefore on every page.
• The booking widget, pasted into the header as its instructions said.
• An icon library, loaded in full to show a handful of symbols.
• Social feeds and share buttons, each with scripts from elsewhere.

The third is often the heaviest. An interactive map brings its own scripts, images and fonts from Google, and a footer map loads them on every page.

Why it costs more than the download

Size is only part of the cost. A browser has to download each script, then read it and run it, and on a mid-range phone running scripts is slow work.

Scripts and styles placed at the top of the page can also hold up its first appearance, because the browser waits for them before showing anything. PageSpeed Insights lists them as render-blocking resources.

While scripts run, a page can look ready without responding to taps. Time to Interactive, one of the figures in the same test, measures how long that lasts.

Every active plugin also runs code on the server for every page, which can add to the wait before the first byte arrives.

Finding out what each page loads

Pick the plainest page, such as the privacy policy, and open it in Chrome with the developer tools showing. The Network tab lists every file the page requested.

Filter to scripts and styles, then read the addresses. Files from a plugin usually include its folder name after wp-content/plugins, so each one can be traced to the plugin that sent it.

Anything from a plugin the page does not use is a candidate for removal. The Coverage panel in the same tools shows how much of each file the page actually used.

Loading each one only where it is used

The fix is to tell each plugin where it belongs. The contact form loads on the contact page, the slider on the home page, the booking widget on the booking pages.

Some plugins have a setting for exactly this. Others need a few lines in the theme that remove their files from pages that do not need them, which is routine work for a developer.

Whichever way it is done, test afterwards. A form in a pop-up or a footer widget needs its plugin's files on pages with no form in the main content, and restricting them breaks it quietly.

A worked example

A cooking school in a former bakery had a WordPress site with pages for evening classes, private events and team-building nights, plus a booking page and a contact page.

Every page loaded the booking script, a footer map, the home page slider, the form plugin's files and a full icon library. The privacy page requested dozens of files to show four paragraphs.

The booking script now loads only on the booking page and the class pages. Elsewhere, a plain Book a class button links to the booking page instead.

The footer map became the address as text, with a link for directions. The contact page kept its map, as a still image that opens Google Maps when tapped.

The form plugin was limited to the two pages with forms, and the slider to the home page. The icon library was replaced by the six icons the site actually used, saved as small image files.

Nothing visible changed on any page. What changed was everything that had been loading where nobody could see it.

The plugins worth replacing

Some plugins are not worth restricting, because they bring a lot to do a little.

A slider framework used to show one still image. A page builder's animation library loaded so a heading can fade in. A sharing plugin pulling scripts from five networks for buttons that plain links could provide.

Two plugins doing the same job are common too: two lightbox scripts for enlarging photographs, or the same icon library loaded twice by different plugins.

Each can usually be replaced by a few lines of code or a lighter plugin. And the fewer plugins a site runs, the fewer there are to update.

The counter-case

On some sites, loading everywhere is correct. If every page has a quote form in the sidebar, the form plugin belongs on every page.

Small scripts are not worth the effort either. A few kilobytes of code that runs instantly makes no difference, and the time is better spent on photographs, usually the bigger weight.

And a site built on a heavy page builder can only be trimmed so far. Past a point, rebuilding on a lighter theme is the better use of money, and a developer can tell you where that point is.

On most sites the rule is simple: each plugin loads where it is used, and nowhere else.

The order to do it in

1. Open the plainest page on the site.
2. List every script and style it loads.
3. Trace each file to its plugin.
4. Restrict each plugin to the pages that use it.
5. Replace any footer map with an address and link.
6. Remove plugins that do a small job heavily.
7. Test every form after each change.

Step four does the most. The files stay on the pages that use them, so nothing changes for visitors except that every other page stops carrying them.

The other half of a heavy page, the photographs, is covered in images sized for a billboard on a phone screen.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.