It has every excuse to be slow. It loads in under a second.

The thinking that doesn't show up on screen.

The most important decisions on this site were made before a single pixel was drawn. Not the colour, not the typeface — those came later. First came the harder questions: who is this site actually for, what does that person need in the ten seconds after they land, and what does the brand need them to do next. For a 16-year-old musician fronting a live band, the answer wasn't "stream my music." It was "book us, or come to a show" — so the whole site is designed backwards from a booking and a gig listing, not from a Spotify embed.

The brand frame was settled before the design, too. Miabella performs with deliberate stillness on stage — what we ended up calling silent intensity: you are there for the music, not for pyrotechnics. By naming that frame ourselves, we got to define how the site should feel — composed, cinematic, premium — rather than letting it default to the busy, everything-moving look most band sites reach for. That single decision shaped every visual choice that followed.

This is the part of a build nobody itemises and clients are never quite sure they paid for, because it doesn't appear in the finished product. It is also the part that decides whether the finished product works. We wrote a whole piece on why this is where the money in a site actually goes — a pretty website is cheap; a site that works isn't — and this build is that argument made concrete.

Make it cinematic. Make it instant. Pick both.

The design language we landed on is unapologetically heavy. Dark, high-contrast, black and white with a single firebrick-red accent. Big display type set in Space Grotesk, mostly uppercase. Full-bleed hero imagery and video. Images that sit in grayscale and bloom into colour as you move through them. A glass navigation bar with a live backdrop blur. Red glow on the calls to action. Cinematic, custom-eased motion on essentially everything that moves.

And then the constraint that contradicts all of it: it had to be fast — genuinely fast, on a real phone, on real Northern Irish mobile data, for an audience that is mostly browsing on the bus, not on a fibre connection at a desk. Not "fast for a site that looks like this." Just fast.

Spectacle and speed are usually a trade. The job was to refuse the trade.

Most studios resolve that tension by quietly giving up one side of it. They either strip the design back until it's bland enough to be quick, or they ship the spectacle and let the load time slide — a hero video that takes four seconds to appear, a layout that lurches as web fonts swap in. We took the contradiction at face value and treated it as an architecture problem, not a design compromise.

By the textbook, this is a slow site.

If you handed the design spec to a performance purist, they'd flinch. Almost every ingredient is on the list of things that tank a page:

• ✕Full-bleed hero video and large photographic imagery on nearly every page.
• ✕Custom display and body fonts, plus a Material Symbols icon font for the UI.
• ✕Grayscale-to-colour filters, hover zooms, and backdrop-blur glass surfaces — all GPU work.
• ✕Cinematic, custom-cubic-bezier motion on cards, images, and navigation.
• ✕A deep site: a 16-essay chronicles section, gig archives, video archives, galleries, and media-rich weddings and shows pages.

Any one of these, done the default way, is a second of load time. Stacked together on a WordPress page builder, they'd produce exactly the four-second, layout-shifting, plugin-laden site we spend our days replacing. The design didn't get safer. The engineering underneath it got smarter.

The spectacle is real. The delivery is boring.

The trick isn't a trick. It's a set of deliberate, slightly boring engineering decisions, all made possible by the planning in section 01:

The page that arrives is already finished.

There is no CMS, no PHP, no database, no query running while you wait. A small Node build step takes the source — shared components, and dynamic data like the gig calendar and the chronicles index living in JSON — and pre-renders all of it into flat, static HTML. The client-side fetch() logic that assembles the page during development is stripped out of the output, so the browser never waits on JavaScript to see content. The first paint is the finished page. Crawlers and AI models see the same complete HTML a human does.

The heavy parts are made cheap, not removed.

• →Fonts are self-hosted on the same Cloudflare edge and preloaded, so there's no third-party origin hop and no flash of unstyled text.
• →Imagery is webp with responsive variants (a phone pulls a 655-pixel-wide file, not a desktop-sized one), sized so the layout never shifts as images load.
• →Hero video is treated as decoration, not content — the page is usable and the headline is readable before it plays a frame.
• →The filters, zooms, and blur are GPU-composited transforms, which modern phones do essentially for free.

It's served from the edge, for nothing.

The whole site is static files on Cloudflare Pages, served from 300-plus cities. There's no server to wake up, nothing to scale, and the hosting bill is £0 a month. The thing that makes it fast is the same thing that makes it cheap to run and almost impossible to break: there are barely any moving parts between a visitor and the content.

What "under a second" actually means.

Here is the part where most case studies paste a screenshot of four green 100s and call it proof. We're going to be more careful than that, because we've written at length about why a lab score full of 100s can be a lie. The metric that matters is what a real device on a real connection experiences:

The largest thing on the screen finishes painting in under a second, and nothing jumps around while it does (a zero CLS is the part you feel even if you can't name it). The lab Performance score sits at 93, not 100 — and we've deliberately not chased the last seven points, because they'd mean compromising the design for a number that doesn't change what the visitor experiences. That's the whole argument of green doesn't mean green: optimise for the phone in someone's hand, not the scoreboard.

For comparison, the typical mid-budget WordPress site we audit before a rebuild scores 28 to 55 on Performance, with an LCP north of four seconds and a hosting bill of £25 to £120 a month. Same kind of content. A heavier-looking design, even. Wildly different result — because the result was decided by the architecture, not the appearance.

The honest bit.

No build is perfect, and a case study that pretends otherwise isn't worth reading. Three things we'd change with hindsight:

The site still ships a Material Symbols icon font for a handful of UI glyphs. That's a whole font file pulled for maybe a dozen icons; inlining them as SVG would shave a request and a few kilobytes. It's on the list.

The static build was, honestly, retrofitted. The site began life assembling its components in the browser at runtime for developer convenience, and we later pre-rendered all of it at build time. The end result is identical for a visitor, but if we were starting again we'd bake components in from the first commit rather than converting later. It's the approach we now use by default — and it's why this very site is built that way from the ground up.

And the imagery is webp; some of the larger hero stills would compress further as AVIF with no visible quality loss. A future pass will get there. None of these change the sub-second story — but leaving them unsaid would.