Core Web Vitals: a website speed tutorial for small businesses

To improve website speed, find the part of the customer journey that is slow and fix its cause. Core Web Vitals help separate three problems: main content taking too long to appear, controls responding slowly, and content moving while someone is reading or tapping.

You do not need to become a performance engineer to make a useful start. You need a few important pages, a record of the results and a clear handover to whoever maintains the site.

This tutorial uses a hypothetical bakery website as a working example. The website in the image is illustrative; it is not a TrioFlare client project or a measured performance result.

Know what the three measurements mean

Google’s current Web Vitals documentation gives these “good” thresholds:

Measurement	Good threshold
Largest Contentful Paint, or LCP	2.5 seconds or less
Interaction to Next Paint, or INP	200 milliseconds or less
Cumulative Layout Shift, or CLS	0.1 or less

LCP describes when the largest visible content element appears. INP measures how quickly the page visually responds to an interaction. CLS measures unexpected movement in the layout.

The recommended assessment uses the 75th percentile of page loads, separated by mobile and desktop. In plain terms, you should look beyond one fast visit on your own laptop.

Use the measurements to ask better questions. If a menu reacts slowly, compressing a photograph may not solve the delay. If the page jumps as an embed loads, changing the server may not address the missing space in the layout.

Also keep the business task visible. A page with an attractive test score can still have a confusing enquiry form. Performance work should help customers finish what they came to do.

Step 1: test the pages that matter

Choose a small set of real URLs. For the bakery example, that might be the home page, a celebration-cake page and the order enquiry page. For your business, choose pages that represent different templates and important customer actions.

Open PageSpeed Insights and run each URL. Check mobile and desktop separately. Record the date, URL and the main issue you want to investigate; keep the report link if you plan to share it with a developer.

Distinguish the section describing real users from the simulated performance test. Real-user data describes observed visits when enough data is available. A lab test helps you investigate under its particular test conditions. Google’s explanation of why lab and field data can differ is useful background.

If a page has insufficient real-user data, write that down. It is not evidence that the page passes or fails for all customers. Use the available diagnostics and test the actual journey on representative devices while you gather more evidence.

Create a short working sheet:

Page	Observed problem	Next investigation
Home	Main image arrives late	Identify how the image is requested
Service page	Enquiry button reacts slowly	Inspect scripts running during the interaction
Contact	Content jumps when the calendar appears	Check the space reserved for the embed

These are example observations, not measurements from a real site. Replace them with what your report and your own testing show.

Step 2: find what delays the main content

For an LCP problem, identify the element the report calls out. It may be an image or a text block. Do not assume that every slow page has the same cause.

For our bakery example, ask whether the main photograph is larger than the display needs, requested too late or waiting behind other work. Your developer should be able to explain the request path and propose a targeted change.

Google’s LCP optimisation guide describes the different parts of the delay. Useful checks include whether the browser can discover the main image early and whether the page mistakenly lazy-loads it.

For images further down the page, lazy loading can make sense. For the main image, the decision should follow its role in the first screen. Give images dimensions so the browser knows the space they will occupy.

After a change, look at the image as well as the number. A blurry product photograph is not a useful improvement for a business that depends on customers understanding the product.

Step 3: investigate slow taps and moving layouts

Treat these as separate tasks. A slow interaction is a response problem. A layout shift is a stability problem. You may need different fixes and different people to investigate them.

When a button or menu feels slow

Try the actual action that causes trouble. Open the navigation, change a filter, type in the form and move through its steps. Ask your developer to record the interaction and identify the work blocking a visible response.

Large JavaScript tasks and unnecessary work during an interaction are worth checking. The INP optimisation guide explains how to investigate delays rather than treating all JavaScript as equally responsible.

Ask what a script does before removing it. Booking, spam protection, accessibility and essential business functions should not be disabled to make a report look cleaner. Remove or defer work only after understanding its purpose.

When the page moves under someone’s finger

Watch the page while it loads. Look for images, fonts, banners or embeds appearing after the surrounding content. Note what moved and when.

The CLS optimisation guide covers common causes, including content without reserved dimensions. For a booking embed, ask whether an appropriate space can be reserved while it loads.

Then test the important action again. The goal is a stable page that still works at narrow widths, with enlarged text and with the keyboard visible on a phone.

Step 4: verify one change at a time

Keep the change small enough to explain. If you replace images, remove scripts and change hosting together, it becomes harder to know what helped or what broke.

For each change, record the problem, proposed fix, affected URLs and checks you ran. Compare lab tests under similar conditions, and give real-user reporting time to reflect new visits. Do not present a fresh simulated test as proof that every customer’s experience has improved.

Use this release checklist:

• The affected page still looks correct on mobile and desktop.
• Navigation, forms, booking and any payments still work.
• Images remain clear and have useful alternative text where needed.
• The keyboard and focus behaviour still work.
• Required security and spam controls remain in place.
• Business measurement still records the events you actually need.
• There is a documented way to undo the change if it causes trouble.

Prioritise the next fix by the customer task it affects. A delay on the page where someone requests a quote deserves attention even if another page produces a more dramatic test screenshot.

Common questions

Should I aim for a score of 100?

A score can help compare controlled tests, but it should not replace checking the real journey. Start with a clear performance problem, the relevant Core Web Vital and whether customers can finish their task comfortably.

Will faster pages guarantee better Google rankings?

No. Google says page experience involves multiple signals, and good Core Web Vitals do not guarantee top rankings. Speed work is useful for the experience itself; content relevance and the rest of the website still matter.

Can I fix this without rebuilding the whole website?

Often, a specific issue can be investigated within the current site. Ask for the cause and a targeted proposal first. A rebuild is a separate decision that should account for the content, customer journey and maintenance needs.

If you would like help turning a speed report into a practical fix list, see our website development service or send us the affected URLs. You can also use our mobile contact-form checklist to check the enquiry journey after the performance work.