The short answer
There are seven usual suspects: slow server response, no caching, unoptimized images, a missing or misconfigured CDN, plugin or theme bloat, database bloat, and render-blocking code. None of them has a single fix that covers all seven, and treating one symptom (a slow load) as if it always has one cause is the mistake most speed advice makes.
Server
Slow origin response time before anything else runs.
Caching
No page cache, no object cache, or a cache that isn’t being hit.
Images
Uncompressed, oversized, or lazy-loaded above the fold.
CDN
Missing entirely, or configured so static files never hit the edge.
Plugins and theme
Queries, CSS and JavaScript added to pages that don’t use the feature.
Database
Revisions, expired transients and orphaned metadata piling up.
Render-blocking code
CSS and JavaScript that delays the first paint of the page.
The order to check them in matters more than any individual tactic. Server response and caching come first, because a slow origin server undermines everything built on top of it. Images and the CDN come next, since they’re the most visible cause on a typical page. Plugin and database cleanup come last, because they take the most care to do safely. How the speed work gets scoped breaks down what a structured pass through all seven actually looks like.
How it actually works
Caching, images, and the CDN
Full-page caching serves a static, pre-built copy of a page to a visitor instead of running PHP and querying the database on every request. Object caching goes a layer deeper: it stores the results of expensive database queries so the same query doesn’t run twice. Browser caching stores static assets like CSS and images directly on the visitor’s device so a repeat visit doesn’t re-download them. Each of these solves a different part of the problem, and none of them fixes a query or a page that was slow to begin with. As Jetpack puts it, caching will hide performance issues, but it will not fix the root cause.
Images are the biggest lever most sites have, and also where the most common piece of advice backfires. Lazy loading defers loading an image until it’s about to scroll into view, which is useful for images far down the page. Applied indiscriminately, including to the image at the top of the page, it’s measurably worse: web.dev’s own A/B test found that lazy-loading above-the-fold images made archive pages 13 to 15 percent slower on both desktop and mobile. That’s specifically because the largest above-the-fold image is usually the LCP element, the one Core Web Vitals is timing, and delaying it delays the whole measurement. WordPress core now recognizes this and doesn’t lazy-load the first featured or content image on a page for that reason.
A CDN caches static content, images, CSS, JavaScript, at edge locations closer to the visitor, so a request travels a shorter physical distance. Cloudflare’s own illustrative figures put a request from Atlanta at roughly 1,100 milliseconds and the same request from Singapore at roughly 3,000 milliseconds without a nearby edge location, a reduction of about 63 percent with one, though that’s a directional example rather than a guarantee for any specific site. What a CDN can’t do is speed up PHP execution or a slow database query. It moves static files closer to the visitor. It doesn’t touch what happens on the origin server before those files are generated.
After each change, run a Core Web Vitals check rather than trusting that the change worked. A caching or CDN change that looks right in the plugin settings can still leave LCP, INP or CLS unchanged if the actual bottleneck was somewhere else.
Plugins and the database
Every active plugin can add its own database queries, CSS and JavaScript to a page load, whether or not that plugin’s feature is actually being used on that page. There’s no verified number for how many plugins is too many. Any specific count offered as a safe threshold isn’t backed by a real source, so treat it as noise.
Database bloat builds up the same way: post revisions, expired transients and orphaned metadata from removed plugins accumulate in the database and slow down the queries that run on every page load. Cleaning it up means removing rows and rebuilding indexes, and a backup before either of those steps isn’t optional. Plugin and theme updates are also a common, overlooked cause of a sudden slowdown: an update can silently change caching behavior or add a heavy new dependency, which is exactly what the update process that catches a plugin-caused slowdown is built to catch before it ships to the live site.
After a database cleanup or a plugin change, re-run the Core Web Vitals check and confirm the backup taken beforehand actually restores, not just that it exists.
Why it matters for a business site
Google’s own documentation is more measured than most speed advice suggests. Google Search Central states plainly that Core Web Vitals are used by its ranking systems, and in the same breath that Google Search always seeks to show the most relevant content, even if the page experience is sub-par. Speed is a factor. It isn’t the only one, and a faster page that’s less relevant to the search still loses to a slower, more relevant one.
For a small, low-traffic brochure site, a caching plugin plus a free CDN tier can genuinely be enough. The honest gap a managed service closes isn’t the initial setup, it’s what happens in the months after: a plugin update that silently disables the cache, an unoptimized image uploaded straight from a phone, or database bloat that nobody’s watching build up. None of those show up the day they happen. They show up as a slow site three months later with no obvious cause.
What good looks like
The benchmark is Core Web Vitals, measured at the 75th percentile and split by mobile and desktop, not a single load-time number:
| Metric | Threshold for “good” |
|---|---|
| Largest Contentful Paint (LCP) | 2.5 seconds or less |
| Interaction to Next Paint (INP) | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | 0.1 or less |
An update is one of the most common causes of a site suddenly missing one of these three, which is why testing an update before it goes live, and having a rollback if it breaks something, ties directly back to speed rather than being a separate concern. The ongoing maintenance routine that speed work depends on covers more than the update itself.
What to do about it
Work through these in order rather than picking the one that sounds most familiar:
- 01Check server response time first. If the origin server itself is slow, caching and a CDN only mask the problem for cached pages and do nothing for anything dynamic.
- 02Add page caching. A full-page cache serves a static copy instead of rebuilding the page on every request, which is the change most likely to matter on most sites.
- 03Fix above-the-fold lazy loading. Make sure the first visible image, usually the LCP element, loads eagerly rather than lazily. Reserve lazy loading for images further down the page.
- 04Compress and correctly size images. An oversized or uncompressed image is one of the most common reasons LCP misses the 2.5 second threshold.
- 05Clean up database bloat, with a backup first. Remove stale revisions, expired transients and orphaned metadata, and confirm the backup restores before making any changes.
NoDrama’s speed retainer runs the checks above every month, not once. Plans differ in CDN capacity and backup cadence: Essential includes 5GB of CDN with daily backups, Professional includes 20GB of CDN with backups every 12 hours, and Business includes 30GB of CDN with hourly backups. What’s included at each plan level has the full breakdown.
After working through the list, re-run the Core Web Vitals check and compare it to the thresholds above rather than to how the site feels.
Common misconceptions
“Lazy-load every image.”
Wrong for the LCP element specifically. web.dev’s own test showed lazy-loading above-the-fold images made archive pages 13 to 15 percent slower. Lazy-load what’s below the fold, not what’s above it.
“Page speed is a major ranking factor, full stop.”
Google’s own position is narrower than that. Core Web Vitals feed the ranking systems, but Google states directly that it still favors the more relevant page even when its page experience is worse.
“A CDN fixes a slow site.”
A CDN moves static content closer to the visitor. It does nothing for a slow database query or an unoptimized PHP process on the origin server, so a slow origin stays slow behind a CDN.
What this does not solve
None of the above fixes under-provisioned hosting. If the server itself doesn’t have the resources for the site’s traffic, caching and a CDN reduce how often that limit gets hit, but they don’t raise the limit. The same goes for a badly written theme: code that runs unnecessary queries or ships excessive CSS and JavaScript stays slow no matter how well everything around it is tuned. A full care plan covers the parts of ongoing WordPress operation that sit outside performance work specifically.
Is my WordPress site actually slow, and what’s the fix?
A slow WordPress site is almost always more than one problem at once: server response, caching, images, the CDN, plugins, the database and render-blocking code all contribute, and there’s no single fix that covers all seven. The honest way to check is Core Web Vitals at the 75th percentile, LCP at 2.5 seconds or under, INP at 200 milliseconds or under and CLS at 0.1 or under, worked through server response and caching first, then images and the CDN, then plugin and database cleanup, verifying with a fresh Core Web Vitals check after each step.