A Practical Guide to Website Speed and Core Web Vitals

Every second your website makes someone wait, you are quietly losing money. That is not a scare line, it is just what happens when you watch enough real traffic. A visitor taps your link on a crowded bus in Lagos, the phone is a two-year-old Android on a wobbly 3G signal, and your homepage is trying to load eight fonts, a slideshow, three chat widgets and a hero image the size of a small movie. They wait. They wait a bit more. Then they are gone, back to the search results, on to a competitor whose site simply opened.

Speed is not a vanity metric. It is the difference between a browser who becomes a buyer and one who never sees your offer. And here is the part most business owners miss: the speed that matters is not the speed you feel opening your own site on office WiFi. It is the speed a real customer feels on a mid-range phone, on mobile data they paid for by the megabyte, in a place where the network drops for no reason. That is the site you actually run, and this guide is about making it fast.

We will keep it plain. You do not need to be an engineer to follow along, though if you have a developer, this gives you the right words to hold them accountable. We will cover why speed drives conversions and rankings, what Core Web Vitals really measure, why sites get slow, and a practical order of operations for fixing them. There is a checklist at the end you can hand to anyone.

Why website speed decides who buys and who bounces

Think about your own behaviour. When a page hangs, you do not sit patiently admiring the spinner. You get irritated, assume something is broken, and leave. Multiply that across thousands of visitors and you get a measurable dent in revenue. Slow sites bleed customers at every step: fewer people wait for the page, fewer of those scroll to the offer, and fewer still finish a form or a checkout because each tap feels laggy.

The drop-off is not gentle either. The first few seconds are brutal, and the visitors you lose there are often the ones with the weakest connections, which here is a very large slice of your audience. A fast site is quietly inclusive: it lets the person on a cheap phone and a shaky signal do business with you as easily as the person on fibre.

There is a second reason speed matters, and it compounds the first: search engines care. Page performance is a genuine ranking signal. When two businesses offer similar things, the faster, smoother site tends to win the higher position, and the higher position brings more traffic, which a fast site then converts better. Slowness costs you twice, at the search result and again on the page. Speed pays you twice in the same two places.

The fastest page is not the one with the most powerful server. It is the one that sends the least stuff. Almost every slow site is slow because it is doing too much, not because it is hosted on something too weak.

What Core Web Vitals actually are

Core Web Vitals are a small set of measurements that try to capture how a page feels to a real human, not how it looks on a spec sheet. Instead of one vague "speed score," they break the experience into three honest questions: Did the main content show up quickly? Did the page respond when I tapped? Did things stay still while I was using them? Each question has its own metric.

What makes these useful is that they are measured from real visitors, on real devices and networks, over time, which is closer to the truth than a single test from a fast machine. Here is each one in plain language, with its general target.

LCP — Largest Contentful Paint (loading)

LCP measures how long it takes for the biggest, most important thing on the screen to appear. Usually that is your hero image, a big headline, or a banner. It answers the visitor's first silent question: "Is this page loading, or is it dead?" You are aiming for the largest element to appear within about 2.5 seconds. Under that feels responsive. Push past four seconds and it feels broken, and people leave before your content ever arrives.

LCP is usually hurt by heavy images, slow server response, and render-blocking code that makes the browser wait before it can draw anything. It is the metric most Nigerian sites fail first, almost always because of oversized images.

INP — Interaction to Next Paint (responsiveness)

INP measures what happens after the page has loaded and the visitor starts using it. They tap a button, open a menu, add an item to the cart. How long before the screen visibly responds? A snappy site reacts almost instantly. A janky one freezes for a moment while the phone struggles to catch up, and that hesitation makes people tap again, get confused, and lose trust. Aim to keep interactions responding within about 200 milliseconds.

INP is mostly a JavaScript problem. When too much code is trying to run on the phone's processor at once, the browser cannot respond to taps quickly. This hits low-end phones hardest, because they have less processing power to spare. A site that feels fine on your iPhone can feel like wading through mud on a budget Android, and that budget Android is what most of your customers are holding.

CLS — Cumulative Layout Shift (visual stability)

CLS measures how much the page jumps around while it loads. You have felt this: you go to tap a link, an image finishes loading above it, everything shoves down, and your finger lands on the wrong thing, maybe an advert you never meant to open. That annoyance is layout shift, and it is measured as a score. You want it below about 0.1, which basically means "things stay where they were put."

