A green Lighthouse score and a failing Core Web Vitals assessment can describe the same WordPress page. They measure different things under different conditions. Treating them as interchangeable can send you toward the wrong repair.
Core Web Vitals currently cover loading, responsiveness, and visual stability through LCP, INP, and CLS. Other familiar measurements, including TTFB and TBT, help explain why those experiences are slow or unstable.
Use the field assessment to identify an affected experience. Then use a controlled test to investigate its cause. A number becomes useful when you can connect it with a page, an interaction, and a reproducible delay.
Read the three current thresholds correctly
Google’s Core Web Vitals framework assesses the 75th percentile, with mobile and desktop evaluated separately. At the good threshold, at least 75% of measured experiences meet that boundary.
| Metric | Experience measured | Good | Needs improvement | Poor |
|---|---|---|---|---|
| Largest Contentful Paint | Appearance of the largest eligible visible content element | 2.5 seconds or less | Above 2.5 through 4 seconds | Above 4 seconds |
| Interaction to Next Paint | Responsiveness from an interaction through the next paint | 200 ms or less | Above 200 through 500 ms | Above 500 ms |
| Cumulative Layout Shift | Unexpected visual movement | 0.1 or less | Above 0.1 through 0.25 | Above 0.25 |
CLS has no time unit. An INP of 300 ms and a CLS of 0.3 therefore describe entirely different problems.
Where sufficient data exists for all three, all three need good results to pass the assessment. A fast LCP does not cancel a poor INP. Keep the individual measurements visible when reporting progress.
There is also a reporting exception worth recognizing. PageSpeed Insights can assess LCP and CLS when INP has insufficient data. That result does not establish that unmeasured interactions are responsive.
Separate field evidence from a lab experiment
Field data describes observed visits. Lab data describes a controlled test with particular device, network, and execution settings. Both are useful, but they answer different questions.
PageSpeed Insights displays real-user information from the Chrome User Experience Report, or CrUX. This reflects a trailing 28-day collection period. Its lab section runs Lighthouse separately.
Check the field report’s scope before interpreting it. URL-level data describes that page when enough samples exist. Origin-level data combines eligible experiences across the site’s origin and can conceal differences between templates.
For example, an origin result cannot tell you whether a slow product gallery also affects plain blog posts. Select representative URLs from each page family. Record which reports have page data and which use the origin fallback.
No field data does not mean a pass or a failure. It means that dataset cannot provide the assessment. For lower-traffic sites, use repeatable lab tests and consider suitable real-user monitoring for additional evidence.
Also expect field results to respond gradually after deployment. Yesterday’s fix does not erase the earlier visits still included in the rolling collection window.
Lighthouse’s performance score combines several lab measurements using weighted scoring. It is not the percentage of visitors receiving a good experience. The archived screenshot below should be read as a lab result, not a current field assessment.
A navigation-only lab run also misses many later interactions. A visitor can encounter a slow filter, an expanding advertisement, or an expensive modal long after initial loading finishes.
Largest Contentful Paint: identify what appeared late
LCP records when the largest eligible content element in the viewport renders. On WordPress, that can be a featured image, product image, or text block. The relevant element may change with viewport size and page content.
Find the element in a performance recording before choosing a fix. An oversized hero image, a late-discovered background, and a heading waiting for a font require different investigations.
For an image, compare document arrival, request discovery, resource loading, and the remaining delay before painting. This prevents you from compressing a file when JavaScript is actually holding its container invisible.
Consider a product page where the image finishes loading at 1.8 seconds but appears at 3.2 seconds. Those illustrative timings point toward the remaining rendering delay. They do not prove that image compression is the next useful change.
Our WordPress LCP optimization guide walks through the breakdown and the corresponding fixes. Compare the same element under equivalent test conditions after each change.
Interaction to Next Paint: reproduce the delayed action
INP observes qualifying clicks, taps, and keyboard interactions during a page visit. It generally represents the slowest interaction, with an outlier allowance on visits containing many interactions.
Its duration includes input delay, event-handler processing, and the presentation delay before the next paint. That means a quick handler can still belong to a slow interaction. Work already occupying the main thread may delay its start.
INP measures the delay to the next paint, rather than the entire eventual business operation. For example, displaying immediate feedback while requesting search results can help responsiveness. The network request may still take longer to complete.
Keep that distinction visible in testing. A button that quickly shows a loading state may have good INP while the underlying service remains frustratingly slow. Measure the full operation separately when that delay affects the task.
For WordPress, reproduce actual controls: navigation menus, product variations, search suggestions, filters, and form validation. Use representative data rather than an empty demo page.
Record both the interaction and the surrounding main-thread work. If a delayed third-party script starts on the first tap, investigate whether it blocks the action itself. Our introduction to INP provides additional context for that shift toward whole-visit responsiveness.
Cumulative Layout Shift: find what moved and why
CLS measures unexpected layout movement using the largest qualifying burst of shifts. A burst has less than one second between shifts and lasts at most five seconds. It is not simply every movement added across the page’s lifetime.
Typical WordPress candidates include images without reserved space, inserted banners, changing font metrics, and expanding embedded content. Inspect the actual shift event before assigning responsibility. The element that moves may be a victim of another element expanding above it.
Suppose an article paragraph moves when a video player finishes initializing. Fixing that paragraph’s margin will not reserve the player’s missing space. Give the media container an appropriate aspect ratio and test its responsive states.
Some shifts closely following discrete user input are excluded from CLS. However, a delayed response can still cause an unexpected shift later. Reserve the intended space or present loading feedback before asynchronous content arrives.
Google’s CLS optimization guide explains these causes and repairs. Test the page beyond its first viewport, including scrolling, consent changes, advertisements, and expandable components.
When embeds are involved, our content performance audit helps identify repeated problems across articles. A template-level repair is more useful than correcting one instance while leaving the same embed pattern elsewhere.
Time to First Byte: investigate document delivery
TTFB measures the interval until the response’s first byte. It can include redirects, connection setup, and server-side response preparation. It is not a direct measurement of PHP execution alone.
Use it to decide where the loading investigation should start. If the HTML arrives late, resources discovered through that document also start later. But you still need to distinguish network conditions, cache behavior, and application work.
Compare equivalent cached and uncached requests where appropriate. On WordPress, anonymous articles and personalized account pages can follow different delivery paths. Do not use the fastest cached homepage response to represent every request.
Our explanation of TTFB’s effect on later loading follows those dependencies. For application-level evidence, continue with WordPress performance profiling.
First Contentful Paint: distinguish a first sign from the main content
FCP measures when the browser first renders qualifying content. That first content might be a logo or a small text element. It does not establish that the article, hero, or product information is ready.
Compare FCP with LCP to identify a useful gap. An early header followed by a long wait for the main image points toward later loading or rendering work. A late FCP suggests investigating the steps before any content becomes visible.
Use a filmstrip or recording to see what visitors received at each stage. A fast first paint containing only a sparse shell can still leave them waiting for the actual task.
Total Blocking Time: inspect loading-time main-thread work
TBT is a lab diagnostic that sums the blocking portions of long main-thread tasks. Only the portion above 50 ms contributes for each qualifying task. Its value depends on the test’s measurement window and conditions.
Use it to find JavaScript or rendering work that congests page loading. Then inspect the relevant tasks in a trace rather than guessing from the largest download.
A lower TBT can support a performance investigation, but it cannot certify good INP. The expensive interaction might happen after the loading test ends. Our TBT investigation guide connects loading traces with separate interaction tests.
First Input Delay: recognize an older assessment
FID measured the delay before processing the first interaction. INP replaced it as a Core Web Vital in 2024. INP includes more of the interaction and observes qualifying interactions throughout the visit.
Keep that change in mind when reading historical audits. A passing FID result cannot establish that the site’s current interactions meet INP’s threshold. Preserve the old measurement as historical evidence, then evaluate responsiveness with the current metric.
Time to Interactive: interpret legacy Lighthouse reports
TTI attempted to identify when a page became reliably interactive during loading. Lighthouse removed it from the performance score in Lighthouse 10. It was overly sensitive to outlier network requests and long tasks.
It can still appear in historical reports and explanations of TBT’s measurement window. Do not make an old TTI value the acceptance criterion for a current WordPress optimization project. Test loading behavior and the relevant interactions directly.
Resolve conflicting reports with a specific experiment
Consider this hypothetical product-page review. The figures are illustrative, not Scanfully customer measurements.
| Evidence | Result | What you can conclude |
|---|---|---|
| Mobile field LCP | 3.1 seconds | The measured population needs loading improvement |
| Mobile field INP | 340 ms | Qualifying interactions are too slow at the assessed percentile |
| Mobile field CLS | 0.04 | Visual stability meets the good threshold in this dataset |
| Desktop lab performance score | 98 | This particular desktop lab run performed well |
| Mobile variation-selector trace | Long task during selection | There is a reproducible interaction worth investigating |
The desktop result does not invalidate the mobile findings. Start by checking that the field data belongs to the intended URL or origin. Then reproduce the product interaction under representative mobile conditions.
Investigate the variation selector separately from the LCP resource. A shared script could affect both, but the numbers alone do not establish that connection. Keep each hypothesis tied to evidence from its own trace.
For an agency report, describe the affected template and visitor action alongside the metric. “Mobile product selection stalls during variation updates” gives a developer a reproducible problem. A score without that context gives them much less to investigate.
Decide what to fix and how to confirm it
Prioritize repeated problems on useful page families: product pages, lead forms, articles, and other routes your visitors rely on. Consider severity, affected traffic, and the effort needed to test a repair. Avoid spending a day polishing an isolated score while a common purchase interaction stalls.
Change one substantive cause at a time in staging. Save comparable traces and check related behavior before deploying. A layout repair should preserve usable content; a script-loading repair should preserve the first tap and keyboard interaction.
After deployment, use repeatable tests to detect immediate regressions. Then follow the field data over its collection period. If you use real-user monitoring, compare appropriate page and device groups rather than unrelated site-wide averages.
Record the deployment time and expected metric change alongside your WordPress activity timeline. That gives future investigations a concrete starting point when a template, plugin, or content edit changes the experience again.
Leave a Reply