PageSpeed Insights explained for business owners.

What the report is telling you

PageSpeed Insights puts two different measurements on one page, and most confusion comes from mixing them up:

• The top part shows how the page performed for real visitors in Chrome over the last 28 days, with a Core Web Vitals assessment that passes or fails.
• The lower part is a test Google runs while you wait, with a tool called Lighthouse. It loads the page once on a simulated phone and gives the score from 0 to 100, plus a list of problems it found.

The top part answers "how does this page feel to the people who visit it". The lower part answers "what is slowing this page down in a test". When they disagree, believe the top part about how visitors feel, and use the lower part to find causes.

Both parts come in two versions, one for mobile and one for desktop, chosen with the tabs at the top. Mobile is the one to read, because many visitors to a small business site arrive on a phone, often from a search or an ad, and the mobile test is the harsher of the two.

The top part: real visitors

This data comes from the Chrome User Experience Report, built from Chrome users who share usage statistics with Google. It covers 28 days, and each number shows the experience of the slowest quarter of visits: three visits in four were at least that good. Google reports it that way so a page cannot pass while a large share of visitors has a bad time. Safari users and Chrome on iPhones are not counted at all, so on a site whose visitors mostly use iPhones the figures describe a minority of them.

Three of the numbers are the Core Web Vitals, and Google sets a threshold for each:

• Largest Contentful Paint (LCP): how long until the main content, usually the big photo or the headline, appears. Good is 2.5 seconds or less.
• Interaction to Next Paint (INP): how quickly the page responds when someone taps a button or opens a menu. Good is 200 milliseconds or less.
• Cumulative Layout Shift (CLS): how much the page jumps around while it loads, the kind of jump that makes you tap the wrong button. Good is 0.1 or less.

The page passes the assessment when all three are good. If there is not enough data for INP, LCP and CLS decide on their own. The report also shows First Contentful Paint and Time to First Byte, which help explain a slow LCP but are not part of the pass.

If one page has too few visits, the report shows figures for your whole site instead. If the whole site has too few, this part is empty. That is normal for a small business, and it does not mean anything is wrong. You then work from the lab test and a real phone.

The lower part: one test on a simulated phone

Lighthouse loads the page once from Google's servers, pretending to be a mid-range phone on a slow mobile connection. That pretence is why the mobile score is lower than the desktop score for the same page, and why your own phone on office Wi-Fi feels faster than the score suggests.

The score is coloured green from 90 to 100, amber from 50 to 89 and red below 50. It is a weighted mix of five lab measurements. Total Blocking Time carries the most weight: how long the page is too busy running scripts to respond. LCP and CLS come next, then First Contentful Paint and Speed Index.

That weighting explains a lot on small business sites. Chat widgets, booking embeds, tracking tags and review carousels all run scripts, and scripts are what Total Blocking Time measures, so a page can show its photo quickly and still score badly.

The score also moves between runs without anything changing on your site. Google's Lighthouse documentation blames network routing, ads and tests on the page, and the machine doing the test, and suggests treating the score as a range rather than a single number. Run each page three times and use the middle result.

Which numbers Google uses for search

Google says its ranking systems use Core Web Vitals, and those are measured from real visits, the top part of the report. The lab score is a tool for finding problems, not the number search uses.

Google also says plainly that there is no single page experience signal, that it shows the most relevant page even when its experience is poor, and that chasing a perfect score just for search may not be the best use of your time. A good experience helps most when several pages answer the search equally well.

For an owner that means: a page that answers the search well and scores 60 can beat a page that scores 100 and answers it badly. Speed still matters, because a visitor who waits on a blank screen leaves whatever your ranking. But the reason to fix speed is the visitor, and the evidence that you fixed it is real-visitor data, not the lab score.

If your site is not showing up in search at all, speed is rarely the reason. Start with why your website is not on Google.

Why 100 is not the goal

The lab score punishes things that earn their place. A booking widget brings bookings. A chat answers the question that stops someone enquiring. A map helps people find you. Each one lowers the score, and taking them out for a better number can cost you customers.

The last points are also the most expensive. Going from red to a high amber usually means fixing images and fonts, which is quick. Going from 90 to 100 often means removing or rebuilding features, which is slow and rarely changes what visitors feel.

A sensible target for a small business:

• Pass the Core Web Vitals assessment where the report has real-visitor data.
• In the lab test on mobile, a green score or a high amber one on the pages that bring enquiries: the home page, the main service pages, the booking page and any ad landing page.
• No large problems left in the list under the score.
• On your own phone, over mobile data, the headline and the main button appear quickly and nothing jumps.

What usually slows a small business site

The same few causes turn up again and again, roughly in this order:

