Website stewardship guide 08
A useful speed review starts with what feels slow: the main content appearing, a menu responding, or a booking form becoming usable. Measure representative pages, find the cause, and check that the repair improves the experience customers actually have.
← All website stewardship guidanceChoose key pages
Read the evidence
Find the cause
Test a repair
Watch for slowdowns
Why this matters
A page may be quick on your office computer and awkward on a customer's phone. Large images, delayed scripts, moving controls, and outside widgets can affect different parts of the experience. Identify the task and conditions before deciding what needs to change.
Field data summarizes real visits, collected by Google from Chrome users. Lab tests run under controlled conditions and help a developer find causes. Both are useful, but they answer different questions. If Google has no real-visitor data for your site, that isn't a failing grade.
Responsible practices
Include a service page, contact page, and any important campaign or booking page alongside the home page. Test realistic images and third-party tools. A repeat visit with cached files can feel different from a first visit, so record which experience you are measuring.
Core Web Vitals are Google's three measures of page experience. Largest Contentful Paint (LCP) is how fast the main content appears. Interaction to Next Paint (INP) is how quickly the page responds to taps and clicks. Cumulative Layout Shift (CLS) is how much the layout jumps. Good targets are LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less, met by at least 75% of visits, separately on mobile and desktop. They describe experience; still check the actual task.
Ask whether the report covers one page or the wider site, which devices it represents, and what period it describes. Compare repeated lab runs under the same settings. A lab score recorded today will not instantly replace a field report describing earlier visits. If field data is unavailable, use repeatable tests and representative real-device checks.
The developer should identify what is delaying or shifting the page. A large hero image, slow server response, heavy script, and unstable embed need different repairs. Ask for a plain explanation of the bottleneck, the proposed change, and the customer task that should improve.
A performance budget is a set of limits or targets used to catch a slower release. It might cover image size, script weight, or a measured interaction. Agree the targets with your provider and review new widgets, video, fonts, and tracking against them. Verify that speed changes preserve accessibility, content, privacy controls, and working forms.
Worked example
Hypothetical example: a mobile test finds that the main image appears late. There is not enough page-level field data to describe real visitors reliably.
A useful report connects an observed delay to a repair and a retest. It should also state what the available data cannot establish.
Page speed
Note the page, device, and task when something feels slow.
Choose a small set of important pages for regular comparison.
Ask the provider to explain the first proposed repair and how it will be measured.
Review the cost of new widgets or media before adding them to every page.
Separate field data from lab tests and record the pages, devices, test settings, and comparison period.
Use browser performance traces to find the cause, then retest under the same conditions.
Apply agreed performance budgets and watch for regressions after content, software, or third-party changes.
Avoid these failures
Good website care lowers risk, but no provider can guarantee uninterrupted service.
Questions business owners ask
LCP describes when the main content appears, INP describes responsiveness to interaction, and CLS measures unexpected visual movement. Use them with checks of the task a customer is trying to complete.
They represent different conditions and samples. Field data summarizes actual visits over a period; a lab run uses controlled settings. Check the URL scope, device, dates, and test configuration before comparing them.
Small sites often have too few visits for Google to report real-visitor data. That isn't a failing grade. Use repeatable lab tests and checks on real phones instead.
No. Prioritize the tasks customers complete and the causes of a poor experience. A perfect lab score is not the goal, and chasing it should not break important content or functions.
Primary guidance
Plan the next step