Start website performance work with the biggest bottleneck

Website performance advice often arrives as a long checklist. The more useful approach is to measure a real page, find what is slow, and fix the largest problem first.

On many sites that will be an image or a third-party script. On others, the server spends most of its time waiting for a database query. Minifying a tiny stylesheet will not rescue either of those.

Images are often the heaviest part

Do not serve a 4,000-pixel photo in a 600-pixel content column. Resize it, compress it, and provide several sizes with srcset so the browser can choose a suitable file.

Modern formats such as WebP can be smaller than comparable JPEG or PNG files, but format choice is only part of the job. A properly sized image usually matters more than squeezing another few percent from the wrong dimensions.

Pay special attention to the main image near the top of the page. It may need to load early. Lazy-loading every image is easy; lazy-loading the image the reader is waiting to see is less clever.

Remove code before minifying it

Minification removes whitespace, comments, and other unnecessary characters from CSS and JavaScript. It is worth automating in the build process, but unused code is a bigger target.

A minified library that the page does not need is still a library the browser must download, parse, and run. Check which scripts load on every page, especially analytics, advertising, chat widgets, and social embeds.

Make repeat visits cheaper

Browser caching lets returning visitors reuse files they already downloaded. Long cache lifetimes work well for versioned assets such as app.42f8c1.js, because a changed filename can point the browser to a new version.

Server-side caching solves a different problem. It can store a generated page, fragment, or database result so the application does not repeat the same work for every request.

Both are called caching, but they reduce time in different places. Check response headers for browser caching and server metrics for application caching.

A CDN helps when distance is the problem

A content delivery network serves cached files from locations closer to visitors. This can reduce network delay, especially when the audience is spread across several regions.

A CDN does not repair a slow origin, an oversized page, or expensive JavaScript. It delivers the same problems from a more convenient location. Use it after understanding what is actually slow.

Database-backed sites need database work

For a CMS such as WordPress, a slow query can hold up the entire HTML response. Useful fixes include adding the right indexes, removing unnecessary queries, caching repeated results, and cleaning up extensions that do too much work on each request.

Do not optimise tables or add indexes blindly. Capture the slow queries first; database changes can have wider effects than a CSS edit.

Measure again

Run the same test after each meaningful change. Use browser developer tools to inspect the network waterfall and, when possible, test on a slower connection rather than only on a fast laptop.

The best performance improvement is usually specific to the page in front of you. Measure, fix the largest bottleneck, and repeat. A short evidence-based list beats twenty generic tweaks.