Almost every slow website we audit is slow for the same handful of reasons, and almost none of them are fixed by installing a caching plugin. Caching helps once the page is well built. It cannot rescue a page that ships two megabytes of images and eleven third-party scripts.
Images are usually the largest single problem
The most common failure is serving one enormous image to every device. A 3000-pixel-wide photograph delivered to a phone screen costs the visitor download time and processing, and looks identical to a correctly sized one.
What to do:
- Serve modern formats. WebP typically costs 25 to 35 per cent less than the equivalent JPEG at the same visual quality.
- Generate several sizes and let the browser choose with
srcsetandsizes. - Lazy-load anything below the fold, but never the main hero image, because that is usually the element the browser measures for Largest Contentful Paint.
- Always set
widthandheight. Without them the browser cannot reserve space, and the page jumps as images arrive.
Fonts block text from appearing
Web fonts are frequently the reason a page looks blank for a moment. Loading them from a third-party host adds a DNS lookup and a TLS handshake before the file even starts downloading.
Self-host the font files, preload the one used for body text, and set font-display: swap so the browser shows readable text immediately and swaps the face in when it arrives. Cut the character subsets you do not need: a Latin-only subset of a variable font is often under 50 KB and covers every weight.
Render-blocking assets in the head
Every stylesheet and every synchronous script in the head delays the first paint. The fixes are unglamorous and effective: keep CSS small enough that it is not worth splitting, defer scripts that are not needed for the initial render, and do not load a 90 KB JavaScript framework to run a dropdown menu.
Third-party scripts are the cost nobody budgets for
Analytics, tag managers, chat widgets, heatmap tools, review embeds, advertising pixels. Each one is a request to a server you do not control, running code you did not write, on your visitors' devices. It is routine for third-party scripts to outweigh a site's own code several times over.
Audit them honestly. For each one, ask who looked at its output in the last quarter. Load what survives asynchronously, and after the page is interactive.
Layout stability is a real cost, not a cosmetic one
Cumulative Layout Shift measures content moving after it has been painted: a button that slides down as an advert loads, and the visitor taps the wrong thing. Reserve space for images, embeds and advertising slots. Avoid injecting banners above existing content. Use font-display: swap, and tune the fallback font with size-adjust and matching metrics so the swap does not move the text.
What to measure, and where
Test on a mid-range phone over a mobile connection, not on your laptop over office fibre. Lab tools such as Lighthouse are useful for diagnosis; field data from real visitors is what actually reflects experience. If the two disagree, believe the field data.
The uncomfortable summary
Performance is not a phase at the end of a project. It is the accumulation of decisions made throughout it: which framework, how many scripts, how images are handled, whether a design calls for a carousel that nobody uses. Agree a page weight and a Core Web Vitals target at the start, and measure against it as you go. Retrofitting speed is always more expensive than not losing it.
