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.
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 45,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?
You’d think those plugins that have better behavior would advertise speed benefits – but they don’t. Not yet anyway.”