CLS is caused by elements that arrive without a reserved space, images without set dimensions, fonts that swap and resize text, adverts and banners that push content around. It is often the cheapest of the three to fix, and fixing it makes a site feel dramatically more polished.

How speed is really experienced on African mobile networks

Here is where a lot of advice written elsewhere falls apart. Much of the mainstream guidance quietly assumes fast, cheap, unlimited internet and a recent phone. That is not the reality for most of your visitors, so let us be honest about the conditions your site actually runs in.

• The network is inconsistent. A visitor might have a strong 4G signal one minute and drop to 3G or worse the next, walking between rooms or riding through town. Your site has to hold up across that whole range, not just the best case.
• Data costs real money. Many people buy data in small bundles and watch it closely. A bloated homepage that burns 8 or 10 megabytes on a single visit is not just slow, it is expensive to the visitor. People genuinely avoid heavy sites to protect their data. A lean site is a courtesy they notice.
• The phones are modest. The typical device is not a flagship. It is a mid-range or entry-level Android with limited memory and a slower processor. Heavy JavaScript that runs fine on a developer's laptop can choke on these phones, which is exactly why INP matters so much here.
• Latency is high. If your server sits far away, every single request carries a delay just from the distance. A page that needs dozens of separate requests pays that delay over and over. Fewer requests and content served closer to the user both help enormously.

The practical takeaway is simple: test your site the way your customers experience it. Open it on a real, ordinary phone, on mobile data, ideally throttled, not just on the fast connection in your office. What feels instant to you on WiFi might take fifteen frustrating seconds for the person you are trying to sell to. Until you have felt that, you are optimising blind.

Why sites get slow in the first place

Slowness is rarely one big villain. It is usually a pile of small ones that add up. When I audit a struggling site, the same culprits show up again and again, in roughly this order of impact.

Heavy, unoptimised images

This is the number one cause, and it is not close. Someone uploads a photo straight from a phone camera or a stock library, a 4,000-pixel-wide, four-megabyte image, and the site displays it in a little box. The browser still has to download the whole enormous file. A page with five or six of these can weigh more than ten megabytes, and every one of those megabytes has to crawl down a mobile connection before the visitor sees the page. Images alone can make or break your LCP.

Too much JavaScript

JavaScript is the code that makes pages interactive, but it is heavy in two ways. It has to be downloaded, and then it has to be executed by the phone's processor. Modern sites, especially those built on page builders and stuffed with plugins, often ship far more JavaScript than they use. All that code competes for the phone's limited power, which is what wrecks INP and makes taps feel sluggish. More features almost always means more JavaScript, and more JavaScript almost always means a slower phone experience.

Slow or crowded hosting

Cheap shared hosting puts your site on a server with hundreds of other sites, all fighting for the same resources. When a neighbour gets a traffic spike, your site slows down too. On top of that, if the server is physically far from your visitors, every request drags. A slow server response time delays everything else, because the browser cannot even begin until the server answers. Good hosting will not fix a bloated site, but bad hosting will sabotage even a lean one.

No caching

Without caching, your server rebuilds the entire page from scratch for every single visitor, every single time, even when nothing has changed. That is wasteful and slow. Caching lets the server, and the visitor's browser, keep a ready-made copy so repeat work disappears. A site without caching is doing hard labour on every visit for no reason.

Third-party scripts

These are the bits of code you paste in from other companies: analytics, chat widgets, social feeds, advertising pixels, embedded videos, font services. Each one reaches out to another company's server, and you have no control over how fast that server responds. Load ten of them and you have handed your page's speed over to ten strangers. They are also a common, sneaky cause of layout shift and slow interactions. Most sites carry two or three they no longer even use.

None of these is exotic. They are ordinary decisions, made one at a time, that compound into a slow site. The good news is the same is true in reverse.

A practical step-by-step to diagnose and fix a slow site

Do not fix things at random. That is how people spend a week tweaking something that saves 40 milliseconds while ignoring the four-megabyte image that costs ten. Work in order of impact, using the sequence below.

