60% of Your Website Is Code Nobody Wrote on Purpose

The working title for this piece — drawn from the project's own editorial slate — says 60%. That number was a placeholder, written down before anyone had actually measured it. The real figure, measured across every template rather than assumed from one, is higher: roughly seven pages in ten of code that shipped to every visitor's browser and did nothing for them. Not slow. Not suboptimal. Unused — downloaded, and in the case of the JavaScript, at least partially executed, for zero effect on what the visitor ever saw.

What "unused" actually means

When a browser loads a page, it doesn't just download the CSS and JavaScript files a page links to — it has to parse every rule in every stylesheet against every element on the page, and load and evaluate every script, before it can know which of those rules and scripts actually apply. A CSS rule written for a component that isn't on this page still gets parsed. A script written to run a carousel, a modal, or a booking widget still gets downloaded and, depending on how it's written, still gets executed enough to check whether its target element exists — before finding out it doesn't and doing nothing.

That work is real. It happens on every page load, for every visitor, on whatever device they own — not once at build time, but every single time someone arrives. A rule or a script that's never used doesn't cost the business anything after the first time someone notices it. It costs every visitor, every time, for as long as it keeps shipping.

Measured, all five templates, one instrument

Lighthouse 13.4.1, direct CLI runs against both live hosts, same session, same flags both sides — the exact byte figures behind the "Reduce unused CSS" and "Reduce unused JavaScript" diagnostics, not the rounded numbers a dashboard shows.

Two things stand out more than the averages. First, the old site's unused-CSS figure barely moves — 876 to 889 KiB, on every template, on both devices. A page that varies wildly in what it actually contains ships an almost identical slab of dead CSS regardless, which is only possible if that CSS was never scoped to any individual page in the first place. Second, the rebuild's number isn't "much lower." It's zero, on all ten runs — read directly from Lighthouse's own coverage data, not rounded down from something small. Every rule and every script the rebuild ships gets used by the page it ships on.

Why this happens — and it isn't a vendor problem

Page builders and template platforms solve a real problem: a business needs a working, reasonably attractive site this month, not after a six-week custom build. To do that, they ship a shared library of every component a customer might ever choose — accordions, carousels, tabbed panels, pricing tables, booking widgets, dozens of layout variants — as one bundle, because the platform can't know in advance which of its features any given page will actually use. Loading everything, everywhere, is the simplest way to guarantee that whatever a page editor drags onto a page will work. That's a reasonable trade for the problem the tool is solving.

The defect isn't the tool making that trade. It's a site going live, and staying live, without anyone checking what that trade actually cost once the page was finished — measuring what got used against what got shipped, and trimming the gap. That check is exactly what a page-builder workflow doesn't naturally prompt anyone to do, because the platform's job ends at publish, not at audit.

What this actually costs a real visitor

This series has already measured what the extra weight did to load time. On mobile, the old site's Largest Contentful Paint ran 8.6 to 10.8 seconds across the five templates — against the rebuild's 1.7 to 2.6 seconds. That's not an abstract score. It's the difference between a page that has finished appearing before most people have decided whether to wait, and one that's still loading after most people have already left. Every one of those extra seconds is spent by a real visitor, on a real device, doing nothing but waiting for bytes their browser didn't need in the first place.

It isn't only time. A phone parsing 876 KB of CSS and partially executing 250 KB of JavaScript it will never use is doing real work — real CPU cycles, real battery drain — for a result the visitor never sees. On a capable, plugged-in laptop that cost is easy to not notice. On an older or budget phone, on battery, it's the difference between a page that feels instant and one that makes the device warm.

And for a meaningful share of visitors, especially on mobile, that weight has a direct cost in money. Mobile data is not free, and in many of the markets this kind of consultancy actually serves — including South Africa, where this business operates — a gigabyte of mobile data is a real, felt expense, not a rounding error against an unlimited home-fibre plan. Shipping 1.5 MB for a five-page brochure site, most of it unused, is asking every visitor on a metered connection to pay data costs for a library of components their page never renders. A visitor priced out of waiting, or priced out of the data, doesn't experience your pitch at all — they just leave, and there's no dashboard that tells you why.

