Measure the real thing first
Optimising without measurement produces effort in the wrong places. Start with field data from actual sessions, segmented by device class and connection, because a mid-range phone on mobile data is frequently several times slower than the machine the site was built on.
Lab tools are useful for diagnosis and comparison, but they are a model. Field data is what your users experienced.
Find what blocks the first render
Before anything appears, the browser must fetch the HTML, then any render-blocking CSS and synchronous scripts. Everything in that chain adds directly to how long the page looks empty.
Inline the critical styles, defer the rest, and make every non-essential script asynchronous. This alone frequently accounts for the largest single improvement.
Fix the images
Images are usually the largest payload on a page and the easiest thing to get badly wrong. The common faults are a single large file served to every screen size, a modern format never adopted, and no lazy loading below the fold.
- Serve modern formats with a fallback
- Provide multiple sizes and let the browser choose
- Lazy-load anything below the fold, and never the hero image
- Set explicit width and height so layout does not shift
- Compress deliberately — the difference between visually identical settings is often several hundred kilobytes
Audit the third parties
Analytics, tag managers, chat widgets, A/B testing, and advertising scripts frequently outweigh the entire application. Each was added for a reason and very few are ever removed.
List them, find an owner for each, and delete the ones nobody can justify. For those that remain, load them asynchronously and after the page is usable.
Then look at the server
If the initial response itself is slow, no amount of front-end work will compensate. Look for unindexed queries, N+1 patterns, and work being done per request that could be cached.
A cache in front of pages that do not change per user is frequently the single cheapest improvement available.
Defend the result
Performance regresses continuously, because every individual addition seems small. Put a budget in the pipeline — payload size, render timing — and fail the build when it is exceeded.
Without an automated gate, a site returns to its previous speed within a year, and the work has to be done again.