♞Websites
How to Make a Small Business Website Faster: Core Web Vitals in Plain English
Short answer: To make a small business website faster, measure your key pages in PageSpeed Insights and Search Console, then fix the usual causes: oversized images, a lazy-loaded hero, too many plugins and third-party scripts, slow hosting and content that jumps as it loads. Aim for Google’s targets: LCP within 2.5 seconds, INP under 200 ms and CLS below 0.1.
Most small business websites are not slow because of one big mistake. They are slow because of twenty small ones: a hero photo straight off the camera, a slider nobody asked for, a chat widget, three tracking tags and a theme that loads every feature on every page. Each one looks harmless. Together they make a customer on a phone wait, and some of them will not.
This guide explains Core Web Vitals in plain English, shows you how to measure them without being misled by the score, and lists the fixes that make the biggest difference, in roughly the order we tackle them on our website redesign projects. You do not need to be a developer for most of them.
What are Core Web Vitals, in plain English?
Core Web Vitals are three measurements Google uses to describe how a page feels to a real visitor. Forget the acronyms for a moment and think of them as three questions your customer asks without realising it.
- Is it there yet? Largest Contentful Paint (LCP) measures how long the biggest thing in the first screen, usually the hero image or headline, takes to appear.
- Did it react? Interaction to Next Paint (INP) measures how quickly the page responds when someone taps a button, opens a menu or types in a form.
- Did it move? Cumulative Layout Shift (CLS) measures how much the layout jumps around while it loads, the reason people tap the wrong button.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP (loading) | 2.5 s or less | Up to 4 s | Over 4 s |
| INP (responsiveness) | 200 ms or less | Up to 500 ms | Over 500 ms |
| CLS (stability) | 0.1 or less | Up to 0.25 | Over 0.25 |
Google assesses these at the 75th percentile, which means at least three out of four visits need to hit the target, and it reports mobile and desktop separately. A page that is quick on your office broadband can still fail on a mid-range phone.
INP replaced First Input Delay (FID) as a Core Web Vital on 12 March 2024. If a guide or plugin still talks about FID, it is out of date. Thresholds can change, so check Google’s current documentation before you set targets.
Does website speed affect Google rankings?
Yes, but not in the way speed plugins like to suggest. Google’s own documentation says good Core Web Vitals align with what its core ranking systems seek to reward, and it recommends that site owners achieve them. It does not say a fast site will outrank a more relevant one. Relevance and helpful content come first.
The stronger reason to care is people. A slow page loses you visitors before they read a word, and a page that jumps or ignores taps feels broken, which damages trust in the business behind it. Speed work is one of the few website jobs that helps search, advertising and conversion at the same time.
How to measure your website speed properly
Field data and lab data are different things
PageSpeed Insights shows two kinds of results. The top section, when it appears, is field data: real visits from Chrome users over the previous 28 days, taken from the Chrome UX Report. Below it is a Lighthouse lab test with the famous 0 to 100 score, run once on a simulated device.
The lab score is a diagnosis tool. It tells you what is slowing the page down. The field data is what your visitors actually experienced and what Search Console reports on. Do not chase a perfect 100; chase green field data. Smaller sites often have no field data because they do not get enough Chrome traffic, in which case the lab test is your best guide.
Use the Search Console Core Web Vitals report
If your site is verified in Google Search Console, the Core Web Vitals report groups similar URLs and labels each group Good, Need improvement or Poor, separately for mobile and desktop. Fix Poor groups first, starting with the pages that matter most to the business. After a fix, you can start validation, which tracks the URLs for 28 days before confirming the issue is resolved.
Test the pages that earn you money
Do not test only the homepage. Test your top service or product page, a blog post that brings in search traffic, and your contact or booking page. Then open each one on an ordinary phone using mobile data and watch it load. You will often spot the problem in seconds: a hero that appears last, a banner that pushes everything down, a menu that takes a beat to open.
Fix slow loading (LCP) first
On most small business sites, loading is the biggest problem and the easiest to improve. Google’s web.dev guidance notes that images are the LCP element on over 70% of pages, so start there.
Resize and compress your images
Upload images at the size they are displayed, not the size the camera produced. A full-width hero rarely needs to be wider than about 2,000 pixels, and a team headshot shown at 300 pixels does not need to be 4,000. Export as WebP or AVIF where your platform supports it, and let the site serve smaller versions to phones with responsive images (most modern themes and platforms do this if you upload correctly).
Never lazy-load the hero
Lazy loading delays images until they are about to scroll into view. It is excellent for images further down the page and harmful for the first one. A common mistake is a plugin that lazy-loads every image, including the hero, which pushes LCP back. Exclude above-the-fold images from lazy loading and, if your developer or platform allows, mark the hero with fetchpriority=’high’ so the browser fetches it first.
Make the hero easy for the browser to find
The browser loads fastest what it can see in the page’s HTML. Hero images set as CSS backgrounds, injected by a slider script or swapped in by JavaScript are discovered late. A plain image in the HTML is usually quicker. This is also one more reason to drop the homepage slider; a single strong image and headline usually does the job better, as we explain in our guide to what to put above the fold.
Check hosting, caching and a CDN
If the server takes a long time to send the first byte, nothing else can start. Budget shared hosting, no page caching and visitors on another continent from your server all add delay. Turn on page caching, use a content delivery network (CDN) if your audience is international, and keep your platform, theme and PHP or server software up to date.
Fix sluggish taps and clicks (INP)
Poor INP almost always comes from too much JavaScript competing for the browser’s attention. On small business sites the usual suspects are page builders, unused plugins, chat widgets, pop-ups, review carousels, social feeds, heatmap tools and a pile of tracking tags nobody has reviewed in years.
- Audit every script. List each plugin, tag and embed, what it does and who still uses its data. Remove anything nobody can justify.
- Load extras only where needed. A booking widget belongs on the booking page, not on every blog post. A chat widget can load after the visitor interacts or scrolls.
- Keep the page structure lean. Some page builders wrap each element in many layers of code. Very large pages and mega menus with hundreds of links make every interaction slower.
- Give feedback instantly. Buttons and menus should visibly respond the moment they are tapped, even if the work behind them takes a little longer.
Stop the page jumping (CLS)
Layout shift is the most irritating problem for visitors and often the quickest to fix once you know the causes.
- Images and videos without dimensions. Give every image width and height attributes, or a fixed aspect ratio, so the browser reserves the space before the file arrives.
- Embeds, maps and ads. Reserve space for them with a minimum height so they do not shove content down when they load.
- Cookie banners and announcement bars. Let them overlay the page rather than push it down, or include them in the layout from the start.
- Web fonts. When a custom font replaces a fallback font of a different size, text reflows. Use few font files, preload the main one and choose a fallback with similar proportions.
- Animations. Animate with transform and opacity rather than properties that change the layout.
Quick fixes ranked by effort, and when they are not enough
| Fix | Main benefit | Effort |
|---|---|---|
| Compress and resize images | LCP, page weight | Low |
| Stop lazy-loading the hero | LCP | Low |
| Add image dimensions | CLS | Low |
| Remove unused plugins and tags | INP, LCP | Low to medium |
| Page caching and a CDN | LCP | Medium |
| Replace the slider with one hero | LCP, CLS | Medium |
| Cut fonts to two families | LCP, CLS | Medium |
| Rebuild on a lighter theme | All three | High |
From our projects: before removing anything, we copy the site to a staging version and switch plugins and tags off one at a time, retesting after each. It turns a vague feeling that the site is heavy into a short list of the exact items slowing you down, and it stops anyone breaking a contact form on the live site.
When quick fixes are not enough
Sometimes the problem is the foundation. A heavy theme, a page builder stacked on top of another page builder, or years of plugins added and never removed can mean that tuning only gets you so far. If you have done the quick fixes and your field data is still red on mobile, or every change risks breaking something, a rebuild is often the better long-term option than endless patching. Our article on the signs a website needs a redesign covers how to decide, and our website redesign checklist shows how to plan one so speed is designed in from the start.
Checklist: a faster small business website
- Test home, top service or product page, a popular blog post and the contact page in PageSpeed Insights.
- Check the Search Console Core Web Vitals report for mobile and desktop and fix Poor groups first.
- Resize every large image to its display size and export as WebP or AVIF.
- Exclude the hero image from lazy loading and give it high fetch priority.
- Replace homepage sliders and autoplay hero videos with one strong image.
- Add width and height to images and reserve space for embeds and banners.
- Remove unused plugins, widgets and tracking tags; load the rest only where needed.
- Turn on page caching and use a CDN if your customers are spread across countries.
- Limit fonts to two families and a few weights, and preload the main font.
- Retest on a real phone using mobile data, then start validation in Search Console.
Questions
What is a good PageSpeed Insights score?
Lighthouse treats 90 or above as good, but the score is a lab test on a simulated device. What matters more is the field data at the top of the report and in Search Console: LCP within 2.5 seconds, INP under 200 milliseconds and CLS below 0.1 for at least three in four visits.
Why is my website fast on desktop but slow on mobile?
Phones have slower processors and often slower connections, so heavy images and JavaScript hurt them far more. Google also tests mobile with throttled settings. Large hero images, page builders, chat widgets and tracking scripts are the usual causes. Fix images first, then reduce scripts, and always retest on a real phone.
How long does it take for Core Web Vitals to update?
Field data in PageSpeed Insights and Search Console is based on the previous 28 days of real visits, so improvements show gradually rather than overnight. When you start validation in the Search Console Core Web Vitals report, Google monitors the affected URLs for 28 days before marking the issue as fixed.
Do WordPress plugins slow down a website?
Not every plugin, but many add scripts and styles to every page, and they add up. The number matters less than what each one loads. Remove plugins you no longer use, replace several single-purpose plugins with one where sensible, and test speed before and after each change on a staging copy.
Should I use WebP or AVIF images on my website?
Both are modern formats that are much smaller than JPEG or PNG at similar quality, and both are supported by current major browsers. AVIF often compresses further, while WebP is supported by more tools and plugins. Use whichever your platform handles reliably, and keep a fallback if your audience uses older browsers.