Website speed for non-technical owners: what to check, what to ask

I do not think a business owner needs to understand every technical term in a speed report. You do need to know whether people can read your pages, use the navigation and send an enquiry without waiting through an awkward experience.

That is where I would start. A performance score can help diagnose a problem, but it is not the same thing as a usable website. The aim is to make important tasks feel responsive, then use technical evidence to decide what needs attention.

Check the pages that matter to enquiries

Open your homepage, a main service page and your contact or booking page on a phone. Use mobile data as well as your usual connection. Try to read the opening sentence, open the menu and complete the main action.

I would make a short note of what happens rather than simply writing that the site feels slow. Does the headline appear late? Does a picture push the button down after you start reading? Does tapping the booking link seem to do nothing?

Repeat the check before drawing conclusions. Connection conditions, device performance and services outside your website can affect a single visit. A recurring problem is more useful to investigate than one unexplained pause on one phone.

Use a report to ask better questions

Google PageSpeed Insights is a useful starting point for checking a public page. Enter the actual page address, not just the homepage, and look at the mobile results as well as desktop.

The report can include field data from real visits when enough data is available, alongside a simulated lab test. Those are different views of performance. Field data describes a reporting period, while a lab test checks particular conditions at a particular moment.

If real visitor data is missing, that does not prove the site is fast or slow. I would ask whoever manages the website to explain what evidence is available and what the test can reasonably tell us.

Understand three useful measurements

Largest Contentful Paint, or LCP, concerns how quickly the largest visible content element appears. A large opening image can be involved, but it is not always the cause. Ask which element was measured before agreeing to remove anything.

Interaction to Next Paint, or INP, concerns responsiveness to user interactions. If a menu or button reacts slowly, scripts doing too much work may be part of the explanation. A technician should investigate rather than assuming every delay has the same cause.

Cumulative Layout Shift, or CLS, concerns unexpected movement on the page. I notice this when a button moves as I try to tap it. Reserving space for images or embedded content can help, depending on what is causing the movement.

Look for heavy content before blaming everything

I would ask about oversized images, autoplay video, font loading and third party scripts early in the review. These are sensible places to investigate, not a diagnosis made from the appearance of your homepage.

Images should be appropriately sized for where they appear. An enormous source image squeezed into a small card may be wasteful. Ask whether image dimensions, compression and delivery formats suit the design, including larger and smaller screens.

For scripts, make a list of what each one does and who uses it. Old tracking tools, duplicate widgets and abandoned integrations deserve scrutiny. Do not remove an unfamiliar script blindly: it might support consent settings, booking or another necessary function.

Ask for a proposed fix, not a magic score

Before approving work, I would request a plain language explanation of the problem, the affected pages and the recommended change. Ask what evidence points to that cause and how the result will be checked.

A useful proposal also names tradeoffs. Removing a video may change the presentation. Delaying an embedded booking tool may change how the booking step appears. You should understand those consequences before someone changes the experience your customers use.

I would avoid making a perfect score the only acceptance condition. Agree on the specific issue to improve, repeatable test conditions and checks that the site still works. A better score is not much comfort if the enquiry form stops sending messages.

Retest the whole route after changes

Check the same pages on comparable devices and connections after the work. Keep the before and after notes together. If field data is available, remember it will not instantly reflect a change made this morning.

Test menus, consent controls, forms and booking steps as well as page loading. A speed change can affect when interactive features become available. Make sure the page remains understandable while images or external tools are still loading.

I would also review the content around the next step. A fast form can still be confusing, so pair this check with the advice on better enquiry and booking forms.

What to do this week

• Test three important pages on a phone using mobile data.
• Record specific delays, movements or unresponsive controls.
• Run PageSpeed Insights for each page and save the results.
• Ask which issues have evidence behind them.
• Agree on a focused change and a way to verify it.
• Retest the complete enquiry or booking journey afterward.

My aim would be a short, prioritised list rather than a frightening technical audit. Fix the problem that obstructs a useful task, check the result and keep a record. That gives you a practical basis for the next decision without requiring you to become the developer.