The sustainability angle, made concrete

Every kilobyte transferred over a mobile or fixed network, and every CPU cycle spent parsing and executing it, draws real electricity — at the device, across the network path, and at whatever server or CDN answered the request. None of that is exotic or disputed; it's the same physics that makes a phone warm when it's doing unnecessary work. Multiply one page's 1.2 MB of pure waste by however many visits a site gets in a year, and "unused code" stops being a performance nicety and becomes a measurable, avoidable draw on real energy — spent producing precisely nothing for anyone.

That framing matters here specifically. This project already treats impact as one of its stated values, not just a page in the main navigation. A site that ships five times the necessary weight, on every page, to every visitor, indefinitely, is a strange place for that value to stop applying. The fix isn't a carbon offset or a statement — it's the same discipline that produced the zero-unused numbers above: stop shipping what isn't used. That's a smaller, less glamorous claim than "we're sustainable," and it happens to be one this project can actually measure and defend, which is the whole discipline this series has tried to hold itself to throughout.

Why this is a business continuity question, not just a technical one

A business that depends on its website to generate enquiries has a direct stake in how much of that website's weight is dead. Slower pages measurably cost attention — this project's own Core Web Vitals numbers, logged elsewhere in this series, show the old site's mobile Largest Contentful Paint blowing past every recognised "good" threshold on every template, not just the homepage. A visitor who leaves before the page finishes rendering never reads the pitch, never sees the call to action, and never becomes an enquiry — and unlike a missed call or an unanswered email, that loss doesn't show up anywhere as a specific, nameable event. It just shows up, eventually, as a conversion rate that's quietly worse than it should be.

There's a second, less visible cost too: search engines crawl and re-crawl a site using their own compute budget, and a heavier, slower page is more expensive for a crawler to process than a light one — the same tax on a search engine's crawler that a human visitor pays with their own battery and patience. A site that's cheap to load is cheap to index, cheap to re-index when it changes, and cheap for anyone — human or automated — to fully experience. That's not a growth hack. It's the baseline cost of being easy to do business with, paid once, in the build, rather than by every visitor, forever.

How zero actually happened

The rebuild's CSS is hand-authored, not generated: one small set of design tokens, then a handful of files split by concern — base rules, layout, typography, components, forms — each one written for the components this specific five-page site actually has, not for a library of components it might one day need. Nothing gets added speculatively; a class exists because a page uses it. The JavaScript follows the same discipline from the other direction: this project's own standing rule is that if a feature needs JavaScript to work at all, the feature itself gets reconsidered first — which is why there's barely any script to audit for waste in the first place.

That's a genuinely different posture from "optimise the bundle" tooling — no build step strips unused rules after the fact, because there's nothing unused to strip. The discipline happens at the point someone writes a line of CSS or JavaScript, not afterward in a pipeline. It's a harder habit to hold than installing a purge tool, and it's also the only approach that gets you to an honest zero rather than a smaller, still-nonzero number.

What this doesn't settle

• Lab measurement, not field data. Every figure in this piece, like every figure in this series, comes from a single simulated run per condition on synthetic hardware. Neither host currently has real-user monitoring in place, so there's no field confirmation yet of how these numbers translate to actual visitor devices and networks.
• Five pages is a favourable case. Zero unused CSS is a genuinely harder target to hold as a site grows — more pages and more real variation make it easier for a rule written for one page to go quietly unused on another. The discipline that produced this number needs to be maintained deliberately as the site grows, not assumed to persist on its own.
• This is about CSS and JavaScript specifically. Fonts and images carry their own weight and their own budget, covered elsewhere in this series — this piece isn't claiming the whole page is minimal, only that the code driving it no longer carries any dead weight.
• The manual accessibility pass is still owed, as stated throughout this series — nothing here changes that.