Speed Up WordPress: What Actually Moves the Number

The number most people try to raise is not the number Google uses. The PageSpeed Insights score is a lab simulation of one page load on a synthetic device. What actually gets assessed is Core Web Vitals measured from real visits, at the 75th percentile, split between mobile and desktop.

Those are different things, and they move independently. A site can score 98 in the lab and fail its Core Web Vitals assessment, because the lab test does not have your visitors' phones, networks or ad blockers.

So the first job is measuring the right thing. The second is knowing which levers pay off, because on a WordPress site they are not equal and they are not in the order most guides present them.

---

What Google actually assesses

Three metrics, and the thresholds are precise.

Metric	What it measures	Good
LCP — Largest Contentful Paint	Loading	2.5 seconds or less
INP — Interaction to Next Paint	Responsiveness	200 milliseconds or less
CLS — Cumulative Layout Shift	Visual stability	0.1 or less

Assessment is at the 75th percentile of page loads, segmented across mobile and desktop. So you are not optimising for your average visitor — you are optimising so that three-quarters of real page loads clear the bar, on the slower devices included.

INP replaced First Input Delay when it became a stable Core Web Vital in 2024. If a guide still talks about FID, it predates the change and is worth checking for other staleness.

On whether this is a ranking factor: Google's own wording is that Core Web Vitals "aligns with what our core ranking systems seek to reward", and that it "highly recommends" site owners achieve good scores. It does not publish a weight, and treating speed as a tiebreaker rather than a lever is the accurate mental model. The full picture of where it sits among technical signals is in technical SEO: what actually needs fixing.

Note what is not on the list. TTFB is not a Core Web Vital — web.dev says plainly that "it's not absolutely necessary that sites meet the 'good' TTFB threshold" — but it is the floor under LCP, which is why it appears first in the levers below.

The mechanics of each metric, and the WordPress-specific causes of each, are in Core Web Vitals for WordPress.

---

Measure before you change anything

Two sources, and they answer different questions.

• Field data — what real visitors experienced. Search Console's Core Web Vitals report, and the field section of PageSpeed Insights. This is what is assessed. It is also slow to update, because it is a rolling window of real visits
• Lab data — a simulated load. Lighthouse, the score at the top of PageSpeed Insights. This is a diagnostic, not a grade. It tells you what is slow on the page and why, which is exactly what you need while working

Use lab data to find the problem and field data to confirm you fixed it. Reversing that produces the familiar experience of chasing a score for a week and seeing nothing change in Search Console.

Test the pages that matter, not the homepage. Search Console groups URLs, and a template with a problem affects every page using it. Your highest-traffic post template is usually a better test subject than the front page.

---

The levers, in order of payoff

Six steps. On a typical WordPress site the first three account for most of the available improvement.

Step 1 — Fix the server response time first

Everything else is built on top of this. TTFB is the time before the browser has received a single byte, and it is dead time inside LCP.

The target: 0.8 seconds or less, with anything over 1.8 seconds considered poor.

What raises it on WordPress:

• Underpowered or oversold hosting, which is the most common cause and the one no plugin fixes
• An old PHP version. WordPress's own guidance is blunt: "Making sure you're running the latest version of Linux (or Windows), Apache, MySQL/MariaDB, and PHP is essential"
• No page cache, so every visit rebuilds the page from the database
• Redirects, each one adding a full round trip before anything starts
• Distance, if your visitors are far from your server and nothing is cached at the edge

If TTFB is over a second and the host is the reason, no amount of image compression will rescue the page. The decision framework for that is in choosing WordPress hosting for speed.

Step 2 — Put a page cache in front of everything

This is the single biggest return for the least work, and WordPress says so in its own optimisation documentation: "If you need a quick fix now, go straight to the Caching section, you'll get the biggest benefit for the smallest hassle there."

A page cache serves a stored copy instead of running PHP and querying the database. WordPress describes the effect on largely static pages as an improvement "several hundred times over".

And the warning attached to not having one is stronger than most people expect: "if you don't use a caching solution, performance will slow to a halt as additional page requests come in and stack up, often crashing your web or database server."

That reframes caching. It is not only a speed measure — it is what stops a traffic spike from taking the site down.

The four layers, what each one actually caches, and which of them your host may already be running, are in WordPress caching explained.

Step 3 — Fix the LCP element

LCP is usually one image. On most WordPress themes it is the featured image, the hero, or the first image in the post.

Three rules, and the third is the one that catches people:

• Do not lazy-load it. web.dev is unambiguous: "Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP." WordPress adds loading="lazy" automatically, and while core tries to skip the first image, themes and page builders routinely defeat that
• Give it fetchpriority="high" so the browser fetches it before other resources competing for bandwidth
• Serve it at the size it is displayed, in a modern format, with dimensions set so it does not shift the layout

The diagnostic that saves the most time: LCP breaks into four parts, and web.dev gives target proportions — roughly 40% TTFB, under 10% resource load delay, around 40% resource load duration, under 10% render delay. Whichever part is oversized names your fix. A large load delay means the browser found the image late; a large load duration means the image is too heavy.

Step 4 — Audit what your plugins are costing

Plugin weight is the WordPress-specific lever, and it is measurable rather than a matter of opinion.

Start with Site Health. Since WordPress 6.6 there is a check for autoloaded options — data loaded from the database on every single page request. WordPress's own guidance: "Generally, you should try to keep your site's autoloaded options under 800kb." Site Health warns above 800,000 bytes, and core now refuses to autoload any single option larger than 150 kilobytes.

A bloated autoload table is almost always a plugin, often one that was deactivated years ago and left its data behind.

