How fast is fast enough? Ask the web team of a large retailer and they will answer with numbers, written down in advance. The practice even has a name: a performance budget, which web.dev (Google's site for web developers) defines as "a set of limits imposed on metrics that affect site performance".
A small business owner, meanwhile, usually judges speed from their own phone, on the office Wi-Fi, on a page they have visited many times. It feels fast, naturally. The customer on a train, on an older phone, opening the page for the first time, may have a different experience.
The good news is that the standard big companies measure against is public and free. Google publishes the targets, and Google gives away the tools to check them. Let us see what the numbers are and how you can measure your own site this week.
What speed standard do big-company websites aim for?
The shared standard is a set of three measurements that Google calls Core Web Vitals. Google's Search documentation is direct about them: "We highly recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally."
According to web.dev, the three measurements and their "good" targets are:
- Largest Contentful Paint (LCP) measures loading. The largest visible element of the page, often the main photo or headline, should appear within 2.5 seconds of the page starting to load.
- Interaction to Next Paint (INP) measures responsiveness. When a visitor taps, clicks or types, the page should respond on screen in 200 milliseconds or less.
- Cumulative Layout Shift (CLS) measures visual stability, meaning how much the content jumps around while it loads. The score should be 0.1 or less.
There is one more detail in the standard, and it matters. web.dev recommends measuring these at the 75th percentile of page loads, separately for mobile and desktop. In plain words, at least three visits in four must meet the target. A page passes only when all three measurements meet their targets at that level. This is a strict standard, and it is strict on purpose: an average would hide the slow visits, and each slow visit is a real customer waiting.
Where are the lines between good, needs improvement and poor?
Google's PageSpeed Insights tool sorts every measurement into three groups, using the thresholds of the Web Vitals programme:
| Measurement | What it describes | Good | Needs improvement | Poor | |---|---|---|---|---| | Largest Contentful Paint (LCP) | Time until the main content appears | 2.5 seconds or less | Over 2.5 and up to 4 seconds | Over 4 seconds | | Interaction to Next Paint (INP) | Time to respond to a tap, click or key press | 200 milliseconds or less | Over 200 and up to 500 milliseconds | Over 500 milliseconds | | Cumulative Layout Shift (CLS) | How much the layout moves while loading | 0.1 or less | Over 0.1 and up to 0.25 | Over 0.25 |
The middle column is the one to watch, because a page that slides from good to needs improvement gives an early warning. A small business can watch the same columns with the same free tools that big web teams use.
How can an owner measure their own website for free?
Two free Google tools do most of the work.
PageSpeed Insights. You type in the address of a page, and the report shows two kinds of data. The first is real visitor data, taken from the Chrome User Experience Report, which records the experience of real Chrome users over the previous 28 days. Google's documentation says PageSpeed Insights shows the 75th percentile of these real visits and then gives the page a Core Web Vitals assessment: it passes if all three measurements are good. If there is not enough data for INP, the page passes when LCP and CLS are both good. The second kind is lab data: a test run by a tool called Lighthouse, which loads the page once in a simulated setting and gives a performance score. Google says a score of 90 or above is good, 50 to 89 needs improvement, and below 50 is poor.
Which one matters more? The real visitor data describes your customers; the lab score describes one simulated visit. Read the assessment first, and use the lab report for its suggestions, because PageSpeed Insights lists audits that explain how to improve each page.
Two more details from Google's documentation help an owner read the report. When a single page has too few real visits (Google mentions pages that were recently published or have too few samples from real users), PageSpeed Insights falls back to the data for the whole website. When the whole website has too little data, only the lab test appears. And the report has separate tabs for mobile and desktop. Start with mobile, because web.dev asks for each device type to be measured on its own, so a page can pass on desktop and fail on phones.
The Core Web Vitals report in Google Search Console. Search Console, which Google describes as a free service, includes a report that groups the pages of your website by status (poor, need improvement, good) using real visitor data. Google's help page explains that a group of pages takes the status of its worst measurement, so a group with poor CLS is poor even if its INP is good. The report shows only indexed pages, and only those with enough data, and Google says it shows a sample of pages to help you assess the site's performance. A small website may see "No data available", which means there are not yet enough real visits to measure. In that case, PageSpeed Insights remains your tool, page by page.
Our page on the free tools a small business can use explains how to set up Search Console if you have not done it yet.
Why do the lab score and the real visitor data disagree?
An owner may see a low lab score and a passing assessment on the same report, or the opposite, and wonder which to believe. Google's documentation gives the reason. Lab data is collected in a controlled environment, which is useful for finding problems but may miss real-world ones. Field data, meaning data from real visits, captures the true experience but offers fewer measurements.
In the end, the customer is the one who matters. When the two disagree, trust the real visitor data for the verdict and use the lab report as a list of things to try.
What does a performance budget look like for a small business?
web.dev describes a performance budget as limits on measurements such as the total size of a page, the time it takes to load on a mobile network, or the number of requests the page makes. web.dev also explains how development teams build these limits into their process, so that a new feature that breaks the budget is noticed before it goes live.
A small business can keep a shorter version, written in one sentence and checked once a month:
- The home page, the main service pages and the contact page keep good Core Web Vitals on mobile.
- Before adding a new plugin, widget, chat tool or video to the site, test the page in PageSpeed Insights, add the feature, and test again.
- If a page moves from good to needs improvement, open the PageSpeed Insights suggestions for that page and fix the first items on the list.
That is the entire budget. It fits beside the monthly routine we describe in website maintenance at the big-company standard. For a longer explanation of each measurement and fixes by website platform, see our guide to Core Web Vitals explained.
How often did speed problems appear on the sites we checked?
Licheo's retired audit tool read up to 20 pages per website and completed audits of 66 distinct domains. It recorded at least one performance finding on 59 of those 66. These are websites that visitors, and our own team when testing, chose to type into the tool, so the figure describes those sites alone, and some of them belong to companies larger than a small business. It tells us that speed problems were common among the websites people brought to us.
Where should a small business start?
Run your home page and your contact page through PageSpeed Insights on a phone setting today, and write the three numbers down. That is your starting point. If you prefer to do the work yourself, our page on what an owner can do alone shows how speed fits among the other tasks, and our guide to small business SEO puts it in the context of the whole search plan. Speed is also one of the features covered in the website features big companies have.
At Licheo, a team of specialist AI agents builds the website, keeps it fast and findable on Google and in AI assistants, and nothing goes live until the owner approves it. The website, search and AI work that big companies pay whole teams for, done for your small business. The story of how that became possible is in how big-company marketing reached the small business. For pricing, contact us, and to see where your website stands in under 60 seconds, try the free Get Found Check.
Sources
- Performance budgets 101, web.dev (Google), Last updated 2018-11-05, accessed 27 September 2026.
- Understanding Core Web Vitals and Google search results, Google Search Central, Last updated 2025-12-10, accessed 27 September 2026.
- Web Vitals, web.dev (Google), Last updated 2024-10-31, accessed 27 September 2026.
- About PageSpeed Insights, Google for Developers, Last updated 2024-10-21, accessed 27 September 2026.
- Core Web Vitals report, Google Search Console Help, accessed 27 September 2026.
- About Search Console, Google Search Console Help, accessed 27 September 2026.
- Licheo audit tool records, queried read-only from the Licheo production database on 27 September 2026 (102 completed audits of 66 distinct domains, 2025-12-30 to 2026-08-27 PT).