PageSpeed Insights is Google’s free tool for testing how fast a web page loads. You paste a page address, and it shows two things: how real visitors on Chrome experienced the page over the last 28 days, and a simulated lab test with a score from 0 to 100. For a Kenyan business, read the Mobile tab first and focus on three timings: the main image or heading should appear in 2.5 seconds or less, taps should respond in 200 milliseconds or less, and the page should not jump around while it loads.
About 1,000 people a month in Kenya search for “pagespeed insights”, and about 2,400 search “google speed test” (Rank.ke keyword data, October 2026). Most of your visitors are on phones, often on mobile data, so speed decides whether they wait or leave. This post shows how to read the report, the five fixes that matter most, and how to test again.
What the score means and what it does not
The big number at the top of the report is the Lighthouse performance score. Google’s documentation (opens in a new tab) says a score of 90 or above is good, 50 to 89 needs improvement, and below 50 is poor.
Two cautions before you chase it:
- It is a lab test. Lighthouse loads your page once in a controlled setting. Real visitors on real connections will not match it exactly, and scores change a little between runs.
- It is not a ranking guarantee. Google says Core Web Vitals are used by its ranking systems (opens in a new tab) and recommends good scores, but good scores do not ensure top rankings. It also says that trying to get a perfect score just for SEO reasons may not be the best use of your time, and that relevant content can rank even when page experience is weak. Page experience matters most when many helpful pages compete for the same search.
So the score is a guide. A slow page costs you visitors directly. Treat that as the main reason to fix it.
Phone versus computer results
PageSpeed Insights has a Mobile tab and a Desktop tab. They test differently. The mobile test simulates a mid-tier phone on a mobile network. The desktop test uses an emulated computer on a wired connection.
Always read Mobile first, for two reasons. Google uses the mobile version of your pages to index and rank them. And most Kenyan visitors reach a site from a phone. A site can score 95 on desktop and far lower on mobile, because a computer with a fast connection hides problems that a mid-range Android on 4G, or on a weaker signal outside town, will feel.
How to read the report
Run it now on your homepage and on your two most important pages. Follow these steps.
- Go to pagespeed.web.dev and paste the full address of the page.
- Press Analyze and wait about half a minute.
- Open the Mobile tab. You should see a section about real users, then a score circle, then a list of issues.
- Look at the real-user section first. It shows Core Web Vitals from the Chrome User Experience Report, a collection of data from Chrome users over the previous 28 days. It says Passed or Failed.
- Then look at the score and the opportunities and diagnostics below it.
- Run the test three times and note the middle result.
If you see no real-user data, that is normal for a small site. Google falls back to data for the whole site, and if there is not enough of that either, it shows nothing. The lab score still works.
The three numbers that decide a pass are Google’s Core Web Vitals (opens in a new tab), measured at the 75th percentile of visits, which means three in four visits were at least this good, split by phone and computer:
| Measure | What it means | Good |
|---|---|---|
| Largest Contentful Paint (LCP) | When the biggest thing on screen, usually a photo or heading, appears | 2.5 seconds or less |
| Interaction to Next Paint (INP) | How quickly the page reacts after a tap or click | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | How much the page jumps while loading | 0.1 or less |
A page passes only if it meets all three. You can also see these for your whole site in the Core Web Vitals report in Google Search Console.
The five fixes that matter most
On most small business sites in Kenya, these fixes give the biggest gain. Do them in this order.
- Shrink your images. A photo straight from a phone camera can be several megabytes. Resize it to the size it is shown at, compress it, and save it as WebP or AVIF, which Google’s web.dev guidance on the largest image (opens in a new tab) recommends over older formats. This is usually the single biggest win.
- Do not delay the main image. The big picture at the top of a page is usually the LCP element. web.dev says never to lazy-load it, and to make it easy to find in the page so the browser fetches it early. Lazy-load the images lower down instead.
- Remove what you do not use. Every plugin, chat widget, tracker and pop-up adds files the phone must download. If you have three tracking tools doing the same job, keep one. On WordPress, deactivate and delete plugins you do not need.
- Fix the server delay. Before a page can show anything, the server must reply. According to web.dev, this time to first byte is about 40% of a well-optimised LCP. Slow shared hosting, a server far from Kenya or no caching all add to it. Turn on caching, and if the delay stays high, ask your host about it or move.
- Stop the page jumping. Give every image and advert a set width and height so the browser leaves room for it. Without that, the text moves when the picture arrives and a visitor taps the wrong button.
A sixth tip for INP: heavy JavaScript makes taps feel slow. If a page feels sluggish after it appears, look at the scripts first.
Images, hosting and plugins on Kenyan sites
A few Kenyan situations come up again and again.
- Product galleries on WordPress or Shopify shops. A shop with 40 product photos on one page can send 40 large files to a phone. Show 12 and load more on request, and compress every upload.
- A hero image or slider on the homepage. Sliders are heavy. A single well-sized photo is faster and usually converts as well.
- Embedded videos. A YouTube embed loads a lot of code. Use a thumbnail that opens the video when tapped.
- Hosting. Where your server sits changes how far each request travels. Test the server delay and compare. Do not pay for a bigger plan before you have fixed the images, because the images are usually the problem.
- Data bundles. A heavy page uses a visitor’s data. A light page is kind to the person paying for it, and that is a reason to keep it light even when Google would not notice.
Fix one thing, test again, and keep a note of the before and after. After a week or two, look at Search Console and at your enquiries. For the wider picture of what to fix on your site and in what order, read our complete guide to SEO in Kenya, and for the first steps of marketing a small business online, see how to market your business online in Kenya. Once your pages are fast, SEO content writing helps them rank, and our guide on checking where your website ranks on Google shows how to see the result.
Test phone and computer in one go
PageSpeed Insights tests one page and one device at a time. Rank.ke’s Speed test, one of the Site tools under Site audit, runs the phone and the computer test together and lists the fixes in plain English. It uses no credits and is on every plan, including Free. The Health check, in the same place, looks at one page across five groups: search, tech, AI readiness, trust and speed. The Google Search Console page in Rank.ke shows your own search data, but the Core Web Vitals report itself stays in Search Console.
Check your brand on Rank.ke (opens in a new tab), open Site audit and run the Speed test on your homepage. It takes about two minutes, and you will see the phone and computer results side by side.
Try Speed test on your own brand.
There is a Free plan, so you can start without paying.