Why your website is slow: four causes that account for most of it

Are web fonts making your site slow?

Very often, and in a way that is easy to miss. With the common setting font-display: swap, the browser paints your text in a fallback font, then repaints when the real font arrives. Largest Contentful Paint is recorded at the repaint — so your LCP is measuring the font swap rather than your page.

On a site we measured recently, the hero paragraph showed 2.29 seconds of pure render delay with zero network time. The text was already in the HTML. It was waiting for a typeface.

There are two fixes. Reduce what you load — most sites ship weights they never use — and consider font-display: optional, which keeps the fallback for that visit rather than swapping. The trade-off is real: on a slow connection, first-time visitors see your fallback font.

How much are third-party scripts costing you?

More than their file size suggests. A tag manager, an analytics script, a chat widget and a consent banner will each open a connection to a new origin, then execute on the main thread while the browser is trying to become interactive.

The cost is usually concentrated in Total Blocking Time, which is 30% of the Lighthouse performance score — the single heaviest weighting. Adding one consent banner to an otherwise clean site can cost ten points.

Load order matters as much as load count. A script set to run before hydration blocks the main thread at the exact moment Lighthouse is measuring. The same script loaded after hydration often costs almost nothing.

Can CSS make a page slow?

Yes, and this one surprises people because CSS files are small. The cost is not download, it is paint.

Large-radius blurs are the worst offender. A 64-pixel blur across a 500-pixel decorative shape forces the GPU to sample an enormous area, and if it sits above the fold it lands squarely in what Speed Index measures. Backdrop filters and blend modes are similarly expensive, because they force the browser to composite a separate layer.

The fix is usually visual rather than technical: a radial gradient looks close to identical to a blurred circle and costs effectively nothing.

What about images?

Images are the most talked-about cause and, on modern sites, frequently not the real one — because frameworks now handle sizing and format conversion automatically. Where they still bite is when someone uploads a 4000-pixel photo through a CMS that serves it untouched.

The checks worth doing: are they served as AVIF or WebP, are they sized for the space they occupy, do they have width and height attributes so nothing shifts as they load, and is anything below the fold lazily loaded.

How do I find out which one applies to me?

Run PageSpeed Insights and look at the LCP breakdown rather than the score. It splits the time into time to first byte, resource load and element render delay. That split tells you the category immediately.

High render delay with low network time points at fonts or blocking scripts. High resource load time points at images. High blocking time points at JavaScript. The score alone tells you there is a problem; the breakdown tells you where.