Performance is craft, not configuration.

There is a habit in web work of treating performance as something you bolt on at the end. You build the site, then you run Lighthouse, then you spend a sprint fixing what it flags. The score goes up, the sprint ends, and the next project starts the same way.

This produces adequate sites. It does not produce fast ones.

The sites we are most proud of — the ones that score in the high nineties on a real mobile device, on a real network, without any post-build heroics — are fast because every decision made during design and development had a weight attached to it. Not a score to chase. A constraint to respect.

The 1-second budget

We hold a 1-second median load time on 4G as the target for every project. Not a stretch goal — a design constraint, the same way a typographer works within a column width or a carpenter within a material's grain.

A second feels fast until you try to build to it. On a real mid-range Android phone — not a Pixel 8 in a Sydney office, but the kind of device most of your customers actually use — 1 second is demanding. It means roughly 200–250kB of compressed, parsed, executed JavaScript before the page is interactive. It means images that arrive already at the right size, in the right format, without blocking the initial render. It means fonts that load without a flash of invisible text that shifts the layout as they arrive.

None of that is impossible. But none of it is automatic, either. It requires making the constraint visible early enough that it can shape decisions, not just measure them.

Where most of the weight comes from

In our experience, the performance budget is lost in three places, roughly in this order.

JavaScript. Not the framework — the framework is usually fine. The damage comes from third-party scripts: analytics, chat widgets, booking embeds, A/B testing tools, retargeting pixels. Each one is small enough to seem harmless. Together they routinely constitute 60–70% of the total parse cost on a page. The solution is not to eliminate them — most serve a real purpose — but to defer and gate them. Load the booking widget when the user navigates to the booking section. Load the chat widget after the first user interaction. Load the pixel at the end of the event cycle, not the beginning of the render cycle.

Images. This one is simpler and easier to fix, which is why it is surprising how often it isn't. An image that is served at 2400px to a 390px screen, in JPEG at 85% quality, is not a premium image — it is a slow one. Every image on a site we build is served at the correct intrinsic size for the viewport it appears in, in AVIF or WebP with a JPEG fallback, with a meaningful sizes attribute and a correctly prioritised loading attribute. The hero image — the one that is always above the fold — gets priority. Everything else gets lazy. It sounds obvious. It is also something a surprising proportion of production sites get wrong.

Fonts. Variable fonts are a gift. They let you use a single file to cover every weight and style you need, often at a smaller total payload than a set of static weight files. But they still need to be loaded with care: preloaded in the document head, served withfont-display: swap, and subsetted to the characters the design actually uses. A display font that includes the full Latin-Extended character set — accents, diacritics, currency symbols from languages the site never uses — is carrying weight for nothing.

The design decisions that matter most

There is a persistent idea in the industry that fast sites are plain sites. That performance and design quality exist in tension, and that choosing one means compromising the other. We do not believe this, and the sites we have shipped are evidence against it.

The constraint, applied early, does change what you design. You reach for CSS transitions over JavaScript animations where the motion is simple enough. You choose a single display typeface over three. You build a hero from typography and colour rather than a full-screen video. These are not compromises — they are design decisions that happen to be fast. Often they are also better decisions: quieter, more focused, easier to read.

Where complexity genuinely serves the work — a 3D object in a hero, a canvas animation, a rich interaction — we use it, but we use it precisely. The 3D scene on this site is dynamically imported: it does not block the initial render, it has a static fallback for users on low-powered devices or reduced-motion settings, and it defers to the content rather than competing with it. The performance cost is real. The design justification is clear.

What you actually measure

Lighthouse is a useful tool, but it is a lab test. It runs on a simulated device with a throttled connection in a controlled environment. A score of 98 in Lighthouse is a good sign. It does not guarantee a fast experience in the real world.

The metric that matters is Core Web Vitals in the field — the data Google collects from real users on real devices. Specifically: Largest Contentful Paint (how long until the main content is visible), Interaction to Next Paint (how quickly the page responds to input), and Cumulative Layout Shift (how much the layout moves as assets arrive). These are the numbers that affect search ranking and, more directly, the experience of the person trying to book an appointment or buy a product.

Getting good field CWV requires all of the above, plus one more thing: servers that are close to your users. For Australian sites, this means hosting on infrastructure with an Australian region. A site deployed to Vercel with an Australian edge node will load measurably faster for a Brisbane user than the same site on a US-east server, even if the Lighthouse score is identical. It is not glamorous, but it is real.

The honest version

Performance is not hard. It is not even particularly technical once you understand the levers. What it requires is attention — the willingness to measure as you build, to treat the budget as real, and to make the slower-but-right choice when the faster-but-wrong one is sitting right there in the component library.

We build to a 1-second median because we believe your customers' time is worth that effort. Because a patient at a clinic, a customer looking at a product, a small business owner deciding whether to call you — they are not waiting for a website. They are making a decision. The faster you get out of their way, the more likely they are to make the right one.

Speed is not a feature. It is respect.