Start with the visitor’s journey
A mobile visitor may be opening your website from a message, comparing services on a commute or trying to send an enquiry with a weak connection. The useful question is whether they can understand the page and complete their task. A performance score can help find problems, but it is a starting point for investigation rather than the whole brief.
Choose a few representative journeys before changing the design: opening the homepage, reading a service, viewing a project and starting an enquiry. Check these on a real phone as well as in a browser test. Note what appears late, what jumps and what feels slow when touched. Those observations give the developer something specific to investigate.
Separate loading, responsiveness and stability
Core Web Vitals describe three different parts of the experience. Largest Contentful Paint (LCP) concerns loading the main visible content. Interaction to Next Paint (INP) concerns responsiveness to interactions. Cumulative Layout Shift (CLS) concerns unexpected movement of the layout. Treating all three as a generic speed problem can lead to the wrong fix.
A headline that arrives late, a menu that responds slowly and a button that moves under a visitor’s finger need different investigations. Ask for the measured problem, the affected page and the proposed change together. That keeps the performance work tied to a visible improvement.
Record the conditions behind the number
Repeat a test with the same URL, device profile and network settings when comparing a change. A single run can be influenced by the test environment. Field measurements describe actual visitor experiences; a controlled lab run is useful for reproducing and investigating a problem. Keep those two types of evidence separate in a report.
A newer website may not yet have enough field data for a useful report. That does not prevent testing its important journeys. Record the test setup and the observed limitations so the next review can compare like with like. Avoid turning one good run into a promise about every visitor’s connection.
Choose changes that remove unnecessary work
Start with the resources needed for the first useful screen. Check whether an oversized image, a delayed font or decorative code is competing with the page’s main content. Below-the-fold features can often be loaded when needed, while the text, navigation and primary action should be available promptly.
An animated brand does not require every effect to run on every device. Decide which movement communicates something and which only adds atmosphere. Keep the useful interaction, reduce expensive decoration where appropriate and provide a reduced-motion experience. Review the result visually; removing weight should still leave a deliberate design.
Reserve space for images and other arriving content so the surrounding layout has a stable place to settle. When investigating a slow interaction, measure the actual action rather than assuming that changing image formats will solve it.
- Check the first visible content and its resource requests.
- Use appropriately sized images for the screen that receives them.
- Load optional features when they are needed.
- Keep menus, forms and primary actions responsive.
- Review layout stability and reduced-motion behavior.
Retest the experience after the optimization
After a change, repeat the original journeys. Confirm that menus still open, forms still provide feedback and scroll sequences still release correctly. Check a narrow screen, a longer page and direct visits to internal URLs. A faster first screen is only useful if the rest of the website remains usable.
A useful handover includes the initial observation, the change made, comparable measurements and any remaining limitation. Continue reviewing real visitor data when it becomes available. For a new build, agree this performance review as part of acceptance rather than leaving it as an undefined task after launch.