Website speed test: is your site fast enough to win the job?

The score is a summary, so read the measurements underneath it before buying a fix. Largest Contentful Paint, or LCP, asks how quickly the main visible content appears. Cumulative Layout Shift, or CLS, describes unexpected movement while the page loads. Interaction to Next Paint, or INP, concerns how quickly the page responds after a tap or another interaction. They describe different problems and need different repairs.

Google's Web Vitals guidance sets good thresholds at LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. Field assessment uses the 75th percentile of visits, separated by device. Those thresholds come from Google, not a TradeFlo sales target. The source is linked below so your developer can check the definitions and measurement method.

Look at the data note on your result. Field data describes visits collected from real users. Lab data comes from a controlled test and helps investigate a page under those test conditions. A small site may have no usable field data. That means we cannot report that reading; it does not mean the business has failed a customer-experience test. Keep an unavailable measurement separate from a poor measurement.

Choose a page with a clear job for the visitor. For a heating firm that might be the boiler repair page, where someone needs to find the phone number. For a contractor it might be a project page, where an estimator checks the firm's experience before making contact. Enter the complete public address. Avoid a private customer portal, a draft preview or an address that needs a password.

This tool requests a mobile check. Use the same page when you compare readings, and write down whether the site changed between runs. A test of the homepage followed by a test of a photo-heavy gallery is not a before-and-after comparison. If the result looks surprising, repeat the check and open the page on your own phone. Record what you can actually see: a blank area, a moving button, a delayed menu or a usable page.

A phone check also catches things a speed score cannot settle. Can you read the service area without zooming? Does the telephone link open the dialler? Can you dismiss the cookie banner and reach the enquiry form? Treat those observations as a separate list. A good loading result does not prove that the customer can finish an enquiry, and a usable form does not explain a slow first screen.

For a slow LCP, ask the developer to identify the largest element and the work delaying it. If that element is your opening project photograph, ask whether the delivered image is larger than the space where it appears. Request an appropriately sized file and a check of when it starts loading. If the delay happens before the page responds at all, ask them to investigate the server response instead of compressing unrelated pictures.

For a poor CLS result, watch what moves. An image without reserved space, a late banner or a font change can push text and buttons around. Ask for the cause of the movement and an explanation of how the page will reserve the required space. For a poor INP reading, name the interaction that felt delayed. Your developer can then investigate work on the browser's main thread rather than guessing from the headline score.

Keep the first repair small enough to assess. A request such as 'make the site faster' gives you no agreed finish. A better brief names the page, the measurement, the suspected cause, the proposed change and the check afterwards. Ask the developer to explain their diagnosis before replacing a theme, changing hosting or adding another performance plugin. None of those purchases follows automatically from a low score.

Imagine a roofing firm whose repairs page opens with a large photograph and then loads a long project gallery. This is an example of how to investigate, not a customer result. The owner notices that the opening image appears late on a phone. The next useful question is which image the test identifies as the largest visible element and when its download begins.

The repair brief could read: 'Check the opening photograph on our roof repairs page. Deliver a version sized for its display, keep its space reserved while it loads and check that the enquiry button stays reachable. Leave the rest of the gallery for a separate pass.' That gives the developer a specific page and a visible behaviour to examine. It also leaves room for the diagnosis to show that the image was not the cause.

After the change, run the same address again and repeat the phone check. Keep both readings, even if the headline score varies. Record whether the original problem improved and whether anything else broke. If the gallery looks soft, a menu stops responding or the call button moves off screen, the repair needs more work. Do not accept a screenshot of a better score as the whole handover.

Send the exact URL, the test date, the result and the action you tried on a phone. Include a screenshot of the visible fault if you have one. Separate a measured reading from your own observation: 'LCP needs work' and 'the photograph appeared late on my phone' are useful pieces of evidence, but they are not the same measurement. Ask what the developer needs to reproduce the issue.

Agree how you will check the repair before it starts. Use the same page and test type, then test the enquiry route in the browser. Ask for the change to be reversible and for a record of what was altered. If the developer changes an image, a script and the hosting together, you will have less evidence about which change mattered. A contained first pass makes the next decision easier.

A timeout, a protected website or an unavailable provider can prevent the check from finishing. Retry with the public address, making sure it opens normally without a login. If the checker still cannot read it, save the message and ask the website owner or developer to investigate. Do not describe an unavailable scan as a slow website. There is no measured speed result in that case.

When you have a result, use the button below to check another important page or bring the reading to a call request. Tell us the service page you tested and the part a customer struggled with. We can use that starting point to discuss a sensible first repair, without treating the score as proof of lost jobs or promising a ranking change.