The full method — measuring before deactivating, finding what each plugin loads on which pages, and doing it without breaking the live site — is in how to audit your WordPress plugins.

Step 5 — Reduce JavaScript for INP

INP is where WordPress sites usually fail, because page builders, sliders, chat widgets and analytics all compete for the same main thread.

An interaction has three parts: input delay before your code runs, processing duration while it runs, and presentation delay before the browser paints the result. Long tasks blocking the main thread inflate the first, heavy event handlers inflate the second, and a very large DOM inflates the third.

The WordPress-specific causes, in order of how often they are the answer:

• A page builder producing deep nested markup and a large DOM
• Third-party embeds — chat widgets, heat maps, tag managers loading further scripts
• Sliders and carousels, which run continuously
• Plugins loading their assets on every page rather than only where used

Deferring scripts helps; deleting them helps more. The most reliable INP fix on a WordPress site is having fewer things running.

Step 6 — Stop the layout shifting

CLS is the easiest of the three to fix and the most annoying to visitors.

• Set width and height on every image and iframe so space is reserved before the file loads
• Reserve space for ads, embeds and cookie banners rather than letting them push content down
• Load fonts with font-display: swap and a matched fallback, so the swap does not resize the text block
• Avoid inserting anything above existing content after the page has rendered

Most WordPress CLS comes from three things: images without dimensions, a cookie banner that appears late, and a web font that reflows the page when it loads.

---

What does not move the number

Worth saying, because these absorb enormous effort.

• Chasing 100 in Lighthouse. The score is a weighted lab composite. Field Core Web Vitals is the assessment, and the two can disagree completely
• Stacking optimisation plugins. Two minification plugins conflict rather than compound, and a page cache plus a second page cache is a bug, not a strategy
• Minifying HTML. Real, and measured in kilobytes, while the LCP image is measured in hundreds
• Aggressive minification of CSS and JS without testing. The most common cause of a site that got faster and stopped working — combine and minify by all means, then check the pages that use the heaviest scripts

A word on WordPress's own release benchmarks. The 6.8 performance report is instructive: 24 performance-related changes shipped, and the measured result across default themes was a small LCP regression of roughly 1.7–1.9% rather than an improvement. Core is not where your speed problem is. Your theme, your plugins and your host are.

---

The one thing that is new

WordPress 6.8 shipped speculative loading in core — the browser begins loading a page before the visitor has finished clicking on the link to it.

The default is deliberately cautious: prefetch mode with conservative eagerness, meaning "prefetching is triggered when a user starts to click on a link." WordPress chose it as "a reasonable starting point to enable speculative loading at the scale of WordPress" because it "minimizes the chance of any speculative loads without a subsequent navigation."

It is off for logged-in users and for sites without pretty permalinks, and URLs with query parameters are excluded automatically.

The caveat matters if you turn up the setting. In prerender mode, "even their client-side code will be loaded" — so analytics can fire for a page nobody visited unless the code checks whether it is being prerendered first.

---

Frequently asked questions

How do I speed up my WordPress site?
In order of payoff: fix server response time, add a page cache, fix the LCP image, audit plugin weight, reduce JavaScript, and stop layout shift. The first three account for most of the available improvement on a typical WordPress site.

What is a good PageSpeed score for WordPress?
The score is a lab diagnostic, not the assessment. What is assessed is Core Web Vitals from real visits: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, at the 75th percentile. A site can score highly in the lab and still fail that.

Are Core Web Vitals a ranking factor?
Google says Core Web Vitals align with what its core ranking systems seek to reward, and highly recommends achieving good scores, but publishes no weight. Treating speed as a tiebreaker between comparable pages rather than a lever on its own is the accurate model.

What is INP and what replaced FID?
Interaction to Next Paint measures responsiveness across all interactions on a page, and it replaced First Input Delay as a stable Core Web Vital in 2024. A guide still discussing FID predates the change.

Why is my WordPress site slow even with a caching plugin?
Usually server response time, an unoptimised LCP image, or plugin JavaScript. A page cache removes PHP and database work but does not shrink a two-megabyte hero image or stop a chat widget blocking the main thread.

How many plugins are too many for WordPress?
The count is the wrong measure. What matters is what they load on each request. Check Site Health's autoloaded options figure — WordPress advises keeping it under 800kb — and measure what each plugin adds to page weight and query count.

Does WordPress core slow my site down?
Rarely. WordPress's own 6.8 performance report measured a small LCP regression of about 1.7–1.9% across default themes despite 24 performance changes, which shows how little movement core accounts for. Themes, plugins and hosting are where site speed is decided.

What is speculative loading in WordPress 6.8?
Core support for the Speculation Rules API, which begins loading a page before the visitor finishes clicking. The default is prefetch with conservative eagerness, disabled for logged-in users and sites without pretty permalinks, with query-parameter URLs excluded automatically.

---

What to do next

Open Search Console's Core Web Vitals report and note which of the three metrics is failing, and on which template. That is your actual problem.

Then run PageSpeed Insights on one URL from that group and read the field data section rather than the score at the top. The lab diagnostics below it tell you what to change; the field data tells you whether it worked.

---

Related guides

• Core Web Vitals for WordPress — the three metrics and their WordPress causes
• WordPress caching explained — the four layers and what each one does
• How to audit your WordPress plugins — measuring what they cost
• Choosing WordPress hosting for speed — the decision framework
• Technical SEO: what actually needs fixing — where speed sits among the signals
• When WordPress breaks: a diagnostic order — when it is not slow but broken
• Image SEO beyond alt text — the search side of the same images