1. Measure the real starting point. Before you change anything, test the site on a mobile profile, on a throttled connection, and write down the numbers. You need a baseline, otherwise you will never know whether your changes helped or hurt.
2. Find the biggest thing on the page. Identify what your LCP element actually is, usually the hero image or main banner, and how big it is in kilobytes. This is almost always where the largest single win hides.
3. Weigh the whole page. Look at the total size of everything the page downloads and how many separate requests it makes. A homepage over a few megabytes, or with well over a hundred requests, is carrying fat you can trim.
4. Separate images from scripts. Break the total down. If images dominate, start there. If JavaScript dominates, your responsiveness problem lives there. Knowing the split tells you which chapter of this guide to act on first.
5. Fix images first. It is the highest-impact, lowest-risk change on almost every site. We will cover exactly how below.
6. Turn on caching. Often a single setting or plugin, and it helps every visitor immediately with little risk.
7. Audit third-party scripts. List every external script and justify each one. Remove what you do not use. Delay what is not needed immediately.
8. Then chase JavaScript and fonts. These are more delicate and better handled by a developer, but by this point you have already captured most of the win.
9. Measure again. Re-test on the same mobile profile and compare against your baseline. Keep what helped, revert what did not, and move to the next item.

That order matters: the early steps are cheap, safe and high-impact, while the later ones are riskier. Get the easy 70 percent first, and do not let anyone talk you into deep code surgery before the images are sorted.

Image optimization, the single biggest win

If you do nothing else in this guide, do this. Images are usually the heaviest part of a page and the easiest to fix without touching code. There are four moves, and together they can cut a page's weight by more than half.

• Resize before uploading. Never upload a 4,000-pixel image to display it at 800 pixels. Resize it to roughly the size it will actually be shown. This alone often shrinks a file by 80 or 90 percent. A photo does not need to be bigger than the space it lives in.
• Compress sensibly. Compression removes data the eye cannot really see. A well-compressed image can be a fraction of the original size with no visible difference on a phone screen. Run your images through a compression tool before they go live, and make it a habit for everything new.
• Use modern formats. Newer image formats are built to be far smaller than the old JPEG and PNG at the same quality. Serving images in a modern format is one of the cleanest ways to cut weight, and most decent platforms can do it automatically once you switch it on.
• Always set width and height. Tell the browser how big each image will be before it loads. This reserves the space so nothing jumps around when the image arrives, which directly protects your CLS. It costs nothing and it makes the page feel calm.

Caching, CDNs, and the finer tuning

Caching is the art of not repeating work. Once you understand the idea, it is obvious why it helps so much. There are two layers of it, and you want both.

Server and page caching

When someone visits a page, the server often has to assemble it from scratch, pulling from the database, running code, building the HTML. Page caching saves a finished copy of that page so the next visitor gets the ready-made version instantly, no rebuilding required. For a site whose content does not change every second, which is nearly all business sites, this is a large, safe, immediate win. On most common platforms it is a single plugin or a setting your host provides.

Browser caching

Browser caching tells a visitor's phone to hold on to files it already downloaded, your logo, your styling, your scripts, so that on the next page or the next visit it reuses them instead of downloading them again. For repeat visitors this makes the site feel almost instant, and it saves them data, which they will appreciate whether they consciously notice or not.

A CDN, serving content closer to home

A CDN, a content delivery network, keeps copies of your files on servers spread across many locations, so a visitor is served from somewhere physically closer to them rather than from one distant origin. That shorter distance cuts the delay on every request. For a Nigerian business whose hosting sits overseas, a CDN can meaningfully sharpen load times, and it absorbs traffic spikes gracefully so a sudden rush does not knock your site over.

The combination is powerful. Caching means the work is done once instead of every time, and a CDN means the result is delivered from nearby. Neither requires rewriting your site, and both are among the best returns on effort in the whole game. Once images and caching are handled, a few more techniques squeeze out the remaining slowness. These are a little more technical, so this is where a developer earns their keep.

Lazy loading

Lazy loading means the browser only loads images and videos as the visitor scrolls near them, instead of downloading everything the moment the page opens. Why download the ten images at the bottom of a long page before the visitor has even seen the top? Lazy loading defers that work, so the first screen appears fast and the rest arrives just in time. It is especially valuable on long, image-heavy pages and on slow connections. One caution: do not lazy-load your main hero image, because you want that one to appear as fast as possible. Load it eagerly, lazy-load the rest.

Fonts

Custom fonts make a brand look polished, but they carry hidden costs. Each font file must be downloaded before the text can display in that style, and while the browser waits, visitors either see nothing or see the text jump when the font finally swaps in, which hurts your CLS. Keep fonts under control.

• Use fewer fonts and fewer weights. Every additional font family and every bold or italic variation is another file to download. Two well-chosen fonts are plenty for almost any brand. Trim the rest.
• Let text show immediately. Configure fonts so the browser displays readable text right away using a system font, then swaps to your brand font once it loads. Waiting visitors can still read; they are never staring at blank space.
• Host or serve fonts efficiently. Fonts pulled from a distant external service add another round trip to a stranger's server. Serving them efficiently, and only in the character sets you need, keeps them light.

