meo / auditRequest a walkthrough

Meo audit guides · Meo Advisors

Page Speed and Core Web Vitals: An Audit Guide

Read page-speed tests without confusing lab scores with real visits. Audit loading, responsiveness, and layout stability on business websites.

Published · Reviewed

Overview

A page speed audit examines how quickly useful content appears, how promptly a page responds, and whether its layout moves unexpectedly. Core Web Vitals describe these experiences. Read controlled lab tests alongside available real-user data, and identify the page, device conditions, and collection period before deciding what needs fixing.

Review the pages where decisions happen

Your homepage is a useful starting point, but it may not represent a service page, location page, or booking destination. Different templates can load different images, scripts, and widgets. Build the test sample around the routes a prospective customer might use.

Keep mobile and desktop results separate. They describe different conditions, and your team needs to know which experience the recommendation addresses. Avoid choosing whichever result gives the more flattering headline.

Also distinguish an unavailable test from a slow page. A timeout, blocked request, or missing dataset needs a source-specific explanation. It is not a valid basis for assigning a measured loading time.

Largest Contentful Paint: when the main content appears

Largest Contentful Paint, or LCP, measures when the largest eligible image or text block becomes visible. It helps explain why a page might technically begin loading while still feeling empty. The relevant element may be a prominent image or a large text block.

Investigate the element identified in the report before changing every image. Google's LCP optimization guidance breaks the metric into server response, resource discovery, loading, and rendering delays. Compressing an image addresses only part of that chain. Sources: [1] optimize-lcp

Interaction to Next Paint: how the page responds

Interaction to Next Paint, or INP, concerns responsiveness after interactions. A menu can appear ready while responding slowly when someone taps it. Review representative actions such as opening navigation, expanding service details, or interacting with a form.

A standard page-load lab run does not establish the INP of real visits. Total Blocking Time can help diagnose responsiveness problems in the lab, but it is a different metric. Keep its label intact rather than renaming it INP.

For fixes, look at the interaction involved and the work that delays the next visible update. Google's INP guidance discusses input delay, processing, and presentation. Removing a script without understanding its role could also break a necessary contact route. Sources: [1] optimize-inp

Cumulative Layout Shift: whether the page stays put

Cumulative Layout Shift, or CLS, concerns unexpected movement. A visitor may aim for a contact button just as another element moves it. Review images, embedded content, banners, and late-loading components around the route.

Google's CLS guidance discusses reserving space and investigating common causes of shifts. The task should identify the moving element and the conditions that trigger it. A screenshot taken after loading can miss the behavior entirely. Sources: [1] optimize-cls

Some shifts happen later in a visit, so a clean initial test does not establish that the whole experience remains stable. Review the interaction state relevant to the reported problem.

What to check

Build a record your developer can reproduce:

  • Identify the exact URL, page type, and reason for testing it.
  • Save the test date, tool, and mobile or desktop strategy.
  • Separate lab diagnostics from field experience.
  • Identify whether field data applies to the URL or the wider origin.
  • Record the main content element behind the LCP result.
  • Review delayed responses on relevant interactions.
  • Keep Total Blocking Time distinct from INP.
  • Investigate unexpected movement near content and actions.
  • Check the role of large media and third-party components.
  • Repeat comparable tests when confirming a suspected cause.
  • Preserve necessary contact and booking behavior after changes.
  • Document missing data without assigning a fabricated result.

Treat tool recommendations as diagnostic leads. Ask which finding explains the observed delay and which change can be tested independently. A long list of potential savings is not an implementation order.

Use the published standards without confusing them with an audit grade

Google's published good-experience targets are LCP within 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1, assessed at the 75th percentile. These are Core Web Vitals standards, not a description of Meo's scoring thresholds. Source: web.dev Web Vitals. Sources: [1] web-vitals

The percentile describes a point in the distribution of recorded experiences. It is not an average, and it does not mean every visit performed that way. Keep the device segment attached to the result.

A pass is useful context, but it does not establish that the offer is clear or the booking route works. A speed audit supports the wider website review; it cannot replace it.

A Lighthouse score summarizes a lab run

Lighthouse combines performance metrics into a score. The score is not a time in seconds or a count of customers lost. Chrome documents the weighting and scoring approach in Lighthouse performance scoring. Sources: [1] lighthouse-scoring

Use the underlying diagnostics to decide what to fix. A score change can reflect test variability as well as a site change. Preserve the environment and compare similar runs before claiming an improvement.