• A huge photo at the top, uploaded straight from a camera or phone at several thousand pixels wide. It is usually the LCP element, so it decides the main number.
• A slideshow or video at the top, which loads several large files before anything settles.
• Web fonts: several families and weights, text that stays invisible until they arrive, and a jump when they replace the fallback font.
• A chat widget that loads a large amount of script on every page, before anyone has asked to chat.
• A booking widget embedded on every page, which brings the booking tool's own scripts and styles with it.
• An embedded map, a social media feed or a reviews carousel on the home page.
• Tracking tags from past campaigns: pixels, heatmaps and old analytics nobody reads.
• A heavy cookie banner, sometimes large enough to count as the page's main content.
• A slow server: cheap shared hosting, no caching, or a page builder that sends far more code than the page needs.

Most of these were added one at a time, each for a good reason. Together they make the page slow.

How to read the list of problems

Under the score, the report lists insights and diagnostics, each with the files involved and often an estimate of the time it would save. Do not try to clear them all. Read them in this order:

• Find which element is the LCP element. The report names it, often the top photo, and breaks its time into parts: the server's response, the wait before the photo starts loading, the loading itself and the wait before it appears. The biggest part tells you where to work.
• Look for files that block the first paint: stylesheets, fonts and scripts the browser must fetch before it shows anything.
• Read the list of third-party code. It names each outside company whose scripts load, such as a chat, booking, map or tracking provider, and how much time each costs.
• Check the image items: photos larger than they are shown, or in older formats.
• Check what causes layout shifts: images without set sizes, banners that push the page down, fonts that swap late.

Skip items that promise tiny savings. An item that saves a fraction of a second on a file nobody waits for is not worth a developer's afternoon.

Fixes in the order that pays

Work through these on the pages that bring enquiries, then test again:

• Resize the top photo to the largest size it is shown at, save it as WebP or AVIF, and make sure it is not set to load lazily. Google's own guidance says never to lazy-load the LCP image. Ask your developer to mark it as high priority.
• Replace a slideshow or video at the top with one good photo.
• Use one or two font families with only the weights you need, served from your own site, with text shown in a fallback font at once.
• Load the chat only when someone taps the chat button, or after the page has finished loading. A button that looks like the chat and loads it on tap costs almost nothing.
• Put the booking widget on the booking page only. Everywhere else, a button that opens it.
• Swap the embedded map for an address that opens the visitor's maps app, and drop the social feed.
• Remove tracking tags you no longer use.
• Give every image and embed its size in advance, so the page does not jump.
• If the server's response is slow, turn on caching, then look at better hosting.

Lazy loading is right for photos further down the page, which then load as the visitor scrolls. It is wrong for the photo at the top. The fix most often missed is that one setting.

A worked example: a barbershop's home page

A three-chair barbershop has a home page with a video at the top, the booking tool's widget embedded under it, an Instagram feed, a Google map and a chat bubble. The mobile test comes back red. The top part of the report is empty, because the shop's site has too few visits for real-user data.

The list under the score tells the story. The LCP element is the video's first frame. Third-party code from the booking tool, Instagram, Google Maps and the chat provider runs before anything responds to a tap. Two font families arrive late and the headline jumps when they do.

The changes:

• One resized photo of the shop replaces the video, set to load first.
• A "Book a chair" button opens the booking tool's own page instead of the embedded widget.
• Three photos of recent cuts, saved small, replace the Instagram feed, with a link to the account.
• The address, as a link that opens the visitor's maps app, replaces the map.
• The chat loads when someone taps its button.
• One font family instead of two.

Tested three times again, the page shows its main content much earlier and most of the third-party list is gone. Bookings still go through the same booking tool, one tap later. For more on what a shop like this needs on the page, see salons and spas.

Check what real visitors get

Search Console has a Core Web Vitals report built from the same real-visitor data, grouping your pages into good, needing improvement and poor, for mobile and desktop. Like PageSpeed Insights, it shows nothing when a site has too few visits.

After a fix, the top part of PageSpeed Insights takes weeks to catch up, because it covers the last 28 days. Judge a change by the lab test and your own phone straight away, and by the real-visitor data a month later.

Test on a real phone too, over mobile data rather than the office Wi-Fi, from inside the Instagram or Facebook app if you run ads, as before you run ads explains. The score cannot tell you that a cookie banner covers the button, or that the phone number does not start a call when tapped.

When to stop, and when to get help

Stop when the page passes the Core Web Vitals assessment, or, without real-visitor data, when the mobile test is green or high amber and your phone shows the headline and the button quickly. More points after that rarely bring more customers.

You can do the image and font fixes yourself on most website builders. Get help when the report points at the server, the theme or a page builder, when a widget needs to load on tap, or when the site is so heavy that patching it costs more than rebuilding. In that case, see how a website redesign keeps what already works.

Ad landing pages deserve the most care, because every slow second is paid for: see landing pages for ads. Every page we build is designed for phones first and checked for speed before launch, as part of websites. The page-by-page basics are in what a small business website needs.