Why Most Websites Are Too Slow (and Three Fixes That Cover 80% of It)
The median web page in 2025 was 2.5 megabytes and made over 70 HTTP requests. A decade earlier those numbers were 1MB and 50. The trend is not pixels and HTTP requests slowing down — it is web pages getting bigger faster than connections improve.
Most of that bloat is preventable. Most slow sites have the same three problems. Fixing them takes a day for a competent web developer and gives back 2–5× of perceived speed. Here is what to look for and how to fix it.
The three problems
1. Images that are too big and not modern
Image weight is the single biggest culprit in 90% of slow sites. The reasons compound:
- The CMS lets you upload a 4000px-wide photo from your phone and serves it as-is to a 375px-wide phone screen.
- JPEGs are still the default format even though WebP and AVIF give 30–50% smaller files at the same quality.
- Images load eagerly — they download even when the visitor never scrolls to them.
The fix:
- Resize every image to no wider than ~1100px (the maximum width of a typical content column at 2× retina). If you can do per-image responsive sizes (
srcset/sizes), better. - Convert to WebP (and AVIF if you want to be modern). WordPress 7 ships with native conversion; for older CMSes, a build-time script or a plugin handles it.
- Add
loading="lazy"to every image below the fold. The browser will not download them until the visitor scrolls.
This alone typically takes a 3MB page down to 800KB.
2. Render-blocking JavaScript and CSS
Every <script> tag in the <head> blocks the browser from showing your page until it downloads and runs. Same for stylesheets. By default, most CMS themes load 8–15 of them. The page sits blank for two seconds while they all download.
The fix:
- Move JS to the bottom of the body, or add
defer/asyncattributes to keep it from blocking. - Inline your critical CSS (the styles needed for the visible part of the page) and load the rest async.
- Audit your loaded scripts. Half of them are usually unused (old analytics, abandoned plugins, unused trackers). Remove what is not used.
This brings First Contentful Paint from 2–4 seconds down to under 1.
3. No caching, no CDN
Every request to a CMS-driven site fires up a database query, runs PHP, and generates HTML from scratch. On a popular page that is wasteful — the HTML is identical for every visitor.
The fix:
- Enable page caching. A WordPress plugin (WP Rocket, W3 Total Cache) does it in two clicks. Static-site generators do it by definition. Either way: serve cached HTML, not re-generated HTML.
- Use a CDN — Cloudflare's free tier covers most small sites and serves your static assets from servers physically close to your visitors. A user in Thessaloniki gets your CSS from a Greek data centre, not from your origin server in Germany.
- Set long cache headers on your static assets (images, CSS, JS) so the visitor's browser does not re-download them on every page view.
This makes repeat visits feel instantaneous.
How to measure where you stand
Before you start changing things, get a baseline. Three free tools cover everything:
- PageSpeed Insights — Google's tool. Tells you Core Web Vitals (LCP, INP, CLS) for both mobile and desktop. Aim for green on all three.
- WebPageTest — more detailed than PSI. Run from Athens for realistic Greek-visitor results.
- Browser DevTools, Network tab — shows you the actual size of every asset loaded and how long each took.
Test before, fix the three problems above, test after. The numbers will tell you whether more work is needed.
When to bring in help
If you have a CMS site and you are not comfortable touching theme files or installing optimisation plugins, this is when a web developer pays for itself. A day of focused performance work routinely gives back:
- 30–50% faster Largest Contentful Paint.
- Lower bounce rate (fast sites keep visitors).
- Better Google rankings (Core Web Vitals are a ranking signal).
- Lower hosting load (cached HTML means less PHP work).
kapaweb's web development service includes performance audits and fixes — proposal-first, hourly-billed, transparent. If your site is slow, ask for the audit before you commit to a redesign — the redesign often is not what you need.
