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

By Greg Nowak. A WordPress PageSpeed report can leave you with twenty recommendations and no clear decision. Meanwhile, visitors are waiting for a service page, struggling with a menu, or trying to send an enquiry. The useful question is: which change will make those journeys better, and how will you prove it worked?

Start with the pages that support enquiries, sales, and active campaigns. Establish what is slow, find the cause, and make a small set of changes you can verify. That gives owners a sensible spending decision and agencies a brief they can deliver.

Choose the pages before choosing the fixes

Build a benchmark set: a main service page, a campaign landing page, an article, and a product or enquiry journey. Include different templates. Test mobile first if that reflects your audience, but check desktop too.

For each URL, save the date, report, visible problem, and Largest Contentful Paint element. Repeat lab tests under comparable conditions rather than treating one run as a baseline. Also try the page on a phone: open the menu, accept or reject cookies, and submit a test enquiry.

Prioritise by business importance, how many pages share the problem, confidence in the diagnosis, and implementation effort. A shared template fix deserves attention when it improves several important journeys. A small warning on a rarely visited page can wait.

Separate the PageSpeed score from real visitor experience

PageSpeed Insights combines a Lighthouse lab test with Chrome user experience data covering the previous 28 days. The lab test helps diagnose the current page. Field data shows how visitors experienced it over time, including visits before your latest release.

Check whether the field report covers “This URL” or the whole origin. An origin result is broader evidence, not proof that every page has the same issue. Missing field data usually means insufficient samples; it does not establish that performance is good or bad.

The Core Web Vitals targets are LCP within 2.5 seconds, Interaction to Next Paint (INP) within 200 milliseconds, and Cumulative Layout Shift (CLS) at 0.1 or less, assessed at the 75th percentile and separately for mobile and desktop. Lighthouse’s standard page-load test does not measure INP. Total Blocking Time is a diagnostic clue, so test interactions as well.

Let the symptom set the order of work

Make the main content available earlier

If LCP is an image, check when the browser discovers it before compressing the entire media library. Its real src or srcset should be available in the initial HTML. Do not lazy-load the LCP image. Google’s LCP optimisation guidance also recommends high fetch priority for the likely LCP image:

<img src="/images/service-hero.webp" width="1600" height="900" fetchpriority="high" alt="Team reviewing a project plan">

This is a template example. Check what WordPress and your theme already output before changing attributes. Use suitable responsive image sizes and reserve the image’s space. Keep high priority selective. For a CSS background, a targeted preload can help discovery; for text LCP, investigate server response, blocking CSS, and fonts. Verify the loading timeline after the change.

Reduce script work and stop content jumping

List scripts from the theme, builder addons, forms, analytics, consent tools, and chat. Give each an owner and a purpose. Remove unused features, restrict page-specific assets to the pages that need them, and investigate expensive work around slow interactions.

Change one group at a time. Blanket script delays need careful testing: a menu, consent control, or form may depend on the code being delayed. Check the full journey after each change, including validation messages, confirmation pages, and tracking behaviour.

For layout shifts, reserve space for images and embeds, inspect font swaps, and avoid inserting banners above content after it appears. Reproduce the point where the jump happens; the initial load may not reveal a shift triggered later.

Check caching before database housekeeping

For public pages, ask your host or developer to confirm that anonymous repeat requests reach the intended full-page cache. Test personalised pages, carts, and checkout separately, with appropriate exclusions.

WordPress distinguishes page caching from persistent object caching: the latter reduces repeated database work and requires supporting infrastructure. If uncached responses remain slow, profile PHP, plugins, and database queries before recommending a hosting upgrade.

Expired transients can be removed with the documented WP-CLI command, run against the intended WordPress installation:

wp transient delete --expired

Treat this as maintenance, with a current backup. Put it ahead of image or script work only when evidence points to database overhead.

Give the work an owner and a definition of done

Each ticket should contain affected URLs, the observed problem, supporting evidence, proposed change, owner, and acceptance checks. Agree which metric should improve and which business actions must still work.

Compare repeated lab tests after deployment, then watch field data over the following weeks. Keep the same benchmark pages for theme updates, plugin changes, and new marketing tags.

If you need help deciding what deserves budget first, Greg can review the evidence, agree priorities with your agency or host, and coordinate delivery. Talk to Greg about your WordPress performance plan.

Related on GrN.dk

• Critical CSS for Faster Pages: When It’s Worth the Work
• JavaScript-Heavy Service Pages Still Lose Leads: What to Audit in 2026
• Why Your Website’s Third-Party Stack Needs a Real Owner

Need help with this kind of work?

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

Sources

• About PageSpeed Insights — Google
• Web Vitals — web.dev
• Optimize Largest Contentful Paint — web.dev
• Optimization — WordPress Developer Resources
• wp transient delete — WP-CLI