Performance-First Development: Speed, Core Web Vitals & Why Load Time Is a Revenue Problem
Here's a number I want you to sit with: 53%.
That's the percentage of mobile users who abandon a website if it takes more than three seconds to load. Not three minutes. Three seconds. And on Nigerian networks — where 4G speeds fluctuate, where data costs real money, where plenty of people are still on 3G in parts of the country — three seconds is optimistic. The actual patience window is often closer to two.
I've run website audits for businesses that are genuinely confused about why their traffic isn't converting. They're spending money on Google Ads. The clicks come. People leave. The assumption is always that the offer is wrong or the copy isn't landing. Usually I open Chrome DevTools and the site takes six seconds to load on a mid-range device. That's the problem.
Speed is not a technical vanity metric. It's a revenue lever. This is how to actually pull it.
Core Web Vitals: What They Actually Measure
Google introduced Core Web Vitals as a ranking factor in 2021. For years, the SEO community debated how much weight they carried against content and backlinks. By 2026 the question is largely settled: they matter, they compound with other ranking signals, and they matter most in competitive search categories and for mobile-heavy audiences — which, in Nigeria, is most audiences.
The three metrics:
Largest Contentful Paint (LCP) measures how long it takes for the largest visible element — usually the hero image or main headline — to fully load. Google's threshold for "good" is under 2.5 seconds. Most unoptimised sites are in the 4-8 second range on mobile devices.
Interaction to Next Paint (INP) replaced First Input Delay in 2024. It measures how quickly the browser responds to user input: clicking a button, tapping a navigation item, submitting a form. A page with poor INP loads but feels laggy and unresponsive. The most common cause is too much JavaScript running on the main thread, competing with the browser's ability to respond to user actions.
Cumulative Layout Shift (CLS) measures visual instability — how much content moves after it initially renders. Bad CLS is the experience of being about to tap something on mobile and having it jump because an image or ad loaded above it. It's frustrating, it breaks trust, and it causes mis-taps that send users to places they didn't mean to go. Google's "good" threshold is a CLS score under 0.1.
These numbers are measurable, actionable, and directly affect both search visibility and user experience. A site that scores "good" on all three is fast. A site with "poor" scores is losing visitors before they've had a chance to see what you're offering.
Running a Performance Audit That Actually Tells You Something
Before you fix anything, you need to know what's actually slow. The most common mistake is running Lighthouse, seeing a low score, and trying to fix everything simultaneously. That's not how this works.
Lighthouse gives you a list of issues. Some will move the needle dramatically. Others are marginal. The skill is knowing which is which. Here's the audit process I use.
Start with PageSpeed Insights field data. Google's PageSpeed Insights tool (free, at pagespeed.web.dev) shows two types of data: lab data from a simulated device, and real user data collected from Chrome users. The real user data is more important. A site can score 80 in a lab test but have a median LCP of 6 seconds for actual users on actual devices with actual network conditions. That gap tells you something the lab test doesn't.
Identify the LCP element first. In the PageSpeed Insights report, you can see which specific element is causing the LCP time. This is where most of your effort should go. If the LCP element is an image, the fix is usually in image optimisation and loading strategy. If it's a text block, the cause is often render-blocking resources preventing the browser from displaying text quickly.
Read the waterfall. In Chrome DevTools, the Network tab shows every resource that loads on the page in sequence. You're looking for: large files at the top of the waterfall (blocking everything after them), render-blocking scripts in the wrong position, third-party requests that stall before returning, and font files loading late and causing content to be invisible until they arrive.
Measure Main Thread activity. The Performance tab in Chrome DevTools shows what the main thread is doing during page load. A main thread that's constantly busy processing JavaScript can't respond to user interactions, which directly hurts INP. Long tasks — anything taking more than 50ms of main thread time — are what you're looking for.
Use real devices, not just simulations. Lighthouse simulates a mid-range device, but simulations are imperfect. For Nigerian clients specifically, I test on actual Tecno and Infinix devices over real mobile connections. The results are often worse than the simulation, and they reveal issues the simulation doesn't catch.
The Fixes That Actually Move the Needle
"Optimise your images" is advice that sounds actionable and isn't. Here's what actually does the work.
Images: the highest-impact change on most unoptimised sites.
Format conversion. Convert all photos to WebP. WebP files are typically 25-35% smaller than JPEG at comparable visual quality, with near-universal browser support in 2026. If you're still serving PNGs and JPEGs for photos, this is where to start.
Responsive sizing. An image displayed at 400px wide doesn't need to be 2400px wide in the file. HTML's srcset attribute lets the browser download the appropriately-sized image for the current screen. For a site with many images, implementing responsive images properly can cut total image payload by 60-70% for mobile users.
Compression. Beyond format conversion, tools like Squoosh, Sharp, or ImageOptim can compress images further without visible quality loss. A hero image that started at 3.4MB can often get to 250-300KB with proper conversion and compression.
Lazy loading. Images below the fold should use loading="lazy" so they don't compete for bandwidth during initial page load. One critical exception: the LCP image should never be lazy-loaded. This is a common mistake that directly delays the LCP metric.
Preloading. Add a <link rel="preload" as="image"> tag for your hero image so the browser starts downloading it as early as possible, before it parses the rest of the HTML.
CDN delivery. A content delivery network serves files from the server geographically closest to the user. For Nigerian users accessing a site hosted in the US or UK, serving images through a CDN with regional nodes can reduce image load times significantly.
JavaScript: usually the INP and secondary LCP culprit.
Third-party script audit. Every third-party script on your site — analytics, chat widgets, ad networks, review systems, social sharing buttons — runs JavaScript that competes with your page's own code for the main thread. For the Luxury Tiles UK project, a review widget loading synchronously in the <head> was blocking the main thread for 1.2 seconds before anything else could render. Removing it and replacing with a performance-optimised alternative was the single biggest win in that audit.
Build a list of every third-party script on your site. For each one, ask: is this actively being used? What does it cost in loading time? Is there a lighter alternative? The answers often reveal that 40-50% of third-party scripts are either unused, duplicated, or can be loaded in a way that doesn't block rendering.
Code splitting. In Next.js and other modern frameworks, code splitting prevents JavaScript for pages and features the user hasn't visited from loading on the initial page. Verify that code splitting is actually happening — next build output will show you the bundle sizes per route.
Defer what can wait. JavaScript that doesn't affect the initial render should have defer or async attributes so it loads without blocking. This is particularly relevant for analytics scripts, which typically don't need to run before the page is interactive.
Web Workers for heavy computation. If your site does computationally heavy work on the client — filtering large product catalogues, processing file uploads, running animations — consider moving that work to a Web Worker so it runs off the main thread.
Fonts: a surprisingly common bottleneck.
Loading fonts from external services adds DNS lookup time and a separate network request to the critical path. Self-hosting your fonts — downloading the font files and serving them from your own domain — removes that external dependency. font-display: swap prevents a flash of invisible text while the font file loads, at the cost of a brief flash of the fallback font before the custom font appears. For most sites, this trade-off is worth it.
If you're loading fonts from two or three different sources (Google Fonts and an Adobe font and a custom hosted file), consolidate. Every external font source is a separate DNS lookup.
Server response time (TTFB).
Time to First Byte measures how long the server takes to respond to the initial request. A slow TTFB — Google's threshold for "good" is under 800ms — means every other performance metric starts from behind. The user is waiting for the server before any content can possibly appear.
Common causes of slow TTFB: cheap shared hosting with no caching layer, server-side rendering that's doing too much work synchronously on each request, database queries without proper indexing running on every page load, and no CDN for static assets. For Nigerian clients specifically, hosting on servers in the US or Europe adds latency. Hosting with a provider that has regional infrastructure in West Africa — or using a CDN aggressively for static pages — can reduce TTFB meaningfully for Nigerian users.
The Luxury Tiles UK Case Study
Luxury Tiles UK came to us through a referral. Their site had decent traffic but disappointing conversions. When I ran the initial audit, their PageSpeed score on mobile was 34 out of 100. LCP was 7.2 seconds. INP was categorised as "poor."
The issues were almost textbook:
- The hero image was a 3.4MB JPEG, served at full resolution with no responsive sizing
- Three third-party scripts loaded synchronously in the
<head>: a review widget, a social sharing script, and an abandoned A/B testing tool that had been installed and forgotten - Fonts loaded from two external sources (Google Fonts and a hosted font service)
- Hosting was on shared US-based infrastructure with no CDN for UK traffic
- No image compression or format conversion anywhere on the site
- Several pages were loading CSS for an old theme that was no longer active
We worked through these over three weeks. Hero image: converted to WebP, compressed, implemented with responsive srcset — 3.4MB down to 270KB. Third-party scripts: the A/B testing tool was removed entirely (nobody was using it), the social sharing script was deferred, the review widget was replaced with a lighter alternative loaded after interaction. Fonts self-hosted. Hosting migrated to a provider with UK CDN configuration. Old CSS removed.
After: mobile PageSpeed score of 78. LCP of 2.3 seconds. The site went from visibly slow to fast.
Traffic increased 150% over the following six months. Some of that is the direct ranking benefit from improved Core Web Vitals. Some is the indirect SEO effect of lower bounce rates — users who stay on a fast site longer send stronger engagement signals. Some is the parallel SEO work we did on content and technical structure. But the performance work was the foundation. Nothing else compounds properly on a slow site.
The Strapre Case Study
Strapre's performance problem was different from Luxury Tiles UK's. The technical issues were there — unoptimised images, some render-blocking scripts, no CDN — but the bigger problem was structural. The original site had too much on every page.
The homepage had a full-width video background, four separate animation sequences, a blog feed, a testimonial carousel, and a features section with hover effects that triggered JavaScript on every mouse move. Every section was trying to make an impression. The combined effect was a site that took over 8 seconds to become interactive on a mid-range device.
Structural performance problems require structural fixes. We rebuilt the site rather than optimising the existing build. The new architecture was simpler by design: critical CSS only in the initial render, no animations that couldn't be achieved in CSS (removing the JavaScript animation library entirely), images at correct dimensions with WebP format throughout, a CDN with Nigerian regional coverage for local users.
The rebuilt site loaded in under 2 seconds on the same devices the original had taken 8 seconds on. Six months later: 2,500+ monthly visitors, up from under 100. The performance work didn't produce all of that growth on its own — the SEO architecture and content approach were equally important. But a site that takes 8 seconds to load cannot rank well for competitive terms regardless of how good the content is.
Performance in the Nigerian Context Specifically
Standard web performance advice targets a 3G connection on a mid-range Android. That's almost exactly the Nigerian mobile web use case — and yet most performance content is written for US or European audiences where the baseline is much faster.
A few things that matter specifically in Nigerian context:
Data cost changes the calculation. In the UK or US, a heavy site is annoying. In Nigeria, a heavy site costs the user money. Someone on a daily 200MB data bundle — common for younger smartphone users — feels a 3MB page load differently than someone on unlimited home broadband. Sites that are heavy cost their users real naira. Users notice, consciously or not, which sites burn their data and which don't.
Network consistency matters as much as peak speed. Fast 4G is available in parts of Lagos, Abuja, and other major cities. It's patchy in others. It disappears in transit. Building for intermittent connectivity — using service workers to cache key pages, gracefully handling offline states, not making users reload everything when they briefly lose signal — keeps users on your site through the normal connectivity interruptions of Nigerian mobile browsing.
CDN geography. Most CDNs have their nearest West African nodes in South Africa or Europe. Request routing from Lagos to a South African CDN node is better than routing to the US, but not as good as a node actually in West Africa. When we configure CDN for Nigerian client sites, we check the specific provider's West African coverage and adjust accordingly.
Test on real devices. Lighthouse's emulation of a mid-range device is a useful starting point, but it doesn't capture everything. Real testing on a ₦60,000–₦80,000 Android phone — the kind of device that a large portion of Nigerian web users are on — over a real 4G connection sometimes reveals issues that simulation doesn't. We do this for every client project where Nigerian traffic is a significant portion of the audience.
Performance Budgets: Building Speed In From the Start
The most expensive way to build a fast site is to build a slow one and retrofit performance. Performance work added after development is slower, more disruptive, and often incomplete — because you're working around design and architectural decisions that are already baked in.
A performance budget sets performance constraints before development starts. For example:
- Home page LCP under 2.5 seconds on a mid-range device on 4G
- Total JavaScript under 200KB compressed on initial load
- No single image over 150KB
- No third-party scripts without explicit sign-off on performance impact
- TTFB under 800ms for all major pages
These become requirements on the same level as feature requirements. When a design proposes a full-width video background, the team asks whether that clears the performance budget. When a client wants to add a live chat widget, the discussion includes what it costs in terms of JavaScript payload and main thread time.
At JetherVerse, we include performance budgets in every project scope. Clients who haven't worked with agencies that do this are sometimes surprised. It can feel like a constraint on what you can build. It is. But the constraint is in service of the site actually working for the users it's meant to serve.
Conclusion
Speed is not a feature. It's a prerequisite.
A slow website is a leaky bucket. Traffic comes in through SEO, paid ads, social referrals — and drains out because users leave before they've seen what you're offering. Every naira spent marketing a slow website is partially wasted.
The fixes are systematic and largely predictable: compress images and serve them at the right size, audit and remove unnecessary third-party scripts, configure caching and CDN properly, defer JavaScript that doesn't need to run immediately, self-host fonts, check your TTFB. Test on real devices in real conditions. Build performance budgets into every project from the start.
Do that consistently and the numbers follow. We've seen it on every client project where we've done this work properly.
Is Your Website Fast Enough?
JetherVerse offers performance audits and rebuilds for businesses whose sites are costing them traffic and conversions.
Get in touch:
- 📧 Email: info@jetherverse.net.ng
- 📞 Phone: +234 915 983 1034
- 🌐 Website: www.jetherverse.net.ng
- 📍 4 Ehvharwva Street, Oluku, Benin City, Nigeria