Core Web Vitals: a practical guide for small business websites

Core Web Vitals describe aspects of how a page feels to use: how quickly its main content appears, how promptly it responds and whether its layout moves unexpectedly. For a small business, they are useful diagnostic measures rather than a substitute for clear content and a working enquiry route.

Start with the pages customers actually use. A perfect score on an empty test page is less useful than finding why a real service page is slow on a phone.

Understand the three measures

Web.dev’s Core Web Vitals documentation defines these good-experience thresholds:

Measure	What it describes	Good threshold
Largest Contentful Paint, LCP	When the largest visible content element is rendered	2.5 seconds or less
Interaction to Next Paint, INP	Responsiveness to user interaction	200 milliseconds or less
Cumulative Layout Shift, CLS	Unexpected visual movement	0.1 or less

The assessment uses the 75th percentile of visits, considered separately for mobile and desktop. All three need to meet their thresholds for a good Core Web Vitals assessment. This is different from getting one favourable result on a developer’s machine.

The thresholds help locate problems. They do not mean a site is fully accessible, commercially effective or guaranteed to rank above competitors.

Separate real-user data from test data

Field data describes observed user experiences over a reporting period. Lab tests run under chosen conditions and are useful for reproducing and diagnosing issues. The two can differ because real visitors use different devices, connections and interactions.

A small site may not have enough field data for a particular URL. Record that as a data limitation, not as a pass or a failure. Use repeatable lab checks and practical device testing while recognising what they cannot establish.

When comparing results, keep the URL, date, device profile, test conditions and tool together. A mobile test on one page cannot be fairly compared with a desktop test on another. Review the same representative pages before and after a change.

Investigate slow main content

If the main visible content arrives late, identify the element being measured and the resources it depends on. It may be an image, a large text block or another prominent element. Do not assume every slow page has the same cause.

Ask the developer to examine image dimensions, file weight, delivery, loading priority and any code that delays rendering. A very large photograph displayed in a small space may be wasteful. A third-party component near the top of the page may introduce another dependency.

An illustrative investigation: a service page uses a full-resolution camera photograph as its opening image. The first experiment could be a correctly sized, compressed alternative, followed by the same test conditions. Record the change rather than claiming that image compression always fixes LCP.

Investigate delayed interactions

Test the actions customers need: opening the menu, choosing a service, expanding an answer and completing the form. Note whether delay occurs consistently or only after another action.

Ask which scripts run during those interactions and whether unnecessary work can be deferred or removed. Adding several analytics tools, embeds and decorative effects can increase complexity, but the actual cause needs measurement.

Do not solve responsiveness by disabling useful functionality without reviewing the customer need. A simpler component may be appropriate; removing the only usable booking route is not a meaningful performance improvement.

Investigate moving layouts

Watch the page as images, fonts, banners and embedded content load. Does text move after someone starts reading? Does a button shift just as someone tries to tap it?

Ask whether space is reserved for media and dynamic content. Review late-loading banners and any elements inserted above existing content. Test with realistic content lengths as well as the shortest demonstration text.

A stable layout also needs to work at narrow widths. A wide table or long unbroken address can produce a separate overflow problem even when the main performance measures look acceptable. Inspect the finished page rather than relying exclusively on a report.

Choose fixes by customer impact

Make a short backlog with the page, observed problem, proposed cause, change, owner and verification method. Prioritise the main service and enquiry journeys before rarely used decorative pages.

Avoid buying a performance plugin or changing platforms before understanding the problem. Either can help in a suitable context, but neither is evidence that the diagnosis is correct. Our WordPress versus Astro comparison explains why implementation and workflow matter alongside the technology choice.

After a fix, repeat the diagnostic test and allow field reporting to reflect new visits where available. Keep a record of other changes that might affect the comparison. Improvement in a measurement is useful evidence, but it does not by itself prove an increase in sales.

Put performance in the website brief

Ask how representative pages will be checked, who owns the fixes and what happens when later content or integrations affect performance. Include practical mobile and keyboard checks using resources such as W3C’s Easy Checks.

A website should feel clear, responsive and dependable while helping customers understand the business. Performance work belongs inside that wider website design scope, not as an isolated pursuit of a score.