Speed is a design decision, not a technical one
Someone approves a homepage design on a Friday. It has a full-width video behind the headline, a logo carousel, a testimonial slider, a subtle parallax effect on three sections, and a type stack of six weights across two families. Everyone likes it. It is signed off.
The site is slow four months later and nobody connects the two events. A plugin gets installed. Hosting gets upgraded. Someone runs a scan, gets a red score, and asks the developer why the build is heavy.
The build is not heavy. The design was.
Where website speed is actually decided
Website speed is set on the wireframe, not in the server config. By the time a developer is choosing image formats, the ceiling has already been established by decisions nobody thought of as technical: how many distinct visual elements the first screen requires, how many fonts are in play, whether motion is decorative or functional, and how much of the page has to load before anything is readable.
Caching, compression, a CDN and better hosting all reduce the cost of delivering what the design asked for. None of them reduce what it asked for. That is the whole point. A studio that promises to optimise a heavy design is promising to carry the same weight slightly faster.
The 2025 HTTP Archive Web Almanac puts numbers on how much is being asked for. The median mobile page shipped 911 KB of images. Not the heaviest page. The median one. That is most of a megabyte of pictures before a visitor has read a sentence, and almost none of it was a technical decision. It was a layout that wanted more pictures.
What are the Core Web Vitals thresholds?
Worth stating precisely, because they get quoted from memory and drift. Google’s current Core Web Vitals are three metrics with three thresholds.
Largest Contentful Paint should occur within 2.5 seconds of the page starting to load. This is when the biggest thing on screen, usually your hero image or headline, actually appears.
Interaction to Next Paint should be 200 milliseconds or less. This measures how quickly the page responds when someone taps or clicks.
Cumulative Layout Shift should be 0.1 or less. This is the measure of things jumping around while the page settles.
All three are assessed at the 75th percentile of real page loads, segmented by mobile and desktop. That last detail is the one people miss. It is not your experience on office fibre that counts. It is the experience of the slowest quarter of your actual visitors, which in a B2B context means a project engineer on a phone, on site, on a network shared with everyone else on that site.
The Almanac’s field data shows how directly weight decides this. Of desktop home pages under 1 MB, 70 per cent passed the Core Web Vitals assessment. Of those 5 MB or larger, 38 per cent passed. Roughly half the pass rate, for pages that in most cases are not offering the visitor twice as much.
The four decisions that cost the most
The hero video. It is almost always a mood piece with no information in it, it usually cannot be the Largest Contentful Paint element in any useful way, and it is the single most expensive thing on the page. If the video genuinely shows the work, put it further down where a visitor chooses to play it.
The carousel of fifty images. Logo walls, project sliders, testimonial rotators. Everything in a carousel loads, and almost nothing in a carousel gets seen past the second slide. A carousel is usually a layout decision made to avoid a content decision, which is that nobody wanted to choose the six clients worth showing.
Six typefaces. Two families, three weights each, plus italics, and the page is carrying font files before it carries content. Two weights of one good family is not a compromise. Weight contrast creates hierarchy on its own, and it renders sooner.
An animation library imported for one effect. A whole dependency loaded so that a number can count up when it scrolls into view. Nobody has ever bought anything because a statistic counted up.
None of these are mistakes a developer makes. They are all approved in a design review by people who are looking at a static mockup, where a video weighs nothing and a carousel is a single frame.
Designing to a budget instead
The fix is unglamorous. Set a weight budget at the wireframe stage and treat it the way a structural engineer treats a load. Decide what the first screen has to do, and then let every addition to it displace something rather than accumulate on top.
That works because in the sectors we build for, the fast version is also the better version. When we designed Towa Marine, the brief was that a superintendent under time pressure should be able to see the response commitment, the three-yard footprint and the system list without scrolling. A page built to answer that question quickly cannot also carry a cinematic intro, and it did not need one. The constraint and the content agreed with each other.
Speed handled this way is not a phase at the end of a project called optimisation. It is a series of small refusals during design, each of which is easy at the wireframe stage and expensive after sign-off. Moving a section on a wireframe costs nothing. Removing a hero video after the client has seen it costs a conversation nobody enjoys.
We build to that standard by default, and our pricing bands start from S$4,000 with images compressed and served in modern formats, plus 30 days of support after handover, extended to 45 days on larger builds. What we do not do is quote optimisation separately, because a design that needs rescuing was designed wrong.