Your website is slow: what actually matters

Open your homepage and a main service or product page on your phone. Try mobile data as well as Wi-Fi. Notice when useful content appears, whether buttons respond and whether anything moves just as you try to tap it. Test the contact or booking route too, including any separate booking website.

Write down the page address and what went wrong. One slow visit can be a network or device problem, so repeat it before drawing conclusions. A short screen recording can help your web person reproduce a problem, but remove customer information before sharing it.

The service page shows its text promptly, but the booking button moves down when a large photo appears. That is a layout problem worth fixing, even if the overall speed score looks reasonable.

Core Web Vitals are Google's measures of loading, responsiveness and visual stability. They do not tell you whether your prices are clear or your enquiry emails arrive. Each measure describes a different part of using the page.

For real-visitor data, Google checks the 75th percentile separately for mobile and desktop. In plain terms, at least three quarters of the recorded experiences need to meet each good threshold. All three measures must qualify for the Core Web Vitals assessment to pass.

• Largest Contentful Paint, or LCP, measures when the largest visible image or block of text appears. Google's good threshold is 2.5 seconds or less. It is not the time taken to download every part of the page.
• Interaction to Next Paint, or INP, measures how long the page takes to show a visual response after interactions such as taps, clicks or keyboard input. A good result is 200 milliseconds or less. It does not measure how long a booking takes to complete on the server.
• Cumulative Layout Shift, or CLS, measures unexpected movement of content. A good result is 0.1 or less. This is a score, not a time in seconds. Photos appearing without reserved space are a common cause.

Go to pagespeed.web.dev, enter the full page address and select Analyse. Start with the mobile result, then check desktop. Repeat for a main service page and your contact or booking page. A homepage result does not describe every page on the website.

The real-user section uses experiences recorded from eligible Chrome visitors over the previous 28 days. Check whether the report is showing your exact URL or the wider website, called the origin. A quieter or newer site may not have enough data for either. Missing data does not mean the website passed or failed.

The diagnostic section uses Lighthouse, an automated test under simulated conditions. This is lab data. It helps find causes, but its performance score is not the same as the real-user Core Web Vitals assessment. Lighthouse's standard page-load test does not measure INP. Its Total Blocking Time result can help investigate responsiveness instead.

Scores can change between runs without anyone changing the website. Repeat the test and look for consistent problems, rather than treating one score as a verdict. A score of 100 is not necessary to make the page useful to customers.

Large phone photos, background videos and oversized banners can take time to download. Ask whether the site creates smaller versions suited to each screen and compresses them without spoiling visible detail. Making an image look smaller on the page does not necessarily make its downloaded file smaller.

Sometimes the delay starts before any image downloads. The hosting server may take too long to send the page, or a chain of redirects may delay the request. Styles and scripts can also stop the browser displaying content promptly. PageSpeed's diagnostics help your web person distinguish these causes.

• Ask for properly sized and compressed photos, using suitable formats such as WebP or AVIF where the website supports them.
• Check when the main top-of-page image starts loading. It should not use lazy loading, which deliberately delays images until they are needed. Lazy loading can help photos further down a long page.
• Ask your web person to investigate slow server response and caching. Caching means reusing a saved response or file instead of generating or downloading it again unnecessarily.
• Review unused code and unnecessary redirects before assuming you need a new hosting package or a complete rebuild.

A review feed, chat box, social feed or video player can load extra code from another company. These are third-party widgets. Their scripts can consume download time and keep the browser busy, making the rest of the page less responsive. Several individually useful widgets can create a problem together.

For a poor INP result, your web person should reproduce the slow action and check what the browser is doing at that moment. Shrinking photos alone will not necessarily fix a menu that freezes because of heavy scripts.

For a poor CLS result, check whether images, embedded panels and banners have space reserved before they load. Late-loading fonts can change line lengths and move surrounding content too. Your web person can set dimensions and review font loading so visitors do not have to chase buttons around the screen.

Start with a repeatable problem on an important page. Ask for a specific proposed fix and a before-and-after test of the same page. If a widget seems expensive to load, establish what it does before removing it. A lighter link to a map or video may be enough, while a booking panel may be essential.

Do not switch off a cookie control or required security check just to improve a score. Do not install several speed plugins at once. Overlapping settings make it harder to identify what helped and can stop menus or forms working. Arrange a backup and a way to undo changes before altering a live site.

• Choose the customer task that matters, such as reading a service page and reaching the enquiry form.
• Fix the main confirmed cause, then repeat the same measurement and walkthrough.
• Check menus, forms, payments and bookings after changing scripts or loading settings. Agree any submission test so it does not create a real order or unwanted messages.
• Record what changed and keep the test results with the page address and date.

A lab test can show a change straight away. PageSpeed's real-user results cover a rolling 28-day period, so older visits remain in the figures after a fix. Do not expect that section to reset as soon as you publish.

Repeat your phone walkthrough and keep checking the pages customers actually use. If public real-user data is unavailable, use repeated lab tests and practical checks without claiming they represent every visitor. Your web person can discuss private real-user monitoring if you need more evidence.

There is no need to rebuild solely because a single test looks poor. Establish the cause, fix what affects customers and verify that the important tasks still work.