Website speed is worth checking because people notice friction quickly. A poor speed score is not, by itself, a reason to rebuild a website. First record what visitors experience, save the test results, and check whether the site still helps them complete its main task. Ask the technical person to identify the cause.
Measure the right thing
Start with a few important pages, usually the homepage, a core service page, and the contact or checkout flow. Choose one page for the first check and write down the problem you noticed, such as a slow first view, a delayed response after a tap, or content moving while you try to read or click.
Open PageSpeed Insights, paste the full page address, and click Analyze. Save the Mobile and Desktop results separately. Record the date and tested address, then copy or screenshot the real-user section and the Lighthouse diagnostics. You do not need to decide which diagnostic caused the problem; send the saved results to the technical person.
The real-user section uses Chrome data from the previous 28 days. If the exact page does not have enough eligible visits, PageSpeed Insights may show an origin summary based on pages across the domain. That summary does not necessarily describe the page you tested. If no real-user data appears, write down not available rather than treating its absence as a pass or failure.
The Lighthouse section is one simulated lab run. It can help a developer diagnose the page, but a green lab score does not prove that real visitors had the same experience. Do not expect every field metric to appear there: INP depends on user interactions and is not produced by a standard page-load test.
Google's current Core Web Vitals guidance defines a good field result as:
- Largest Contentful Paint (LCP): the largest image or text block visible in the first screen appears within 2.5 seconds;
- Interaction to Next Paint (INP): the page responds to an interaction within 200 milliseconds;
- Cumulative Layout Shift (CLS): unexpected movement stays at 0.1 or less.
These results use the 75th percentile and are assessed separately for mobile and desktop. In plain language, a reported value of 2.5 seconds at the 75th percentile means about three quarters of recorded visits reached that value or a faster one; the remaining quarter may have been slower. The assessment passes when every Core Web Vital with enough data is in the good range. Sometimes there is too little INP data, so the assessment uses the other two metrics. Keep the device results separate: compare Mobile before and after a change, and do the same for Desktop.
The metrics describe loading, responsiveness, and visual stability. They do not measure content, accessibility, conversion, or overall site quality.
Look for the problem behind the score
The same headline score can come from very different causes. A page may be heavy because of uncompressed images. Another may be delayed by third-party scripts, an old theme, too many plugins, slow server responses or a page that loads resources it does not need.
Your job is to note the visible problem and collect the results, not to diagnose the code. Ask the developer or site maintainer to check:
- Is the largest image sized for the space where it appears?
- Are videos, maps, chat widgets and tracking scripts loaded only where they are needed?
- Does the mobile page contain the same unnecessary material as the desktop page?
- Do fonts, animations or pop-ups delay reading or interaction?
- Are recurring server or database delays visible in the hosting and monitoring data?
You do not need to diagnose scripts, hosting, or databases yourself. Send the tested page addresses, date, mobile and desktop results, and the problem you observed to the developer or person who maintains the website. Ask them to return:
- the specific cause, such as a large image, script, or slow server request, with the evidence behind that conclusion;
- the smallest proposed correction and an estimate of the work;
- three Lighthouse tests for the same URL and device type before and after the change, with all results recorded;
- confirmation of a successful test form submission, checkout, or other important page task after the change.
If the evidence points to a recurring server or database delay, include hosting support. This turns a general complaint about speed into a short list of work that can be estimated and tested.
Lighthouse results can vary between runs, so compare the pattern across all three lab tests instead of choosing the best score. The lab results can show an immediate difference after a change. The real-user figures will not update immediately because they still cover the previous 28 days. Review them again over the following weeks to see whether the experience improved for real visitors.
Improvements that often make sense
There is no universal performance checklist, but possible starting points include resizing images, delaying files that do not affect the first view, improving caching, and removing scripts or plugins that no longer serve a purpose. Fonts, third-party widgets, server or database response, theme or plugin overhead, and loading order may also matter. Test the cause before choosing the fix.
Each change needs a before-and-after check. It is easy to improve a lab score while breaking an image, form, consent banner or tracking setup. Complete the page's key task on a phone and a desktop or laptop. For a contact page, submit a test inquiry and verify the success message and email delivery. For a checkout, use the agreed test process and verify every step through the order confirmation. Record whether each test passed.
When optimization is enough
Targeted work is often enough when the site is structurally sound and the problem is isolated. In that situation, a rebuild can add cost and risk without solving a business problem.
Optimization is also a sensible first step when you need evidence. Fix the clear issues, measure again, and see whether the visitor experience improves. That gives a better basis for a larger decision.
When a rebuild deserves consideration
A rebuild may make sense when performance problems come with wider limits. The platform may no longer be supported, the content model may be difficult to manage, the mobile experience may not match what visitors need or several old patches may make routine changes risky.
Ask what the new site would improve beyond a test score. It should make the content easier to maintain, remove a real technical constraint or give visitors a better path through an important task. If it cannot answer one of those questions, start with a smaller fix.
Use speed as part of a wider review
Speed matters because it affects the experience of using a site. It is one part of a healthy website, alongside clear content, reliable forms, accessible design, and useful analytics. New web design projects include optimized code, compressed images, and a pre-launch speed check. Maintenance and later changes are separate work.
