Search Engine OptimizationWeb Development

Speed up a WordPress site in 2026: Core Web Vitals, INP and the fixes that matter

Updated 9 min readBy Sandeep Mahajan

Three orange ring gauges on a thin horizontal line on a dark navy background

To speed up a WordPress site in 2026, measure first with field data (Core Web Vitals in PageSpeed Insights or Search Console), then fix in this order: hosting and PHP version, full-page caching, images and the largest element above the fold, plugins and scripts that block interaction, and the database. Google's "good" thresholds are a Largest Contentful Paint of 2.5 seconds or less, an Interaction to Next Paint of 200 milliseconds or less and a Cumulative Layout Shift of 0.1 or less, at the 75th percentile of visits. If a site still fails after that, the cause is usually the theme or page builder, and the honest answer may be a rebuild.

Key takeaways

  • Core Web Vitals are LCP (loading), INP (responsiveness, which replaced First Input Delay in March 2024) and CLS (visual stability). A page passes when 75% of real visits meet all three.
  • Google says Core Web Vitals "are used by our ranking systems", but that good scores do not guarantee top rankings and that relevance comes first. Speed is a tiebreaker for search and a real factor for visitors.
  • HTTP Archive's 2025 Web Almanac found 45% of WordPress sites passed Core Web Vitals on mobile, among the lowest of the platforms it compared.
  • WordPress.org recommends PHP 8.3 or greater; old PHP versions are one of the cheapest problems to fix.
  • Recent WordPress releases already handle lazy-loading, image priority and speculative loading. Many "speed" plugins now duplicate core features.

How do you measure WordPress speed properly?

Use field data first and lab data second. PageSpeed Insights shows both: field data from the Chrome UX Report reflects real visitors "over the previous 28-day collection period", while lab data from Lighthouse is "a simulated load of a page on a single device and fixed set of network conditions", useful for debugging but not a verdict. Search Console's Core Web Vitals report groups your URLs by status using the same field data.

The thresholds, from web.dev:

Metric What it measures Good Needs improvement Poor
LCP When the main content has loaded 2.5 s or less up to 4 s over 4 s
INP How quickly the page responds to taps, clicks and keys 200 ms or less up to 500 ms over 500 ms
CLS How much the layout jumps 0.1 or less up to 0.25 over 0.25

Measure your home page, one typical post or service page, and your highest-value page (the contact form, the product page). A site with little traffic may have no field data; then use Lighthouse on mobile settings, run it three times and take the median.

Does page speed affect SEO?

Yes, but less than most speed-plugin marketing suggests. Google's page experience documentation says "Core Web Vitals are used by our ranking systems" and recommends good scores "for success with Search", then adds that good results in its reports do not guarantee top rankings, and that "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." Where many pages are equally helpful, a great page experience "can contribute to success in Search."

The stronger argument is visitors. A page whose main content arrives after several seconds, or whose buttons jump as ads and fonts load, loses people before they read the offer. That is why speed belongs in a conversion review as much as in SEO.

Which fixes make the biggest difference?

Work in this order. Each step removes a bottleneck the next one would hit.

1. Hosting and PHP

WordPress.org's requirements page recommends PHP "version 8.3 or greater" and MySQL 8.0 or MariaDB 10.11 or greater. Its optimisation handbook notes that "newer PHP versions will usually include better performance optimization" and points to OPcache. Ask your host which PHP version the site runs; an older site may still run a version that no longer receives security fixes. If the server is overloaded, no plugin will compensate.

2. Full-page caching and a CDN

The WordPress handbook calls caching plugins the quick win: they "cache your WordPress posts and pages as static files" so PHP and the database are not hit on every visit. Many managed hosts include server-level caching; use that instead of stacking a second caching plugin on top. A content delivery network serves those cached pages and your images from locations near the visitor; the handbook notes that "using a CDN can greatly reduce the load on your website."

3. Images and the LCP element

On most WordPress pages the LCP element is a hero image or a large heading. Make sure that image:

  • is resized for the space it fills and served in a modern format such as WebP or AVIF (the handbook recommends WebP);
  • is not lazy-loaded. Since WordPress 6.3, core adds fetchpriority="high" to the image it expects to be the LCP image and avoids lazy-loading images in the first viewport, but sliders, page builders and some optimisation plugins override this;
  • is not a CSS background inserted by a slider script, which the browser discovers late.

