Try a smaller photo file
The download takes 3.4 of the 4.3 seconds. Start with a compressed copy of this photo. Leave cache and plugin settings alone so you can tell what helped.
WordPress first fixes
WordPress Core Web Vitals first fixes
Start with the WordPress fixes that explain most first audits: page cache, hero image delivery, plugin scripts, theme weight, and third-party code.
No signup needed. Takes about 30 seconds.
Practical sequence
Label the source, pick the owner, rerun the same check.
1
Label field data, lab data, or missing data
Owner: SEO or developer
2
Confirm page caching for public pages
Owner: Developer or host
3
Inspect the LCP element and hero media
Owner: Content or theme owner
What to check first
Fix what the platform evidence actually supports.
WordPress can be fast, but every site has its own host, theme, builder, plugin stack, cache layer, and content model. The first fix should match the bottleneck instead of stacking optimization plugins blindly.
Label field data, lab data, or missing data
SEO or developerDo not treat one Lighthouse score as the whole truth. Check whether CrUX field data exists, whether Search Console groups the URL, and what the lab run is diagnosing.
Confirm page caching for public pages
Developer or hostFor mostly static pages, confirm a page cache or host cache is serving HTML without breaking logged-in, cart, form, or personalized flows.
Inspect the LCP element and hero media
Content or theme ownerFind the main image, heading, video poster, or first content block. Check file size, dimensions, loading priority, and whether lazy loading is delaying above-the-fold content.
Review plugin and builder scripts
Site ownerList scripts loaded by page builders, forms, analytics, popups, sliders, reviews, ads, and chat. Remove, delay, or scope low-value scripts only after confirming ownership.
Rerun and compare the same source
SEO or developerRerun the same lab check after deploy and compare the metric that failed first. Let CrUX field data catch up before calling a field failure fixed.
Worked example — not measured results
Your main photo is slow. What should you change first?
Imagine a mobile test of a WordPress homepage. The main photo takes 4.3 seconds to appear. This is Largest Contentful Paint (LCP): when the largest visible image or text block appears, not when the whole page finishes loading.
Most of the wait is the photo download
All numbers are made up · Mobile simulated test · Real-user data unavailable
- Page starts arriving
- 0.5 s
- Wait to start photo
- 0.1 s
- Download photo
- 3.4 s
- Show photo
- 0.3 s
Keep the original
Ask the person who edits page images, or your theme developer, to upload a smaller copy and try it on a test version of the page. Keep the crop and layout the same. Keep the old file so you can switch back.
Repeat the same test
Run three mobile tests before and three after, using the same page, tool, and settings. Look for the photo appearing sooner. Check phone and desktop. Switch back if the image or page looks wrong or something breaks.
This is only the first thing to try. If your test shows a different delay, start there instead. A faster simulated test does not prove real visitors’ experience has improved or that every Core Web Vitals check passes. There is no after-test result in this example.
What if the first change does not help?
If the smaller photo downloads faster but appears no sooner, check where the wait now goes. Other page code may still hold it back. Ask a developer rather than stacking more changes.
If the page starts arriving late, ask your host or developer about the server and public-page caching. If the photo starts downloading late, check how it is loaded. If taps freeze after the page appears, inspect plugin or other page-code work. Do not disable every plugin or use blanket cache rules for carts and accounts.
For rechecks, save dates and compare the middle result of each set of three. Keep the exact page address, device, and settings the same. Keep location and cache conditions the same where you control them. If you use a test copy, measure both before and after on that copy.
Method: Google’s guide to improving LCP. Example numbers are illustrative, not customer results.
Source caveats
Avoid generic fixes that do not match WordPress.
The right next step depends on the source label, the page type, and who owns the change.
The WordPress performance handbook describes caching as the fastest way to improve performance for many WordPress sites, but cache changes still need site-specific validation.
The WordPress Performance Lab plugin is a collection of performance feature projects, not a blanket guarantee that a site will pass Core Web Vitals.
Do not combine multiple cache, minify, image, and script-delay plugins without checking conflicts and rollback paths.
WooCommerce, membership, learning, form, and logged-in flows can need different cache rules than static marketing pages.
Use nimo
Turn the checklist into a clear next step.
Run the audit, keep field and lab labels separate, assign the next step, and rerun the same check after the change.
Sources checked
Checked on May 20, 2026. Recheck official docs before adding platform feature, quota, or guarantee claims.
Check the page before changing another setting.
A focused audit tells you whether to start with field data, lab diagnostics, platform settings, or a narrower owner handoff.
No signup needed. Takes about 30 seconds.