Page speed for small business websites, explained without the jargon

Three numbers decide whether Google considers your website fast. They are called Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, or LCP, INP and CLS. The thresholds for a good result are 2.5 seconds, 200 milliseconds and 0.1.

Failing one of them is common, and the reasons are usually dull. This post explains what each number measures, how to check your own in about five minutes, and the handful of fixes that account for most of the improvement.

The three numbers

Anything between good and poor is classed as needing improvement. Google judges each metric at the 75th percentile of real visits, which means a page counts as good only when at least three visits in four meet the threshold.

LCP in plain English

This is the time until the main thing you came for has drawn. On most small business sites that is the large photograph at the top or the first block of headline text. A restaurant home page with a very large hero image will struggle here.

INP in plain English

You tap the menu button and nothing happens for a moment. INP measures that delay across the whole visit and reports something close to the slowest interaction. It replaced the older First Input Delay metric in March 2024. It is usually caused by too much JavaScript competing for the phone's attention.

CLS in plain English

You go to tap Book a table and the page shifts, because an image or banner has loaded above it, and you hit the wrong thing. CLS adds up how far and how often that happens. It has no unit because it is a score, and lower is better.

Field data and lab data

This is the distinction people trip over. Both appear in the same report and they answer different questions.

• Field data comes from real visitors using Chrome, collected in the Chrome User Experience Report over the previous 28 days. It is what Google uses to judge your pages. A site with little traffic may have no field data at all, and the report will say so.
• Lab data comes from a test run by Lighthouse on a simulated mid-range phone and a throttled connection. It is repeatable, which makes it good for finding problems, and it can vary a little from run to run. INP needs real interactions, so the lab report uses Total Blocking Time as a stand-in.

Use field data to learn whether there is a problem, and lab data to find out why. The lab score from 0 to 100 is a summary of the lab metrics and Google does not rank on it. A perfect lab score beside a failing field result is a perfectly ordinary Tuesday.

Test your own site in five minutes

1. Open PageSpeed Insights at pagespeed.web.dev.
2. Paste in the page that matters, which is usually the page people reach from Google, such as a service or menu page, and not only the home page.
3. Start with the Mobile tab. It is the harder test and it matches how most local customers find a business.
4. Read the top section, headed “Discover what your real users are experiencing”. Note whether the assessment passed and write down the three values. If it says there is not enough data, rely on the lab section below it.
5. Scroll to the diagnostics and opportunities. The first three items usually point at the biggest problems.
6. Repeat for two more pages, ideally one with a booking form or a map.
7. Record the date and the numbers. Field data lags by up to 28 days, so wait a few weeks after making changes before judging them.

Search Console has a Core Web Vitals report for the field data across your whole site, grouped by similar pages. If you have access, that is the better place to watch for trends.

The fixes that matter

Images

Images are the usual cause of a slow LCP. The common faults are a photograph far larger than the space it fills, an old file format, and a hero image that is lazy-loaded when it should arrive first.

• Resize images to the largest size they will be shown at, and serve smaller versions to phones.
• Use a modern format such as WebP or AVIF.
• Never lazy-load the main image at the top of the page. Do lazy-load everything below the fold.
• Set a width and height on every image so the browser reserves the space. This is also the main fix for CLS.

Menus are the classic case. A PDF menu is slow to open on a phone and is often a scan with no text a search engine can read, and the restaurant website checklist covers what to do instead.

Fonts

Each font family and weight is a file the browser must fetch. A site loading four families in six weights has chosen to be slow. Keep it to one or two families and the weights you use. Host the files yourself rather than calling a third party, and tell the browser to show a fallback font while they load. Choose a fallback of a similar size, otherwise the text jumps when the real font arrives, and that is a layout shift.

JavaScript and page builders

INP problems usually trace back to JavaScript. Themes and page builders often ship code for features a given page never uses, such as sliders, animations and pop-ups. Each one adds work for a phone to do before it can respond to a tap. Switch off what you do not use, prefer plain HTML and CSS for things such as menus and accordions, and be suspicious of any plug-in that does something a few lines of code would do.

Third-party scripts

Chat widgets, tag managers, tracking pixels, review badges, booking plug-ins, embedded maps and embedded videos all run on your visitors' phones. They are the leading cause of poor INP and they are the first thing to audit.

• List every script that loads. Your developer or a tool such as PageSpeed Insights can show the list.
• Remove anything nobody has looked at in a year.
• Load heavy items on demand. A map or video can show a still picture until it is clicked.
• Check that each cookie banner and tracking tag is loaded once and not three times.

Everyone agreed to add each of them, and no one remembers why.

Hosting and caching

A slow server delays everything that follows. If the first byte arrives late, no amount of image work will rescue LCP. Budget shared hosting is a common culprit, along with sites that rebuild every page on every visit. Fixes include hosting close to your audience, full-page caching, a content delivery network for images and files, and keeping the software up to date. This is the part of the job that care and hosting exists to cover, because speed that was good at launch tends to erode as plug-ins and tags accumulate.

When you ask a host about speed, ask three things. Where are the servers? Is full-page caching switched on? How long does a typical page take to return its first byte? A host that cannot answer those is guessing as much as you are.

Banners, pop-ups and late-loading content

Cookie banners, announcement bars and newsletter pop-ups that push content down after it has appeared are a frequent source of CLS. Reserve space for them, or overlay the page and leave the layout where it is.

A sensible order of work

For a typical restaurant or services site, the order that gives the most for the least effort looks like this.

1. Measure the three or four pages that matter and record the numbers.
2. Fix the hero image on each, since that is nearly always the LCP element.
3. Set dimensions on every image and reserve space for banners.
4. Remove or defer the third-party scripts nobody can justify.
5. Cut the fonts to what the design uses.
6. Look at hosting and caching if the first byte is still slow.
7. Wait four weeks, then measure again.

Most of the gain arrives in the first three steps. The rest is tidying, which is worth doing but rarely changes the verdict.

What speed will and will not do for rankings

Google has said that page experience is one signal among many and that relevance still comes first. A fast page with nothing useful on it will not outrank a good page that is a little slow. Speed matters most for the visitor, who gives up on a slow page long before Google has formed a view.

So the sensible target is to pass the three thresholds on your most important pages and then stop. Chasing the last few points of a lab score takes time that is better spent on the content. If a rebuild is the cleanest route, it is part of our web design work, and speed is fixed in the build and not patched on afterwards.

Many of these fixes overlap with accessibility work, which we cover in accessible websites for small businesses. Test your pages this week and write the numbers down. If they pass, you have nothing to do.