Give every image and embed explicit width and height so the layout does not shift, and reserve space for cookie banners and late-loading widgets: those are the usual CLS culprits.

4. Plugins, scripts and INP

INP measures the delay between a tap and the next visual update. web.dev breaks it into input delay, processing time and presentation delay; long JavaScript tasks on the main thread inflate the first two, and very large pages inflate the third. On WordPress the usual sources are page builders, sliders, chat widgets, multiple analytics and marketing tags, and plugins that load their scripts on every page.

The procedure: list your plugins, deactivate one at a time on a staging copy, and re-measure. The handbook's advice is direct: "deactivate and delete any unnecessary plugins." Load tags through one tag manager instead of hard-coding several, and delay chat and social widgets until the visitor interacts.

5. The database

Revisions, transients and options left behind by deleted plugins accumulate. The handbook recommends limiting post revisions, using InnoDB tables and keeping autoloaded options to roughly 800 KB or less. This matters most on sites whose pages cannot be fully cached, such as stores and membership sites.

What does WordPress core already do for speed?

More than in 2017, when the first version of this article was written. Core lazy-loads images and iframes below the fold, adds fetchpriority="high" to the likely LCP image (WordPress 6.3), and since WordPress 6.8 includes speculative loading, which prefetches pages a visitor is likely to open next using the browser's Speculation Rules API. The WordPress core team reported that sites using the earlier feature plugin improved their LCP pass rate by about 1.9% at the median. Before installing an "all-in-one" speed plugin, check whether it duplicates these features, and whether its own scripts make INP worse.

When is it time to stop tuning and rebuild?

When the theme or page builder is the bottleneck. The 2025 Web Almanac put WordPress's mobile Core Web Vitals pass rate at 45%, against 74% for Wix and 85% for Duda; the platform is capable of passing, but the typical stack of theme, builder and plugins is not. Signs that tuning has run out:

  • LCP stays poor on a cached page with optimised images, because the builder's CSS and scripts block rendering.
  • INP stays poor with every non-essential plugin removed.
  • The site runs on a theme or builder nobody dares to update.

For our own site, we stopped tuning. In October 2026 we moved impingesolutions.com from WordPress to a static Astro site on AWS. The old home page scored 44 in PageSpeed Insights on 10 October 2026 with a Largest Contentful Paint of 15.3 seconds (simulated mobile, lab data); the new home page scored 99 with a 2.0-second LCP (Lighthouse, simulated mobile, median of three runs, 13 October 2026, after an image optimisation pass). Those are our own site's numbers, not a promise for yours. The full write-up explains what we kept and what broke, and our comparison of WordPress, headless and static sites covers when staying on WordPress is the better choice.

Impinge Solutions tunes WordPress sites as part of its digital marketing and SEO service, and moves sites that have outgrown tuning through website modernisation. Contact us for a performance review.

FAQ

What are good Core Web Vitals scores?

Google's "good" thresholds are Largest Contentful Paint of 2.5 seconds or less, Interaction to Next Paint of 200 milliseconds or less and Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of real visits on mobile and desktop separately.

Why is my PageSpeed Insights score different every time?

The score is lab data from Lighthouse: a simulated load on one device and one network profile, which varies with server response and test conditions. Field data from real visitors over the previous 28 days is more stable and is what Core Web Vitals assessments use. Run lab tests several times and compare medians.

Will a caching plugin fix a slow WordPress site?

It fixes slow server response for pages that can be cached, which is often the biggest single gain. It does not fix oversized images, layout shifts or heavy scripts that slow interaction, and it helps less on carts, checkouts and logged-in pages.

What is INP and why did my site start failing it?

Interaction to Next Paint measures how quickly a page visually responds to taps, clicks and key presses. It replaced First Input Delay as a Core Web Vital in March 2024 and is stricter, because it looks at interactions throughout the visit, not only the first one. Heavy plugin and tag scripts are the usual cause on WordPress.

Is page speed a Google ranking factor?

Google says Core Web Vitals are used by its ranking systems, but that good scores do not guarantee top rankings and that it shows the most relevant content even when page experience is weaker. Treat speed as a tiebreaker for search and a direct factor for visitors and enquiries.

Which PHP version should WordPress run?

WordPress.org recommends PHP 8.3 or greater, with MySQL 8.0 or MariaDB 10.11 or greater. Test on a staging copy before upgrading, because old themes and plugins can break on newer PHP versions.

Sources (12 links)
Share this article