The JSHW Rebuild

The site was the counter-argument

JSHW sells digital transformation. Its own website was page-builder output that nobody had read the source of. For most businesses that's cosmetic debt. Here it directly contradicted the pitch — the site is the demonstration, and the demonstration was failing.

The audit found three compounding problems, and only one of them was about code.

• The output was unreviewed, not badly designed. The visual design held up. Underneath it, the builder shipped 909 KB of CSS and 537 KB of JavaScript to render one page — 97% of that CSS was never used by the page it shipped on. Nothing in the audit was structural to the design.
• The trust surface was thin. The interim production host runs on a .xyz domain — a namespace where roughly 55% of domains are classified risky by security vendors. The TLD doesn't get a site rejected on its own; it raises scrutiny, and what then gets scored is domain age, email authentication, corroborated identity and site quality. All four are controllable, which moved them from polish to launch-blocking.
• Placeholder content was a trust finding, not a content finding. A fabricated street address, three unattributed testimonials and a broken client-logo strip are precisely the pattern that classifies a site as disposable — to people and to automated scoring alike. They were cut rather than filled with invented substitutes.

Lighthouse, mobile and desktop

Previous: the live builder-made site. Current: the production build behind this article. Lighthouse 12.1.0, lab simulation, one run per condition, 1 September 2026.

Largest Contentful Paint fell from 8.57 seconds to 2.0 seconds on mobile, and to 0.5 seconds on desktop. Cumulative Layout Shift was already 0.000 on the old site — there was no layout-shift story here, just raw weight and blocking resources.

The image row is worth explaining rather than smoothing over. An earlier measurement of this same rebuild — while it still shipped with almost no imagery — put the total at 82 KB, a 95% reduction, and that figure is still sitting in this project's own baseline notes. It's stale. Real photography (eight images, licensed, none staged as JSHW's own team or clients) was added afterwards, and images are now the largest single line on the page. The honest current number is 343 KB — still a 78% cut, still an order of magnitude lighter than the builder site, just not the number a document written two days earlier still quotes. Catching that gap before publishing this page, rather than repeating the old figure, is the same discipline the rest of this series is built on.

Two other lines are worth more than the total. Font weight is identical — the same two self-hosted files either way, so it's the one line that couldn't move. And third-party requests dropped to zero, which matters beyond speed: the site's privacy policy states plainly that it loads no fonts, scripts, images or embeds from any other company. An outside measurement now corroborates that independently of anyone asserting it.

56 findings, each with an ID

Every finding carries a reference a commit can cite, so a fix traces back to the thing it was fixing. Severity runs P0 (live and breaking) to P3 (polish).

A lint rule that runs beats a convention that's remembered

This is a solo-maintained project with no second reviewer. So the build itself fails on the specific mistakes this codebase is prone to, and a rule gets added every time a class of bug is found.

Currently enforced, hard failures rather than warnings: placeholder #/#! hrefs, more than one <h1> per page, images with an empty or missing src or missing alt, images without width/height (the layout-shift guard), the hosting provider's temporary server hostname (which had leaked into the old logo's alt text), builder placeholder copy, a relative og:image, meta keywords, and unresolved TODO markers reaching the output.

Separately, a launch-check command sits in front of any deploy to an indexed host. It's deliberately not part of the normal check: it fails while the build contains content that is honest but incomplete, which is exactly the state a page is supposed to be in while it's being written on staging. A check that failed for that entire period would be useless. So the build warns on every run, and launch-check is the hard gate at the door.

What these numbers don't tell you

Held to the same standard as the results, and in the same document rather than a footnote.

• One page was measured, on each side. Capabilities, Impact, Collaboration and Reach Out are all real, built pages and none has a Lighthouse run recorded yet.
• One run per condition. Several, taken as a median, is the project's own standard before quoting a figure outside the team. This page doesn't meet it yet.
• No field data on either host. Core Web Vitals is a field metric; lab scores approximate it and aren't it.
• Mobile was verified in a desktop browser's emulator for layout, touch-target geometry and font-size maths — real WebKit behaviour and a physical iOS/Android pass are still owed.
• The accessibility manual pass hasn't happened. The automated 100 is a floor.