WordPress PageSpeed: What to Fix First for Better Core Web Vitals

By Greg Nowak. Last updated 2026-07-14.

A fast WordPress site is an operating advantage, not a trophy score

A PageSpeed score is useful only when it helps you decide what to fix. For business owners, the real questions are whether priority pages load quickly, forms respond promptly, and releases stop reintroducing problems. Agencies need to separate template, plugin, hosting, and third-party issues before budget disappears into random optimisation work.

Start with pages that support enquiries, bookings, sales, or search traffic. Test one representative URL for each important template: a service page, campaign landing page, article, category page, and any form or product flow. A slow shared template can affect hundreds of URLs; fixing it is usually more valuable than polishing the homepage in isolation.

Read PageSpeed Insights without chasing the wrong number

PageSpeed Insights shows two forms of evidence. Lighthouse lab data is a controlled test of the URL now, so it helps diagnose a release. Field data comes from real Chrome users over a trailing 28-day period. It can lag behind a fix, fall back from URL to origin-level data, or be unavailable when traffic is too low.

Core Web Vitals are assessed at the 75th percentile. The current “good” limits are LCP at 2.5 seconds or less, INP at 200 milliseconds or less, and CLS at 0.1 or less. Lighthouse cannot directly measure INP because a synthetic load has no real interaction; use Total Blocking Time as a lab clue, then confirm INP in field data. Run mobile tests, compare the same URLs under similar conditions, and trust repeated evidence over one unusually good or bad run.

What you see	Likely first suspect	First practical move
Poor LCP	Hero image, slow HTML, or render-blocking CSS	Identify the LCP element and inspect when it is discovered, downloaded, and rendered
Poor INP or high lab TBT	Long JavaScript tasks and third-party tools	Remove, defer, or conditionally load scripts before adding more optimisation plugins
Poor CLS	Images, embeds, banners, or fonts without reserved space	Set dimensions and reserve layout space before content arrives
Slow TTFB	Missing page cache, slow PHP, database work, or hosting limits	Verify cache behaviour, then profile server-side work on an uncached request

A triage matrix for choosing the first investigation, not a substitute for measuring the affected template.

Fix the largest visible bottleneck first

On many WordPress sites, the LCP element is the hero image or heading. Make the hero image discoverable in the initial HTML, with a real src or srcset. Do not lazy-load it. If it is likely to be the LCP element, give it high fetch priority and include intrinsic dimensions:

<img src="/images/service-hero.webp"
     srcset="/images/service-hero-800.webp 800w, /images/service-hero.webp 1600w"
     sizes="100vw" width="1600" height="900"
     fetchpriority="high" alt="Team reviewing a WordPress performance report">

If the LCP image is hidden in a CSS background or otherwise missing from the initial HTML, preload that specific asset:

<link rel="preload" as="image" href="/images/service-hero.webp"
      type="image/webp" fetchpriority="high">

Preload is targeted, not a setting for every image. Competing high-priority resources can cancel the benefit. Compress and resize the asset, but also check the network waterfall: a small image discovered late can still produce poor LCP.

For CLS, add width and height to images, reserve space for embeds and consent banners, and avoid inserting notices above content after rendering begins. For fonts, use a sensible fallback and load only the weights the design needs.

Treat scripts and page builders as a portfolio

A visually simple Elementor or block-editor page can still load assets from the theme, builder addons, forms, chat, reviews, analytics, consent software, heatmaps, and tag management. Inventory requests by owner and page. Ask what must run before the visitor can read or act, what can wait, and what belongs only on selected templates.

Removal usually beats minification. Disable unused widgets and animation libraries, unload page-specific assets where the implementation permits it, and delay non-essential integrations without breaking consent or attribution. Test menus, forms, filters, and checkout steps after each change; INP problems often live in interactions that a load-only score cannot reproduce.

Use caching in the right order

For a mostly public WordPress site, verify full-page caching first. Confirm that anonymous repeat requests reach the intended cache layer, while logged-in, personalised, cart, and checkout responses follow the right exclusions. Persistent object caching is different: it helps database-heavy or dynamic requests by reusing results across requests, but it requires a cache service and plugin supported by the host.

A CDN can shorten delivery for distributed visitors and static media, and some services provide full-page edge caching. It will not repair a theme that generates slow HTML or ships excessive JavaScript. Diagnose origin and browser work before treating a CDN as the answer.

Keep database cleanup in the maintenance lane

Expired transients and table maintenance are legitimate housekeeping, especially on an older installation, but they rarely fix image-led LCP or script-led INP. Back up first, use staging where practical, and run database work in an appropriate maintenance window:

wp transient delete --expired
wp db optimize
wp cache flush

The first command removes expired transients; the second runs database optimisation through WP-CLI's database tooling. The cache flush is deliberately last because it clears the object cache. On WordPress multisite with persistent object caching, it will typically flush the cache for all sites and can cause a production performance hit. Use it for a known reason, not as a ritual.

Make performance part of release ownership

Keep a small benchmark set of business-critical URLs and check it after theme changes, plugin updates, new tracking, or hosting moves. Record the LCP element, major script owners, cache status, and mobile lab results before and after release. Then watch field data over the following weeks; a green lab run on launch day is evidence of a good build, not proof of the real-user outcome.

Give every new plugin or third-party widget an owner, a business purpose, and a defined set of pages. That discipline prevents a performance project from becoming a recurring cleanup exercise.

If you need someone to turn mixed PageSpeed reports, hosting advice, and agency constraints into an ordered delivery plan, Greg can review the stack, identify the highest-value fixes, and coordinate the work with your developers and marketing team. Talk to Greg about a practical WordPress performance plan.

Related on GrN.dk

Need help with this kind of work?

Talk to Greg about WordPress performance Get in touch with Greg.

Sources

Last modified

2026-08-12