Websites: cost, hiring and build
How to check your website speed, and what is worth fixing.
The score in the big circle is the least useful number on the page. Here is which numbers to read instead, what the thresholds are, and what usually slows a small business site down.
Your site probably feels fast to you. You load it on office Wi-Fi, on a recent phone, and your browser has most of it cached. A customer opening it for the first time on a mid-range phone with two bars of signal in a parking lot sees something different. Checking speed properly means measuring what they see, not what you see.
Run PageSpeed Insights
PageSpeed Insights is Google's free tool at pagespeed.web.dev. Paste a full address and run it. Start with the page that matters most for business, which is often not the homepage. For a service business it might be the main service page or the quote form; for a studio, the schedule.
The report defaults to mobile. Stay there. Most local searches happen on phones, and the mobile result is the harder test.
Field data versus lab data
The report has two halves, and they answer different questions.
| Field data (top) | Lab data (below) | |
|---|---|---|
| Where it comes from | Real Chrome users visiting your site, via the Chrome User Experience Report | A single simulated load run by Lighthouse |
| Time span | The previous 28 days | Right now, one run |
| Device | Whatever your real visitors used | A simulated mid-range phone on a mobile network |
| Good for | Knowing whether there is a real problem | Finding out why, and testing a fix |
Read the field data first. It is what your customers actually experienced. If your page does not have enough visits, PageSpeed Insights falls back to data for the whole site, and if the whole site does not have enough either, it shows no real-user data at all. That is common for small local businesses and is not a fault. It just means you rely on the lab section.
The lab score, the number in the circle, changes from run to run with normal variation. Do not chase a few points. Run it two or three times and look at the pattern.
The three Core Web Vitals and their thresholds
Google's Core Web Vitals are three measurements of how a page feels to use. The thresholds below are from web.dev at the time of writing (October 2026). A page passes when at least 75 percent of visits fall in the good range, measured separately on mobile and desktop.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | How long until the main content, usually the hero image or headline, appears | 2.5 seconds or less | Over 4 seconds |
| Interaction to Next Paint (INP) | How quickly the page responds when someone taps or clicks | 200 milliseconds or less | Over 500 milliseconds |
| Cumulative Layout Shift (CLS) | How much the page jumps around while loading | 0.1 or less | Over 0.25 |
Anything between good and poor is "needs improvement". INP replaced an older metric, First Input Delay, in 2024, so older guides that mention FID are out of date.
What usually makes a small business site slow
The causes are rarely exotic. The same handful turn up on most small business sites.
- Huge images. A photo straight off a phone or a stock library, several megabytes, displayed at the size of a postcard. This is the most common cause of a slow LCP and the cheapest to fix.
- Third-party widgets. Chat bubbles, booking embeds, review carousels, social feeds, heatmap tools and several tracking tags, each loading its own scripts. They hurt INP and LCP, and you often cannot speed them up, only remove or delay them.
- Heavy page builders and stacks of plugins, which load code for every feature on every page whether that page uses it or not.
- Sliders and autoplay video at the top of the page, which make the largest element big and slow.
- Slow hosting. If the server takes a long time to send the first byte, everything after it starts late. Cheap shared hosting and a server far from your customers both show up here.
- Images and embeds without set dimensions, and fonts or banners that load late and push content down. These cause layout shift.
What is worth fixing, and what is not
Fix in this order, because each step is cheaper than the next and usually does more.
- Resize and compress images, and serve modern formats such as WebP or AVIF. Most platforms can do this automatically once it is switched on.
- Remove any third-party script you cannot name a reason for. Then ask whether the rest need to load on every page, or only where they are used.
- Give images, video and embeds fixed width and height so the layout does not jump.
- Replace a slider or autoplay video at the top with a single, properly sized image.
- If the server is still slow to respond, look at caching, a content delivery network, or better hosting.
What is not worth doing is chasing a lab score of 100. A page that passes all three Core Web Vitals in the field is fast enough that further work rarely changes anything a customer would notice. Speed is one input among many in how Google ranks pages, and it will not lift a thin page above a useful one. The real reason to fix it is that slow pages lose people before they ever see your phone number.
Be careful with tools that promise a perfect score with one plugin. Some get there by delaying scripts in ways that break forms, booking widgets or tracking. After any speed change, test the form, the booking flow and the phone link by hand.
What to do next
Run PageSpeed Insights on mobile for your most important page. Read the field data first and note which of LCP, INP and CLS is outside the good range. Then work down the fix list above, starting with images and third-party scripts, and rerun the test after each change. Field data takes up to 28 days to reflect a fix, so judge it by the lab result first. You can do all of this yourself; Corsa Media House builds and maintains fast sites for Orlando and Central Florida businesses if you would rather not.
Questions
How do I check my website speed for free?
Use PageSpeed Insights at pagespeed.web.dev. Paste the full address of your most important page, keep the mobile tab selected, and read the field data from real users first, then the lab data from Lighthouse to see what is causing any problem.
What are good Core Web Vitals scores?
According to web.dev at the time of writing (October 2026): Largest Contentful Paint of 2.5 seconds or less, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, met by at least 75 percent of visits. Poor is over 4 seconds, over 500 milliseconds and over 0.25 respectively.
Why are field data and lab data different?
Field data is the previous 28 days of real Chrome users on whatever devices and connections they had. Lab data is one simulated load on a mid-range phone with fixed network conditions. Use field data to know whether there is a real problem and lab data to find the cause and test a fix.
Do I need a PageSpeed score of 100?
No. A page that passes all three Core Web Vitals in the field is fast enough that further work rarely changes anything customers notice. Chasing 100 with aggressive plugins can break forms, booking widgets and tracking, so test those by hand after any speed change.