Website speed optimization starts with a simple question: what is slow, and what does that stop a visitor from doing? A late photo, a frozen menu and a moving button are different problems. They need different fixes.
You do not need to chase a perfect score to begin. Pick an important page, save a starting result and fix one clear problem. Then check the page again under similar conditions.
The short answer
- Match the fix to the symptom, late content, slow reactions or page movement.
- Separate lab diagnostics from the 28 day view of real visits.
- Retest under similar conditions and confirm menus and enquiries still work.
How this guide was made
This guide draws on Google PageSpeed Insights documentation and web.dev performance guidance. The evidence log is a fictional worksheet with Pending results. No SnapRebuild or customer speed test was run for this guide, and no performance or sales gain is claimed.
Sources checked .
Name the page and the slow task
Open the site as a new visitor would. Does the main text take a long time to appear? Can you tap the menu right away? Does the page jump just as you try to choose a service? Write the symptom in plain words.
Start with a page that matters to the business. That might be your homepage, main service page or booking page. Testing a quiet policy page will not tell you much about a busy homepage with photos and extra tools.
Note the page address, device and connection. If you only test on a fast office connection, you may miss what people see on a phone. Ask another person to repeat the same task if the problem is hard to describe.
Understand a speed test
PageSpeed Insights reports two kinds of evidence. Keep their scope, date and device setting in your notes. A headline score alone does not explain what a visitor experienced.
Lab tests help find causes
A lab run tests a page under set conditions. Its diagnostics can help explain a slow load, but results can vary between runs. Repeat the same test if a result looks unusual and save the range, not just the best number.
A Lighthouse score is not a pass result for all real visitors. A normal page load run does not directly measure INP. Use field evidence or suitable interaction testing to assess that measure.
Source for this section: [3] Google PageSpeed Insights lab and field data
Field data shows real visits
PageSpeed Insights field data comes from eligible Chrome visits over a trailing 28 day period, not every visitor. It may report the page itself or fall back to the wider origin, which groups pages under the same site origin. Record which view the report shows.
A new or lightly visited page may lack enough data. That means evidence is unavailable, not that the page passed or failed. A fix made today will not replace the old 28 day window at once.
Source for this section: [3] Google PageSpeed Insights lab and field data
Learn the three main measures
The web.dev Web Vitals guide uses three measures. Its good thresholds apply at the 75th percentile of visits, which means roughly three out of four visits meet the target. Mobile and desktop results are assessed separately.
- Use the measure that matches the complaint.
- Keep the full result instead of copying only the headline score.
- Do not treat a single lab run as proof of field performance.
| Measure | Plain meaning | Good threshold |
|---|---|---|
| Largest Contentful Paint, or LCP | When the largest visible content appears | 2.5 seconds or less |
| Interaction to Next Paint, or INP | How quickly the page responds to an action | 200 milliseconds or less |
| Cumulative Layout Shift, or CLS | How much visible content moves unexpectedly | 0.1 or less |
Source for this section: [1] Web Vitals guidance from web.dev
Trace the symptom to a likely cause
A late image, a slow button and a jumping page can have different causes. Ask the technical owner for evidence that ties the proposed change to the problem.
| Symptom | First check | Evidence to save |
|---|---|---|
| Main photo appears late | Image size and when the browser finds it | Image name and test details |
| Button reacts slowly | Work running when it is tapped | Action tried and delay observed |
| Text jumps down | Space reserved for images or banners | Page section and a short description |
The main image appears late
Check server delay, when the browser finds the image, its download and the wait before it appears. Do not lazy load the main visible image when it is the LCP element. The right priority depends on the actual page, so not every image needs a preload.
Ask: Which loading phase is causing the delay, and what will this change shorten?
Source for this section: [2] How to improve Largest Contentful Paint
A button reacts late
Long script work or heavy event handling can hold up a response. A developer can inspect the work around the interaction, remove what is not needed or split work into smaller tasks. Compressing a photo does not fix every slow menu.
Ask: What work runs when I tap this button, and can the page respond before that work finishes?
Source for this section: [4] How to improve Interaction to Next Paint
The page jumps
Check whether images and embeds have space reserved through dimensions or an aspect ratio. Look for late banners, inserted blocks and fonts that change the layout. Keep useful tools, but give them a stable place.
Ask: Which element moves, and what arrived or changed just before it moved?
Source for this section: [5] How to improve Cumulative Layout Shift
Change one thing and check again
Ask for a clear change, such as using a smaller copy of the main photo while keeping it sharp enough. Record what changed and who made it. This makes the next result easier to explain.
Run the same page test with the same setting. If results vary a lot, repeat it and keep the range rather than picking only the best run. Write down what improved, what stayed the same and what still needs work.
Then try the real task again. A higher score is not a win if the menu stops working or the contact form loses a field. Read the page, open the menu and send a safe test through the contact path.
Keep a short speed log
This fictional worksheet shows how to record evidence without inventing an improvement. Replace Pending only after the named check is complete. A smaller file is a measured size change, but it is not by itself proof that visitors saw a faster page.
Check both a preview and the published page. They may load different images or outside tools. Keep the log with your website notes so future edits have a clear starting point. Better speed is an ongoing care task, not a promise made by one green score.
| Record field | Fictional worksheet entry |
|---|---|
| Page and symptom | Homepage photo appears late |
| Starting lab runs | Pending, save several runs and their range |
| Field scope and dates | Pending, note URL or origin and report window |
| Proposed change | Inspect image discovery, then choose an evidenced fix |
| Retest conditions | Same URL, device setting and test method |
| New results | Pending, keep full reports |
| Real task result | Pending, open menu and submit a controlled enquiry |
| Decision | Keep, revise or undo only after review |
Sources and further reading
Numbered links beside each section point to the source used there. Our examples and checklists are guidance from SnapRebuild. They are not claims of test results. Product details can change.
SnapRebuild sells a website building service. These guides are published under our editorial team name and use AI for research and writing. This is not a claim of independent expert review. Read how we make and update our content. Found an error? Tell us.
Ready for a fresh start?
Bring your website or your business idea. Explore a SnapRebuild preview and decide what comes next.
Try your free preview