Trimming JavaScript

This is the deepest water, and the place to lean on a competent developer, but the principles are straightforward. Ship less code. Remove plugins and features you do not truly use. Delay non-essential scripts so they load after the page is usable rather than blocking it. Split large bundles so the browser only downloads what a given page needs. Every kilobyte of JavaScript you avoid sending is a kilobyte the phone does not have to download and, more importantly, does not have to run. On the low-end phones your customers carry, that saved processing is often what turns a janky feel into a smooth one.

Measuring, and what the tools are really telling you

You cannot improve what you do not measure, but you also should not drown in numbers. Performance tools come in two flavours, and you want to understand both.

Lab tests run your page in a controlled, simulated environment and give you a score plus a detailed list of what is slowing things down. These are excellent for diagnosis, because they hand you a prioritised to-do list: this image is too big, this script is blocking, this element has no dimensions. They are repeatable, which makes them perfect for testing whether a change helped. The catch is that a lab test is a simulation, not a real visitor.

Field data is the opposite. It gathers Core Web Vitals from your actual visitors, on their real phones and networks, over weeks. It is the truth about how your site feels in the wild, across the full messy range of devices your audience uses. It is slower to react, because it needs real traffic to accumulate, but it is the scoreboard that ultimately counts.

Use them together. Lean on lab tests to find and fix problems quickly, and watch field data to confirm real visitors are feeling the improvement. And whatever tool you use, always test on a mobile profile with a throttled connection. A perfect desktop score means little when your customer is on a budget phone and a thin signal.

A gentle warning about scores: do not chase a perfect number for its own sake. The goal is a site that feels fast to real people and converts them into customers. Optimise for the human, not the dashboard.

A realistic performance checklist

Here is the whole thing distilled into a list you can work through, or hand to whoever manages your site. It is roughly ordered from highest impact and easiest, to more technical and specialised. You do not need to do all of it in a day. Start at the top and work down.

1. Test on a real phone first. Open your site on an ordinary Android, on mobile data, throttled if you can. Note how it feels and record your baseline numbers before touching anything.
2. Fix your images. Resize before uploading, compress everything, switch to a modern format, and always set width and height. This is the single biggest win on most sites.
3. Turn on page caching. Usually one plugin or one host setting. Immediate, safe, helps everyone.
4. Enable browser caching. Let repeat visitors reuse files they already have. Faster returns, less data burned.
5. Audit third-party scripts. List every external script, remove the ones you do not use, and delay the ones that are not needed instantly.
6. Add lazy loading. Defer off-screen images and videos, but keep your main hero image loading eagerly.
7. Tame your fonts. Fewer families and weights, let text show immediately, serve them efficiently.
8. Consider a CDN. Especially if your hosting is far from your visitors or you are reaching across regions.
9. Review your hosting. If your server response is consistently slow even on a lean, cached site, the hosting itself may be the bottleneck.
10. Trim JavaScript. With a developer, remove unused code, delay non-essential scripts, and ship only what each page needs.
11. Reserve space for everything. Give images, adverts and embeds fixed dimensions so nothing jumps. Protects your visual stability.
12. Measure again and repeat. Re-test on the same mobile profile, compare to your baseline, keep what worked, and make speed a habit rather than a one-off project.

Final word, and where to get help

Website speed is not a vanity project. It is one of the most direct, unglamorous levers you have on both your search visibility and your sales, and it matters more here than almost anywhere, because your visitors are doing business with you on modest phones, expensive data and networks that come and go. A fast site respects all of that. It says, without a word, that you value the person on the other end.

The encouraging truth is that most slow sites are slow for boring, fixable reasons, oversized images, no caching, a heap of scripts nobody uses, and you can recover a great deal of speed without spending big or rebuilding anything. Start with the images. Turn on caching. Cut the dead weight. Then measure on a real phone and keep going. Aim for good on all three vitals and your visitors will feel the difference long before they can name it.

If all of this sounds sensible but you would rather have someone who does it every day take it off your hands, that is exactly the kind of work we handle at Rahmontech Enterprises. We build and tune fast, dependable websites for African businesses, with the local realities of network, device and data baked into every decision, so your site opens quickly for the customers you are actually trying to reach. However you go about it, treat speed as an ongoing habit, not a one-time fix. Your rankings, and your revenue, will thank you for it.