The four causes behind almost every slow site
We audit dozens of sites each year. Independent of industry or platform, the same four causes appear in roughly the same order of impact.
- Unoptimised images. Typically 50–70% of total page weight. A single hero image served at 4000px wide is often larger than everything else combined.
- Render-blocking third-party scripts. Chat widgets, pixels, heatmap tools and review widgets each add main-thread work; together they routinely add two seconds.
- Font loading. Multiple weights and families loaded without subsetting or preloading block text rendering.
- Slow server response. Shared hosting without caching can take 800ms just to return the HTML.
Fixes one to three: images, scripts, fonts
These three fixes typically deliver 70% of the achievable improvement, and they are the least risky to implement.
- Serve AVIF with WebP fallback and explicit width/height attributes. Generate responsive srcsets so mobile never downloads a desktop image. Preload the LCP image and lazy-load everything below the fold.
- Audit every third-party script and tag. Load analytics asynchronously, defer chat widgets until interaction, and remove tools nobody has opened in six months. Add a performance budget so new scripts require justification.
- Subset fonts to the characters you use, self-host rather than loading from a third-party CDN, preload the primary weight and use font-display: swap.
Fixes four and five: server and caching
If your TTFB is above 500ms, no amount of front-end work will save you. The browser is waiting before it can do anything.
- Move to infrastructure appropriate to your traffic. For most Pakistani businesses, a VPS with a CDN in front outperforms shared hosting by a wide margin.
- Enable full-page caching for anonymous visitors, object caching for database queries, and Brotli compression. On Next.js, use static generation plus incremental revalidation rather than rendering every request.
- Configure a CDN with points of presence in South Asia and the Middle East. Without one, Pakistani visitors add 200–600ms of latency before the request even starts.
Fixes six and seven: layout stability and measurement
Two fixes that are less about speed and more about perceived quality — and both directly affect conversion.
- Reserve space for every image, embed and ad slot with explicit dimensions so content does not jump. CLS above 0.1 is a conversion problem as much as a ranking one.
- Measure field data rather than lab scores. Lighthouse in a controlled environment can show 95 while real users on 4G experience something very different. Use CrUX and Search Console, and wait the full 28-day window before judging.
What not to do
Adding a caching plugin on top of a fundamentally heavy build makes debugging impossible and gains are temporary. Optimisation plugins that minify and combine everything can break functionality in subtle ways that surface weeks later.
The same applies to lazy-loading hero images. We see this regularly — someone adds a lazy-loading plugin, it applies to the LCP image, and performance gets worse. Always exclude above-the-fold images from lazy loading.
Fix the cause, not the symptom. Plugins that mask a slow foundation always regress.
Key takeaways
- Images, third-party scripts, fonts and server response cause almost all slowness.
- Image and script optimisation typically delivers 70% of the achievable gain.
- If TTFB exceeds 500ms, front-end work cannot compensate.
- Judge improvements on field data after 28 days, not lab scores immediately after deploying.
Bilal Ahmed
Head of Engineering
Oversees web and application development, with a focus on Next.js, TypeScript and performance engineering.