The first thing we tell clients who want to speed up their site is to stop trying to speed it up. The site is slow because its architecture allows it to be slow. Optimising the JavaScript bundle, lazy-loading the images, deferring the third-party scripts — all of these help, but only at the margins. The page is fundamentally heavy and you cannot make a fundamentally heavy thing fast.
Fast websites are built by deciding, at the start, that the site will be fast. Then every subsequent decision is filtered through that constraint. This is closer to architecture than to optimisation.
The three sources of weight
Almost every slow site is slow for the same three reasons. Images that are larger than they need to be, JavaScript that runs before the user can interact, and third-party scripts that load synchronously. In our experience these account for somewhere around 80% of all front-end performance debt.
Images are easy to talk about and hard to solve. Modern formats (AVIF, WebP) help. Responsive sizing helps. Lazy loading helps. But the largest gains come from cropping more aggressively, using fewer images, and accepting that a photograph that is 1200px wide does not need to be served as a 3000px file. We see this every project.
JavaScript is harder because it has become culturally invisible. Every component "needs" client-side state. Every page "needs" a router. Every team "needs" their preferred framework. Most pages on most websites need none of those things. They need to render server-side and load no JavaScript at all.
Fast websites are built by deciding, at the start, that the site will be fast. Then every subsequent decision is filtered through that constraint.
What we do
Our default architecture for marketing sites is static HTML with the smallest amount of JavaScript necessary, served from a CDN. No framework on the page. No client-side router. No "isomorphic" anything. The site is a folder of HTML files. Each one is what it appears to be.
For web applications it is different. There the framework earns its weight because the application is genuinely interactive. But even there, we draw a hard line between the marketing surface (static, fast) and the application surface (client-rendered, behind a login). The user who is visiting your homepage should never download your application's JavaScript bundle.
The unspoken metric
Lighthouse scores are useful but they measure the wrong thing. What we actually care about is the time between a user clicking your URL and the page becoming useful to them. On a mid-tier Android phone over a 3G connection, in the markets we operate in. That number, in our experience, is the difference between a site that converts and a site that doesn't. It is rarely the same as the desktop Lighthouse score.
The cheapest thing to fix
If we have to pick one performance lever for clients who can only afford one — pick the hero image. The largest image visible on first paint is usually the largest single contributor to load time. Compress it harder than feels comfortable. Crop it tighter. Then revisit it once a quarter. It will drift back to too large; everything drifts back to too large.
Performance is not a feature you add. It is a posture you maintain.