Practical checklist
Five checks to start with
- Select representative homepage, service and product templates.
- Record the task affected by loading, response or layout movement.
- Keep field data and lab results clearly labelled.
- Compare tests using the same conditions.
- Verify the enquiry and language-switching journeys after changes.
Start with the part of the journey that feels slow
“Make our website faster” can produce a long technical proposal without identifying the user problem. First name the task: reading the main offer, opening the navigation, filtering products or submitting an enquiry. Record whether the obstacle is a blank area, a delayed response or content moving under the pointer.
Choose representative templates. A homepage with video, a text-heavy service page and a product page with a gallery can behave differently. Testing only the homepage gives an incomplete picture of the journey an overseas buyer might follow after receiving a direct link.
Understand the three measures without chasing one score
Core Web Vitals cover loading, responsiveness and visual stability through LCP, INP and CLS. The current good thresholds are LCP at most 2.5 seconds, INP at most 200 milliseconds and CLS at most 0.1, assessed at the 75th percentile. These measure user experience; they are not a forecast of sales.
Translate a finding into a brief. If the main product image appears late, investigate that page’s loading sequence. If the menu reacts slowly, examine the interaction. If a contact button shifts when an image loads, ask what space should have been reserved. One overall score does not tell the team which of these experiences needs attention.
Separate a controlled test from real visitor data
A lab test runs under specified conditions; field data represents recorded visits. The results can differ because devices, networks, locations and behaviour differ. A small site may lack enough field data, so an absent assessment should be recorded as unavailable rather than assumed to pass.
Save the tool, date, URL, device setting and conditions for each test. Repeat a controlled measurement when results look inconsistent, but do not keep testing until the most flattering score appears. A brief should contain representative evidence and the limitation of that evidence.
Review the assets and features you actually need
List the homepage video, large images, booking embed, chat widget and analytics tags with their business owners. Ask which are essential at first view and which can appear later. Do not remove a useful booking route solely to obtain a better score; discuss whether a lighter entry point can preserve its purpose.
For a Hong Kong firm serving overseas buyers, test from relevant locations where practical. A fast office connection may hide an experience problem. A focused initial task might be resizing one oversized hero image or delaying an optional media gallery, then checking the same service journey again.
Define acceptance around evidence and usability
Ask for a before-and-after report under the same test setup, a list of changed assets and confirmation that forms, navigation and language switching still work. If a shared template changed, test another page using that template. This catches improvements that accidentally damage content or controls elsewhere.
Keep a sensible performance budget in the publishing process. Before adding a large video or third-party tool, identify the owner and review its effect on the main task. Performance maintenance becomes easier when the team knows why each feature exists and what evidence would justify changing it.
Sources and scope
- web.dev: Core Web Vitalsweb.dev
Technical reference; examples and review procedures in this article are editorial recommendations.
- web.dev: Lab and field dataweb.dev
Technical reference; examples and review procedures in this article are editorial recommendations.