We rebuilt our own site by removing things

Our own website had two of everything. Two stylesheets, two JavaScript bundles, two versions of every template — one for the site people saw, one for the site we had replaced. A flag in a config file decided which one you got, and for months it had always answered the same way.

That is a normal state for a rebuild. It is a bad state to leave running, because the version nobody looks at still costs something. Every page shipped 28KB of JavaScript written for a layout that no longer existed. Every deploy carried 240KB of CSS that no browser ever parsed. And every change had to be made twice, or made once and quietly forgotten in the other copy.

So we deleted it. 6,865 lines, 560KB of assets, nineteen templates' worth of markup for a site that had already been replaced. The result is a website that does more than it did last month and weighs considerably less.

Less is more is a budget, not a mood

"Less is more" gets used as a taste argument — fewer boxes, more whitespace, calmer type. That part is real, and it is the easy part. The version that actually changes how a site feels is the one you can count: every element on the page has to earn its bytes, its parse time and its paint.

A hero photograph earns it. A second copy of the same photograph, downloaded at 2400px because nobody wrote a srcset, does not. A custom cursor earns it if it tells you what you are about to click. A carousel of client logos that nobody scrolls does not, and we cut it from the original design before it ever shipped.

The discipline is the same one we use on client work: you are allowed to add something beautiful, as long as you can say what it costs and what it replaces.

What came off

The full list, because vague claims about "optimisation" are worth nothing:

• The old stylesheet and the old bundle. main.css (240KB across both copies) and main.js (74KB) are gone. What the current site genuinely used out of that bundle — search, the language switch, the cookie banner, the intake modal, the client strip — was lifted out verbatim into one 11.7KB file. Not rewritten. Lifted, so nothing could change behaviour on the way.
• Five "critical CSS" files that no template had included since the rebuild, plus a mobile navigation partial for a navigation that no longer exists.
• A 3D diorama — 45KB of JavaScript and a 167KB texture — that had been replaced by the fog hero and was still sitting in the repository.
• A work modal that opened case studies in an overlay. It bound to class names the current templates never emit, which is a polite way of saying it had been dead for months.

What we made lighter instead of removing

The hero is a photograph of fog moving through the pine ridge outside Leiria, rendered in WebGL with a domain-warped noise pass in front of it. It is the most expensive thing on the site, and it stays, because it is the argument: we build things that are harder than they need to be, carefully.

What it does not need is to arrive twice. The page was preloading a 113KB JPEG for the mobile hero and separately downloading a 247KB version as the WebGL texture — the same photograph, twice, at two sizes. Now there is one image in three formats: 27KB of AVIF for browsers that speak it, 29KB of WebP for the rest, and the original JPEG underneath for anything older. Measured against the original, the AVIF scores 41dB PSNR, which is the technical way of saying nobody can see the difference.

The same applied across the page. Full-bleed images asked for 2000px regardless of the screen in front of them. They now carry a ladder of widths, so a phone downloads a phone-sized photograph: 461KB of imagery on mobile, down from over a megabyte.

The bug that only a fresh browser could see

One find is worth writing down, because it is the kind of thing that hides for months.

Our server tells browsers to cache JavaScript for a year, marked immutable. That is correct, and it is safe, because every script tag carries the file's modification time as a query string — change the file, change the URL, get the new code.

Except one file was not loaded by a script tag. It was imported by another module, by a plain path with no version on it. So when we changed it, returning visitors kept running the old copy — for a year, if they stayed that long. The symptom was small and infuriating: the loading screen, which is supposed to appear once per session, appeared again on the way back to the homepage.

The fix is three lines: the import now goes through an import map that the server writes with the version in it. The lesson is the part worth keeping — a cache policy is only as good as the weakest URL in the dependency graph, and module imports are easy to forget.

How we knew nothing broke

Deleting 6,865 lines from a live site is only responsible if you can prove the output did not change. So we did it the boring way: rendered all 33 routes before the surgery, rendered them again after, and compared them byte for byte, normalising only the things that are supposed to differ between two requests — the form's anti-spam nonce and the clock in the footer.

Zero differences, except the one block of markup we meant to remove. Then the same sweep against production: every route, every status code, no console errors. That sweep is now a file in the repository, so the next person to touch this can run it before they promise anything.

Where it landed

Lighthouse reports 100 for performance, accessibility, best practices and SEO on desktop across every page type, and 96–99 on mobile. Largest Contentful Paint is 0.4–0.6s on desktop. There is no build step, no bundler and no framework: the site is server-rendered PHP against a headless CMS, deployed over FTP, with two minified files maintained by hand.

That last part is deliberate. A studio's own website is the one project where you are both client and engineer, and it is the honest place to find out whether your opinions survive contact with a deadline. Ours did, mostly. The parts that did not are now deleted.

The part that is not about our site

Most of the sites we are asked to fix are not slow because of one bad decision. They are slow because of forty small ones, each defensible on the day, none of them ever removed: a second analytics script, a font nobody uses, a component library for three buttons, an image pipeline that gives a phone a desktop photograph.

Nobody ever schedules the removal. It is not a feature, it does not demo well, and it is invisible to everyone except the person waiting for the page. It is also, reliably, the cheapest performance work available — and the only kind that makes the design better at the same time.

If your site feels heavier than it should, that is usually not a rewrite. It is an inventory.