Do not compare a desktop result for your site with a mobile result for a competitor. Likewise, a result from a different tool version or test environment deserves a methodological note before it becomes a ranking table.

Field data is a sample with eligibility rules

The Chrome UX Report, or CrUX, aggregates eligible real-user experiences. It does not represent every browser or every visitor. Google explains participation and page eligibility in CrUX methodology. Sources: [1] crux-methodology

Field reporting can use a trailing 28-day period. A change made today will therefore coexist with earlier experiences until the collection window moves forward. Check the actual source period rather than expecting an immediate clean comparison. Source: About PageSpeed Insights. Sources: [1] pagespeed-insights

If the tested URL lacks field data, an origin result may provide broader context. Label it as origin-level evidence. It cannot establish how that particular service page performed, and no field result is not proof of a bad experience.

Turn diagnostics into a bounded repair

If the image is needlessly large, prepare an appropriately sized version and preserve the intended dimensions. If a widget delays useful content, ask whether it must load immediately. Confirm its business purpose before deferring or removing it.

Give the task a completion condition: the intended content loads correctly, the relevant metric improves under comparable lab conditions, and the contact route still works. Monitor available field evidence afterward without promising an outcome before the data exists.

A shared page component can make a repair reusable. Record the templates affected and check examples of each. An improvement on the homepage does not automatically establish that a separate booking application improved too.

Common mistakes: chasing a perfect score at any cost

A score is a diagnostic summary. Removing necessary functionality to improve it can harm the visitor's task. Prioritize the bottleneck affecting useful content or interaction and verify the resulting experience.

Common mistakes: treating an estimated saving as guaranteed time recovered

Tool suggestions describe opportunities under particular assumptions. Dependencies can overlap, so adding every suggested saving together creates a misleading forecast. Confirm the actual change with comparable measurements.

Common mistakes: calling a lab result real-user performance

A simulated mobile test can reveal a problem worth fixing. Describe it as a lab observation. Avoid claims that all customers experienced that delay or that it caused a measured loss of enquiries.

Common mistakes: repeating tests until the best result appears

Selective reporting hides variability. Use a consistent testing approach and explain the observed range when it affects the conclusion. Investigate unstable results rather than choosing the greenest screenshot.

Common mistakes: ignoring the page after the main website

A fast service page can send visitors to a slow external booking destination. Identify the handoff and describe which part of the route was tested. Do not extend a website result to an untested third-party experience.

How the free Meo audit checks this

The free Meo audit uses available mobile lab measurements and field context alongside public technical checks. PageSpeed Insights is the primary lab source, with DataForSEO Lighthouse as a bounded fallback when available. Field evidence is used only with matching URL or origin scope and its stated period.

The scored speed checks cover mobile lab performance, LCP and CLS. INP is useful field context, not a scored INP check in scoring/v1; a page-load lab result and Total Blocking Time never substitute for a measured INP. Missing field data remains unavailable, and a single tested page cannot establish performance across the whole site. See the methodology for the scoring rules.

The full report by email adds broader page and template investigation, deeper experience review where available and prioritized repairs. Your team can verify changes through comparable tests and later field reporting. The request asks for email and phone; automated calls and texts are optional.

Frequently asked questions

Is page speed the same as Core Web Vitals?

Page speed is a broader topic covering loading and performance diagnostics. Core Web Vitals describe specific aspects of loading, responsiveness, and visual stability. Use the metric names rather than treating every performance result as the same kind of speed score.

Why do mobile and desktop results differ?

They represent different test strategies or visitor segments. Page layout, processing demands, and network conditions can affect the experience. Keep both results attached to their conditions instead of averaging them into a number that describes neither clearly.

Why is there no real-user result for your page?

CrUX has eligibility and popularity requirements. Missing field data can reflect those limits. Use available lab diagnostics to investigate the page while labeling the missing field evidence accurately. Do not replace it with a made-up estimate of real-user performance.

Will improving speed guarantee more leads?

No. Speed is part of the experience, alongside the offer, relevance, contact route, and demand. Validate the technical improvement first. Evaluate business outcomes separately with reliable definitions and comparable traffic rather than applying an assumed conversion lift.

Should you replace your website platform?

Establish the cause before considering a migration. Images, templates, scripts, delivery settings, and external widgets can each contribute to delays. A specific repair may address the measured bottleneck without the cost and disruption of a platform change.

Sources and review dates