Why a website is slow and what to fix first

Measure before you optimise

“It feels fast on my laptop” depends on cache, hardware and network. Test in a private window, on a phone and with browser performance tools. Find out whether the delay comes from server response, download size or JavaScript execution.

1. Images are the easiest big win

• Do not send a 4000px image into a 600px container.
• Use efficient modern formats when appropriate.
• Lazy-load images below the first viewport.
• Set dimensions so the layout does not jump while images load.

2. Do not run code the page does not need

Every library must be downloaded, parsed and executed. Several large packages for minor visual effects are much more expensive on a low-end phone than on a developer laptop. Before adding a dependency, ask whether CSS or a small module can do the job.

3. Fonts are downloads too

Five weights across two font families can become a significant payload. Keep only the weights you really use and configure loading so text does not stay invisible while a custom font is on the network.

4. Check server response time

If the first HTML byte arrives after several seconds, image optimisation will not fix the main problem. Look for sleeping instances, slow database queries, synchronous external APIs or missing caching. Measure concrete operations in logs.

5. Third-party widgets can cost more than your code

Chats, maps, analytics, ad pixels and social widgets add requests and JavaScript. You do not have to remove them all, but load them only where they provide real value.

A sensible order of work

1. Record the baseline.
2. Fix oversized images.
3. Remove unused scripts and styles.
4. Check backend and database latency.
5. Measure again.

Optimisation without a second measurement quickly becomes guesswork.

Caching helps when data is reusable

Logos, CSS, JavaScript and immutable images do not need to download on every navigation. Good cache headers let the browser reuse them. But never treat private user data as shared public cache.

Learn to read the Network waterfall

Sort requests by size and time. One file may account for half the page weight; dozens of requests may be waiting on one third-party domain; a slow initial document points towards the backend. One waterfall often explains more than random CSS changes.

Test on a weaker device

A powerful computer hides performance problems. Test on a modest phone with a throttled network, especially when traffic comes from mobile ads or social media. That is much closer to the real customer experience.