Why good looking websites load slowly, and how to fix it

Ambitious design is not what makes a site slow

There is a persistent assumption that a site has to choose: it can look considered, or it can load quickly. The assumption is worth examining, because the data does not really support it. Sites are not slow because they are well designed. They are slow because of a small number of decisions that are easy to make badly and easy to fix once you know where to look.

What the numbers actually say

The HTTP Archive Web Almanac tracks page weight across millions of sites. In July 2025 the median home page was 2.86 MB on desktop and 2.56 MB on mobile. In October 2014 the mobile figure was 505 KB. Pages have grown roughly fivefold in a decade while the networks they load over have improved far less than that, particularly at the weaker end of the range where a lot of real traffic sits.

The breakdown matters more than the total. Images account for more bytes than anything else, at roughly 1,054 KB against 613 KB for JavaScript. So the largest single lever on most sites is not the framework, the animation library or the CMS. It is the pictures.

The three metrics Google actually measures

Core Web Vitals reduce all of this to three numbers, each assessed at the 75th percentile of real page loads, split by device. That percentile is the part people miss: it is not your average visitor, it is the slowest quarter of them.

Largest Contentful Paint should happen within 2.5 seconds, and measures when the biggest thing in the viewport finishes rendering. Interaction to Next Paint should be 200 milliseconds or less, and measures how quickly the page responds when somebody actually taps or clicks. Cumulative Layout Shift should stay at or under 0.1, and measures how much the content jumps around while loading. INP became a stable Core Web Vital in 2024, replacing First Input Delay, and it is the stricter test: FID only measured the delay before the first interaction was processed, while INP measures the full response time across the visit.

Where the time usually goes

In practice, most failing LCP scores trace back to one image. A hero photograph exported at full resolution, served at its original dimensions, loaded before anything else on the page. A 6 MB source file does not become acceptable because the layout around it is restrained. Modern image pipelines will resize and re-encode automatically, but they cannot undo a source asset that was never optimised, and they will not help at all for an image that sits outside the pipeline.

CLS is usually a layout problem rather than a weight problem. An image without declared dimensions, a web font that swaps in at a different size, or an element injected above existing content will all shift the page after the reader has started reading. Each of these is cheap to prevent and irritating to experience.

INP is the one that catches ambitious interfaces, and it is where scroll-linked animation, heavy hydration and oversized client bundles show up. The fix is rarely to remove the interaction. It is to stop doing expensive work on the main thread while the reader is trying to use the page.

How to keep both

None of the above requires a plainer site. It requires the performance decisions to be made at the same time as the web design decisions, rather than handed to whoever does the web development at the end.

In practice that means a few habits. Decide the largest image on each template while the design is still in Figma, and agree what it weighs before it is exported. Give every image explicit width and height so the space is reserved before it loads. Serve modern formats and let the framework generate the sizes rather than shipping one file for every breakpoint. Load fonts with a fallback that is close enough in metrics that the swap does not move the text. Keep the interactive parts of the page small and let the rest render as static HTML.

The point of measuring at the 75th percentile is that it stops you designing for your own machine. A site that feels immediate on a fast laptop on office broadband can be a genuinely poor experience on a mid-range phone on mobile data, and that visitor is not an edge case. They are a quarter of the people you are trying to reach.