The architecture behind a fast website

A Lighthouse score is not a target; it is the result of the right decisions. Below are the architectural decisions behind a fast site, along with what each one costs, because every choice has a cost.

1. Render the page ahead of time, not on request

If a page looks the same for every visitor, there is no reason to rebuild it on every request. Generating it once at build time and serving it as a static file is the fastest option available, because no computation happens on the server.

The cost: When content changes, it has to be regenerated. Suitable for content that changes a few times a day, not for content that changes by the second.

There is a middle path: generate the page statically and refresh it in the background at intervals. Visitors always get a ready-made page, and the content does not go stale.

2. Run on the server by default

In modern React most components can run on the server and send no JavaScript to the browser at all. Only the parts that genuinely need interaction become client components.

Letting that boundary get loose pushes the whole page to the client and ruins interaction latency. The most common mistake in practice is dragging an entire section to the client for one small interaction. The fix is to extract the interactive part into its own small component.

The cost: You have to pay attention to where each component runs. It takes discipline.

3. Not everything that expands needs JavaScript

An FAQ section works with zero JavaScript using the browser's own disclosure elements: keyboard access, screen reader behaviour, and in-page search all come from the browser.

The same applies to most tabs, dropdowns, and dialogs.

The cost: Less control over animation. Usually an acceptable trade.

4. Serve fonts from your own origin

A font fetched from a third party means an extra connection and extra latency. Served from your own origin, you reduce requests and gain control over when text appears.

Declaring metrics up front also stops text from shifting as it settles. When the fallback font's metrics are tuned to match the real one, the shift at swap time disappears entirely.

The cost: You manage the font files. A small burden.

5. Always declare image dimensions

An image without width and height pushes the content below it down the moment it loads. This is the number one cause of layout shift and it is entirely preventable.

Images above the fold should be prioritised; everything else should load lazily. Serving different sizes for different screen widths also avoids sending unnecessarily large files to phones.

The cost: None. There is no justification for skipping this.

6. Push third-party content to the end

Maps, video embeds, chat widgets, and analytics scripts are all heavy. Most of that weight comes from outside your own code, not from it.

There are three techniques, and which one fits depends on the content:

• Lazy loading. Nothing loads until the content scrolls into view. This is the right approach for a map sitting at the bottom of the page.
• A cover image. The content is represented by an image, and the real embed loads when the user clicks. Ideal for video.
• Load after consent. Analytics and marketing scripts do not run at all until cookie consent is given. This is the correct choice for both speed and law.

The cost: In some cases the user makes one extra click. Reserve this for content that is genuinely heavy, not for everything.

7. Do not animate what nobody is looking at

A continuously running animation does work on every frame even when the element is off screen. That work is taken directly from scroll smoothness.

The fix is simple: pause the animation when the section leaves the viewport. That is exactly what this site does, and the measured frame time during scrolling dropped noticeably as a result.

The cost: A few lines of code.

8. You cannot improve what you do not measure

Even with all of the above right, a single heavy script added later can undo it.

Speed is therefore not a one-time task but an ongoing check. Measuring after every release and recording the result means regressions get noticed immediately. The measurement method is covered step by step in how to measure website speed.

A score is a result, not a target

When all of these decisions are made, the score rises on its own. The reverse does not work: interventions made afterwards to raise a score tend to be superficial and do not show up in field data.

And the score is not the real measure anyway. If the page opens quickly on a real phone over a real connection, the work is done.

---

We can review your current architecture and identify where it is losing time. Our approach is on the web design and development page.