Improve mobile website speed: turn a PageSpeed report into specific work

Choose a page and a visitor journey

Start with an important service or product page. Write down what should happen on a phone: read an offer, choose a variant or submit an enquiry. Record the address, date, test device and baseline. A fast homepage does not automatically tell you how the form or a detailed product view behaves.

• ›Exact URL and language.
• ›Important action leading to the next step.
• ›Test conditions and date.
• ›Observed waiting or movement in the layout.
• ›Owner for investigation and implementation.

Separate field measurements from lab tests

PageSpeed Insights combines real-user data with a controlled Lighthouse test. Missing field data can reflect insufficient samples; it does not automatically mean the page is fast or slow. Also check whether the displayed data covers one URL or the whole origin.

Our proposal is to save the report and describe the observed problem in one sentence. Compare later under reasonably similar conditions. One better test run is not proof that every visitor now has a better experience.

Translate the three core metrics into questions

LCP describes loading of the largest relevant content element, INP responsiveness to interactions and CLS unexpected layout movement. Google's good targets are LCP within 2.5 seconds, INP within 200 milliseconds and CLS at most 0.1, evaluated at the 75th percentile of visits.

In a working discussion, we translate that into three questions: when is the important content visible, how does the page respond to input and do text and controls stay reliably positioned? That avoids treating smaller images as the answer to every problem.

Locate the cause before choosing a fix

Google's LCP guide distinguishes server response, resource discovery, transfer and rendering. For INP, work on the main thread can delay responsiveness. Ask for the actual constraint to be identified before accepting a plugin or complete redesign as the proposed answer.

Our implementation brief contains the finding, suspected cause, proposed change and functional risk. For example, important content might appear late. The proposal should explain why that specific content will become visible earlier rather than promising general optimisation.

Check functions after the change

Alongside another measurement, test navigation, language switching, product choice and the form. A faster first screen does little good if the enquiry then fails. Record the implemented change separately from observed outcomes. Review real-user data again when an appropriate observation period is available and document remaining uncertainty.