When website owners do site speed testing, they eventually observe plugins get loaded on every page, adding to code bloat and slower load times everywhere. They hopelessly think, “I don’t need these activated on all pages, but I have no way of controlling this.” This isn’t true.

What if a plugin could load on-demand? Even just parts of it, only when it was needed, instead of on every page load? These solutions exist and we have written about them.

REFERENCE: Selective activation of plugins for improved speed.

It’s true. Most plugins load virtually all their code, every single time, on every single WordPress page and post. The plugin author is at fault for not correctly coding their plugin to properly load things only when they’re needed.

Sites get bogged down from slow (or too many) database queries or too many CSS/JS files loading. It really isn’t WordPress’ job to control these things. It’s the plugin author’s job.

Plugins authors should be better educated on how to properly write their plugins so they do not load needlessly. Yes. It’s an education problem. It’s not super technical or even a flaw really.

It isn’t the responsibility of WordPress to control third-party plugins. Changes to any particular plugin requires talking to the individual plugin authors. There are more than 50,000 plugins. Big education job. We don’t have the resources to do it. Do you?

How can we say this without disturbing the natives?  Plugin authors frequently ignore being empathetic to user’s speed needs. The fault lies in being in too big of a hurry to do it right – or not being creative. They erroneously don’t think milliseconds are a problem. This is speed apathy.

Things will get better. Mobile has changed users need and perception for faster, speedier plugins.

We quote ourselves. (That’s pretty arrogant and pretentious. We know.)

Why does the silly form load everywhere – instead of only on the page with the shortcode like it should?

“Contact Form 7 isn’t the only form plugin that loads its Javascript and CSS files on every page. This is not uncommon for most slider plugins, too. We call this global loading – or site drag. It’s a bad way to do things for speed. While it’s common, it’s not a universal practice. We’ve found sliders and forms that only load code on pages containing their shortcodes. How can you tell? Only by testing. There is nothing in the plugin documentation telling if this will happen. It’s a negative thing – so why would they publish it? Honesty perhaps?

You’d think those plugins that have better behavior would advertise speed benefits – but they don’t. Not yet anyway.”

PagePipe: Contact Form 7 plugin causes global site drag

Site drag isn’t inherent in every plugin. Some plugins are created with speed in mind. These plugins allow plugin activation of features on groups of pages for example, post only. But these are uncommon plugins built by conscientious authors who recognize speed is a desirable bonus and differentiator.