Your website loads instantly on the office fiber connection, so it is easy to assume everyone else sees the same thing. They don't. Most of your visitors in Kenya arrive on a phone, often a mid-range Android, over mobile data that can swing from fast to sluggish between Westlands and the matatu ride home. Heavy pages lose people before they read your offer. Google measures this experience with metrics called Core Web Vitals. This guide explains what they mean in plain English, how to measure them properly, and how to fix the problems that most often slow Kenyan business websites down.
The real conditions your visitors browse in
Speed is the result of your site meeting a specific device on a specific network. For a typical Kenyan audience, that looks very different from a developer's laptop.
Mobile data is the default, not the exception
Many people browse on prepaid bundles and watch every megabyte. A homepage that downloads several megabytes of images, video and scripts costs them real money and patience. Signal quality also varies by location and time of day, so a page that is "fine" in town can crawl upcountry.
Mid-range phones do the heavy lifting
Download size is only half the story. Once the files arrive, the phone's processor has to run the JavaScript, build the layout and paint the page. Mid-range Android devices have far less processing power than laptops, so script-heavy sites feel sluggish even on a good network. When you test, test like your customers browse.
What Core Web Vitals actually measure
These are three metrics Google uses to describe real-world user experience: how fast the main content appears, how quickly the page responds to input, and how stable the layout is. Google publishes the definitions and thresholds in its official Web Vitals documentation on web.dev. A page passes when at least 75% of visits meet the "good" threshold for each metric.
Largest Contentful Paint (LCP): loading
LCP measures how long it takes for the largest visible element, usually a hero image, banner or main heading block, to render. Google considers 2.5 seconds or less good. Slow servers, oversized images and render-blocking files are the usual culprits.
Interaction to Next Paint (INP): responsiveness
INP measures how quickly the page visually responds after someone taps, clicks or types, looking across interactions during the whole visit rather than just the first one. A good INP is 200 milliseconds or less. INP replaced First Input Delay (FID) as the responsiveness metric in 2024, so if you see FID in older guides or reports, it is no longer the metric that counts. Poor INP almost always comes from too much JavaScript keeping the phone's main thread busy.
Cumulative Layout Shift (CLS): visual stability
CLS measures how much content unexpectedly jumps around while the page loads, like a button moving just as you tap it because an ad or image loaded above it. A good score is 0.1 or less. Missing image dimensions, late-loading banners and web fonts swapping in are common causes.
How to measure your site properly
Before fixing anything, get an honest baseline.
Field data vs lab data
Field data comes from real Chrome users visiting your site, collected in the Chrome User Experience Report. It reflects actual devices and networks, and it is what Google uses to assess Core Web Vitals. Lab data comes from a simulated test run (Lighthouse) on a set device and connection. Lab data is excellent for diagnosing problems and checking fixes instantly, but it is not your customers' reality.
PageSpeed Insights
Paste a URL into PageSpeed Insights and you get both views on one page: field data at the top (if your site has enough traffic to be included) and a Lighthouse lab report below, with specific opportunities and diagnostics. Always check the mobile tab first, because that is where most Kenyan visitors are.
Search Console's Core Web Vitals report
If your site is verified in Google Search Console, the Core Web Vitals report groups similar URLs and labels them good, needs improvement or poor for mobile and desktop, using field data. It is the best way to spot site-wide patterns, such as every blog post failing CLS because of the same template.
Why your website is slow: the common causes
The same handful of problems appears again and again.
- Heavy images. Photos uploaded straight from a camera or phone, often several megabytes each, displayed at a fraction of their size. This is the single most common cause of poor LCP.
- Page builders. Drag-and-drop builders make editing easy but often add layers of nested markup, large CSS files and scripts to every page, whether a page uses those features or not.
- Too many plugins. Each WordPress plugin can add its own scripts, styles and database queries.
- Slow hosting and high TTFB. Time to First Byte is how long the server takes to start responding. Underpowered shared hosting, no caching, or a server located far from your audience delays everything that follows.
- Render-blocking scripts and styles. CSS and JavaScript loaded in the page head can stop the browser from showing anything until they finish downloading and running.
- Third-party tags. Chat widgets, tracking pixels, embedded maps, video players and multiple analytics tools each load code from other servers you do not control, and they are frequent causes of poor INP.
How to fix Core Web Vitals, in priority order
Work from the biggest, cheapest wins downward.
- Fix images first. Resize images to the size they are actually displayed, compress them, and serve modern formats like WebP or AVIF. Lazy-load images below the fold, but never lazy-load the main hero image, since that delays LCP.
- Reserve space for everything. Set width and height (or an aspect ratio) on images, videos and embeds, and reserve space for banners and ads. This is the most direct fix for CLS.
- Turn on caching and reduce TTFB. Use page caching so the server is not rebuilding every page for every visitor, and enable object caching where your host supports it.
- Audit plugins and third-party tags. Remove anything you do not use. Load chat widgets and non-essential tags only after the main content, or only on the pages that need them.
- Tackle render-blocking resources. Defer non-critical JavaScript, inline the small amount of CSS needed for the top of the page, and remove unused CSS where possible.
- Reduce JavaScript work for INP. Break up long tasks, cut unnecessary scripts, and avoid heavy animation libraries on mobile.
- Optimize fonts. Use fewer families and weights, and a font-display strategy that avoids invisible text and layout jumps.
- Reconsider the build. If a page builder or bloated theme is the root problem, a leaner rebuild may cost less over time than endless patching.
If you would rather hand this over, our website speed and Core Web Vitals optimization service works through exactly this list, measured against your real field data.
Hosting and CDN considerations for Kenyan audiences
- Server location matters. The physical distance between your server and your visitors adds latency to every request. Choose hosting with good connectivity to East Africa, or put a CDN in front of it.
- Use a CDN. A content delivery network stores copies of your images, CSS and JavaScript on servers in many locations, so visitors download them from somewhere nearby.
- Don't buy on price alone. The cheapest shared plans often pack many sites onto one server. If your TTFB is consistently slow even with caching on, the hosting itself is likely the bottleneck.
- Keep server software current. A supported PHP version, HTTP/2 or HTTP/3, and Brotli or Gzip compression all help.
Keeping your site fast after the fix
Speed decays. New plugins, uncompressed banners or a fresh tracking tag can undo months of work. Treat performance as part of routine upkeep, alongside updates and backups, as covered in our guide to website maintenance.
A simple monthly speed checklist
- Check the Core Web Vitals report in Search Console for new "poor" or "needs improvement" URLs.
- Run your top five pages through PageSpeed Insights on mobile.
- Review any plugins, scripts or tags added since last month.
- Spot-check recent uploads for oversized images.
- Test key pages on an actual mid-range Android phone using mobile data.
Speed problems are often tangled up with other technical issues like redirect chains, crawl waste and broken templates. A technical SEO audit looks at performance alongside indexing and site structure, so fixes support each other. Before any redesign goes live, run through our website launch checklist so speed is built in from day one.
Frequently asked questions
Do Core Web Vitals affect Google rankings?
Yes, they are part of Google's page experience signals, but relevance and content quality matter more. Good scores help you compete and, more importantly, keep visitors from leaving.
Why does PageSpeed Insights show no field data?
Field data only appears when Chrome has collected enough real visits to your page or site. Smaller sites may see lab data only; use it to find problems and test on real devices.
My Lighthouse score is high, so why am I failing Core Web Vitals?
Lighthouse is a simulation on one device and connection. Google's assessment uses field data from real visitors, so that is the number to improve.
Can I fix a slow WordPress site without rebuilding it?
Often, yes. Image optimization, caching, plugin cleanup and better hosting solve many cases. A rebuild only makes sense when the theme or page builder itself is the main source of bloat.
How long until I see improvements in Search Console?
Lab tools show changes immediately, but the field data behind Search Console is based on a rolling window of real visits, so expect several weeks before improvements fully show.
Make speed a business habit
A fast site respects your visitors' data, phones and time. Start with images and hosting, measure with field data, and keep checking. If you want a second pair of eyes on your site, book a discovery call and we'll walk through what is slowing your site down and what to fix first.
