Two Old Websites, One Weekend, and 41MB We Didn't Need

Two client sites, both built between roughly 2007 and 2011, both still live, both still technically working. That last part is doing a lot of quiet damage — "still works" is exactly what lets a site coast for fifteen years without anyone noticing what's actually wrong with it.

This weekend I sat down with both and went through them properly, top to bottom: an artist's portfolio site and an illustrator's gallery site, each with a decade-plus of real client history behind them. Neither one was broken. Both needed work anyway.

"Still Works" Was Hiding a Lot

Once you actually open the hood on a 2009-era hand-coded site, the list writes itself: XHTML doctypes nobody's used in over a decade, no mobile viewport meta tag at all (so phones were rendering the desktop layout and zooming out), headers and navigation copy-pasted across every single page, and images that were obviously just "Save As" exports from a decade-old workflow — some of them ten times larger than they needed to be.

None of that shows up when you glance at the site and it looks fine. It shows up when a phone loads it, when a screen reader hits it, when a search engine crawls it, or when the client asks for one small nav change and it means editing the same six lines on nine different pages.

The Numbers That Actually Mattered

The image folders alone were carrying 65MB across 327 JPGs, re-compressed down to 24MB with no visible quality loss — a 63% cut, just from stripping pointless embedded metadata and re-encoding at a sane quality. One "thumbnail" turned out to be a 150×150px image weighing 1.5MB. It's now 14KB.

The old image galleries were running on Lightbox2 with Prototype and Scriptaculous underneath — 246KB of JavaScript dependencies to open a bigger picture when you click a thumbnail. We replaced the whole stack with one dependency-free script, under 5KB, built on the browser's own native dialog element instead of a decade-old library.

And the color palette got the same treatment: instead of eyeballing "does this look readable," we ran the actual WCAG contrast math against every text/background pair on the site. Four combinations genuinely failed — including, on one site, the color used to highlight which page you were currently on, which meant the site's own emphasis state was harder to read than its plain text.

Actually Mobile-Friendly, Not Just Smaller

Neither site had a mobile viewport meta tag, which meant every phone was rendering the full desktop layout at full desktop width and then zooming the whole thing out to fit — tiny text, tiny tap targets, the works. That's a one-line fix, but it's the one-line fix that exposes everything else: once a phone is actually rendering at its real width, every fixed-pixel container on the page suddenly overflows the screen.

So every hardcoded width: 700px became a max-width with width: 100% underneath it, nav bars that used to force one line with white-space: nowrap got a breakpoint to wrap instead of clip, and font sizes moved to clamp() so text scales fluidly between a phone and a wide desktop instead of jumping at fixed breakpoints. One of those fixes caught a second bug on its own: a fixed-pixel line-height that had been fine at the old, tiny font size became smaller than the text itself once the font size started scaling up — lines were nearly overlapping until that got caught too.

Meeting WCAG, With the Math to Prove It

Beyond the contrast numbers above, this meant real semantic HTML — actual header, nav, main, and footer landmarks instead of generic divs, a skip-to-content link verified with an actual keyboard test rather than just "the link appears," and a heading hierarchy audit that turned up pages with zero real headings at all, or a jump straight from a hidden site title to a visible sub-heading with nothing in between.

Old image galleries had a subtler problem: each thumbnail rendered as two images — one visible, one purely for a hover effect — both carrying the same alt text, so a screen reader announced every single piece of art twice. And a couple of pages reused the same element ID for two different things, which is invalid HTML and breaks anything that targets that ID specifically. Both are the kind of bug you'd never spot by looking at the page, only by actually using it the way someone with a screen reader or a keyboard-only setup would.

SEO That's Actually Different Per Page

Both sites had one meta description, copy-pasted identical across every single page — search engines have no way to tell a gallery page from the contact page from the homepage when they all describe themselves with the same sentence. Every page now has its own real description, plus full Open Graph and Twitter Card tags so a shared link actually shows the right title, description, and image instead of whatever the platform guesses. Both sites also got a proper robots.txt and sitemap.xml, neither of which existed before, and a full crawl for dead links and broken images — the kind of thing that accumulates quietly over a decade and nobody notices because nobody's clicking every single link on a site they already know.

The Bug That Would Have Shipped Quietly

The best find of the weekend wasn't a metric, it was a bug that never would have shown up in a screenshot. After building the new lightbox, closing it left the entire page unclickable — nothing responded, no console errors, nothing visibly wrong on screen.

The cause: a single CSS rule set the lightbox's `display` property unconditionally, which quietly overrode the browser's own built-in behavior for hiding a closed dialog. The result was an invisible, full-screen element still sitting on top of the page, silently swallowing every click underneath it. One line of CSS, scoped correctly, fixed it — but it's exactly the kind of bug that passes every visual check and only shows up when a real person tries to use the thing.

Why Bother, If It "Still Worked"

Because a site that only technically works is quietly costing its owner something every day it stays that way — mobile visitors who bounce off a zoomed-out layout, screen reader users who hit a page with no landmarks and no alt text, search results that never quite rank because the meta description is the same on every page, and a client who has to ask a developer for a nav change instead of it just working.

Both of these sites are on domains their owners actually own — not a marketplace profile, not a social platform that could change its algorithm tomorrow. That's the right instinct. It just needs a website behind it that's actually holding up its end.

We turned everything we learned across both projects into a reusable checklist and a starter template, so the next old site on our list goes faster and skips the mistakes we already made twice. There's always a next old site.