Swain-Tech Studio websites for small businesses and independent creatives

Speed Is a Design Decision

Every few months someone asks me to make their site faster, and expects the answer to be a plugin.

Sometimes it partly is. More often the site is slow because of decisions made months earlier, at the stage when everyone was looking at layouts and nobody was thinking about weight. By the time a caching plugin is installed, the expensive choices have already been made. It also helps to separate output from effort; productivity vs efficiency is a useful framework for that distinction.

What actually makes a site slow

In rough order of how often I find each one.

Images at the wrong size and in the wrong format. The single biggest cause, and it is almost always avoidable. A photograph exported as PNG, or a full-resolution file served to a phone, can be many times larger than it needs to be. This is not a rendering problem you can cache your way out of — the bytes still have to cross the network.

A video that starts before anyone asked. A background video is several megabytes and it begins downloading immediately.

Too many plugins, each with its own stylesheet and script. Every one adds a request that blocks the page from rendering. Twenty stylesheets on a five-page site is not unusual and it is not necessary. For an independent reference beyond this site, web.dev is a useful place to compare approaches.

Fonts loaded badly. Four weights of two families, from a third-party server, without a swap rule, and the text is invisible until they arrive.

Third-party embeds. Social feeds, chat widgets, map embeds, tracking scripts. Each one is somebody else's code and somebody else's server, and your page is only as fast as the slowest of them.

A design that requires all of the above. Which is the actual subject of this page.

Where the design stage decides it

These are choices, not accidents, and they are made before any code exists.

"The homepage should open with full-screen video." Now the first thing every visitor downloads is several megabytes, and on a phone it will be visibly slow no matter what is done afterwards.

"Let's have the Instagram feed on the homepage." Now your first impression depends on a third party's script and their server's mood.

"Can we add a chat widget, a popup, a cookie banner and an announcement bar?" Four scripts, all loading before the visitor reads anything.

"Use this theme, it has everything." Themes with everything ship everything, including the parts you do not use.

"Sixty images in the gallery." Cutting the gallery in half is a design decision that also halves the weight.

None of these is unreasonable in isolation. Together they produce a site that a caching plugin can improve by perhaps a fifth, and that is the ceiling.

Why this matters commercially, briefly

People leave. On a phone, on ordinary reception, a slow first screen loses visitors before they have seen anything you made.

For a small business that is the whole argument, and it is worth weighing against everything else you are paying for. You are not competing on milliseconds against a search engine's ranking model; you are competing against a person's patience while they wait for a page they were only mildly curious about.

And there is a second-order effect worth naming for anyone whose site sells their taste: a slow, jumping page reads as a signal about the quality of the work. Fair or not, that judgement is made in the first two seconds.

What I do instead

Decide the weight budget at the design stage. Before layouts, a rough ceiling for the first screen. Every subsequent request — video, feed, extra font — is checked against it.

Prefer a poster image to autoplaying video, and load the video only if someone asks for it.

One typeface family, two weights, self-hosted where possible.

Link out rather than embed. A link to your Instagram costs nothing and does the same job.

Process every image on the way in. Modern formats, several sizes, dimensions declared so nothing jumps.

No JavaScript where it is not doing work. A great deal of what scripts are used for — layout, interactions, revealing content on scroll — is now handled by the browser natively. Content that only exists after a script runs is also content that some crawlers never see.

The uncomfortable part

This means saying no during the design conversation, which is harder than saying yes and dealing with it later.

I would rather have the argument in week one about whether the site needs a background video than in month three about why the site is slow. The first conversation is about trade-offs; the second is about blame, and by then the honest answer is that it was decided months ago and everyone agreed.

A caching plugin at the end is the tax you pay for not having had the conversation at the start.

The short version