Why WordPress is slow, and what actually fixes it

WordPress is not slow by itself. It is made slow by decisions accumulated over years: a marketplace theme, thirty plugins, a page builder, camera-sized images and three-dollar hosting. Each looks harmless on its own; together they produce a site that takes five seconds to open.

The usual reaction is to install a caching plugin. Sometimes that helps; more often it hides the problem: the page is served faster but weighs the same, and on a phone with a poor connection nothing changes.

What Google actually measures

Not by abstract “speed”, but by three Core Web Vitals. The thresholds are published and the same for everyone:

• LCP - how long the largest element on screen takes to appear. Good: under 2.5 seconds.
• INP - how long the page takes to respond to an interaction. Good: under 200 milliseconds.
• CLS - how much the content jumps around while loading. Good: under 0.1.

Crucially, Google looks at data from real visitors rather than a one-off test. Your score is therefore mostly phones on mobile data, not your laptop on wifi.

The order worth fixing things in

Images almost always give the biggest win. Not because it is hard, but because on a typical site they are most of the page weight. The right format, the right size for the container, and deferring everything below the fold often pull LCP into the green on their own.

Fonts come second. Every Google Fonts request is a separate connection to somebody else's domain before a single letter appears. The same file hosted alongside the site and preloaded removes that wait.

Third, plugins. Not their number as such, but how many of them load their own CSS and JavaScript on every page, including pages where they do nothing. A contact-form plugin pulling its scripts onto a homepage that has no form is the standard case.

Caching speeds up how fast the page is served. It does not make the page lighter. If your homepage is 4 MB, the cache will deliver the same 4 MB - it will just start sooner.

A separate matter: builders

Elementor, WPBakery and the rest solve a real problem: letting somebody without a developer change pages. The price is that they express layout through nested wrappers, and one section can become a dozen divs with inline styles - plus their own CSS and JS on every page.

The alternative that keeps editability is Gutenberg with ACF Flexible Content. The client still assembles pages from ready blocks in the admin, but each block is your own template emitting exactly the markup you wrote. The editing stays; the weight does not.

When to rewrite and when to treat

A rewrite is worth doing less often than it is wanted. If the content and structure suit you and the pain is speed, that is treatable without rebuilding: images, fonts, a plugin audit, decent hosting. If instead every change needs a developer and the admin is frightening, the problem is not speed and something else needs fixing.

The simplest way to tell which case you are in is to measure. Not by eye and not on your own laptop: look at the mobile numbers from real visitors, and at the list of what specifically is holding it up.