A practical website speed audit for European small businesses

Choose three to five representative URLs before opening a testing tool. Include the home page, a key service or product page, and the page where a visitor contacts, books, requests a quote, or starts checkout. If the business serves several European markets, include at least one translated page because fonts, images, consent tools, and third-party widgets can differ by language.

Run the check on mobile and desktop, but start with mobile. Test the published URL in a private browser window and also try it on an ordinary phone, using the type of connection a customer might have away from reliable Wi-Fi. Write down what feels slow, what moves unexpectedly, and which tap or click takes too long to respond.

PageSpeed Insights shows two useful views. Chrome UX Report data describes aggregated experiences from eligible Chrome users in the field. Lighthouse runs a controlled lab test and suggests possible causes. Field data tells you what has happened to real visitors; lab data gives you a repeatable place to investigate and compare changes.

A smaller website may show no URL-level field data because Chrome only includes pages and sites that meet its discoverability and popularity requirements. That is not a failure and it does not mean nobody visited. Use the lab results as a starting point, check the page on real devices, and avoid presenting one automated run as a complete picture.

Largest Contentful Paint, or LCP, asks when the main visible content appears. Google defines a good result as 2.5 seconds or less. Interaction to Next Paint, or INP, looks at responsiveness after a person interacts; the good threshold is 200 milliseconds or less. Cumulative Layout Shift, or CLS, measures unexpected movement, with 0.1 or less considered good.

These thresholds are assessed at the 75th percentile, separately for mobile and desktop, so they are intended to represent most visits rather than one unusually fast test. Use them as shared quality targets. Google recommends good Core Web Vitals for search success and user experience, but a green result is not a promise of rankings, enquiries, or sales.

Create a small table with one row per page and columns for mobile, desktop, LCP, INP, CLS, the main visible problem, and the next action. Run each URL in PageSpeed Insights, save the date, and take a screenshot or export so a later test can be compared with the same evidence.

Then complete the journey yourself. Do not stop at the performance score. A technically fast page can still hide the contact button, make a booking form awkward, or show a consent notice over the information a customer needs.

Start with an issue that affects an important page and has a clear fix. An oversized hero image may delay the main content. A booking, chat, map, review, advertising, or consent script may add work before the page responds. Missing image dimensions can allow the layout to move. Several font files or an autoplaying video can add weight without helping the next customer action.

Do not remove a tool simply because it appears in a report. Ask what business job it performs, when it needs to load, and whether a lighter option can do the same job. A reservation system may be essential; an unused tracking tag is not. This creates a practical priority order: customer blocker, easy improvement, useful redesign, and optional polish.

A useful brief names the page, observed problem, evidence, likely cause, desired outcome, owner, and retest method. For example: “On the mobile service page, the main photograph appears late. PageSpeed identifies it as the LCP element. Prepare a correctly sized modern image, keep the visual quality acceptable, publish it, and rerun the same URL.”

Avoid vague instructions such as “make the website faster” or “reach 100.” Lighthouse explains that scores can fluctuate with device, network, extensions, advertising, and other test conditions. Compare like with like, keep the business goal visible, and judge whether the experience became clearer as well as whether the measurement improved.

After a change, rerun the same URLs under similar conditions and repeat the real journey. Record before and after values, but also check the design, forms, analytics, consent controls, and translated pages. A performance change is not successful if it breaks something customers or the business rely on.

Repeat this short audit after a redesign, new booking tool, campaign landing page, major image update, or change of consent platform. For routine maintenance, a quarterly check of the most valuable pages is a reasonable starting rhythm for many small teams. Increase the frequency when the site changes often; reduce it when the site is stable and monitored.

Fix first what blocks a customer from seeing, trusting, or acting. Investigate next what affects many pages or keeps returning. Schedule improvements that need design or supplier coordination. Leave tiny score gains until they support a real customer or operating need.

That rule keeps a performance audit useful for the business. Core Web Vitals provide common language and evidence, while the customer journey decides the order of work.