ZenMasterWorks ← Back to the blog
July 7, 2026 · Performance & Accessibility · 6 min read

Eight Blueprints, Zero Gaps: The Last Mile to 100

We publish our PageSpeed scores as verified facts, not marketing copy — checked and dated, not rounded up. This week we ran the same discipline against all eight industry website blueprints. None of them started at 100. Here's what was actually wrong, and what it took to fix it.

100Performance
100Accessibility
100Best Practices
100SEO

That's the final state, all eight blueprints, mobile, verified July 7, 2026. Getting there meant reading what PageSpeed Insights actually flagged on each page, fixing the specific rule causing it, computing the exact contrast ratio before shipping a color, and retesting — one page at a time, no batch guesses.

Contrast bugs, six different ways

Nearly every failure traced back to the same habit: a brand accent color — coral, amber, gold, rose — used directly as text color without checking it against the background it would actually render on. On paper or cream, the bright versions of these tones land around 3.1–4.1:1. AA requires 4.5:1. The gap looks small on a color picker and is completely real to a contrast checker.

  • Cleaning: footer text (4.31:1), plan-card frequency labels (3.39:1), and a bold guarantee callout (3.12:1) — three separate components, same root cause.
  • Electrical: a section eyebrow and a contact-section paragraph, both using the bright accent directly on backgrounds it wasn't built for. Took two fix rounds to catch both.
  • Plumbing: not a color-choice problem — a genuine CSS bug. Two rules targeted the same "Call Now" button; a more specific selector silently overrode the intended navy-on-white styling with white-on-orange (3.12:1), invisible in the source until PageSpeed flagged it.
  • Landscaping, Pest Control: our own header retrofit introduced this bug. We rolled out a new stacked phone-link pattern site-wide and reused an existing "-deep" color token assuming it would read as dark enough everywhere. It didn't — 3.74:1 and 4.09:1 against the specific cream background those two pages use.
  • Salon & Beauty: a topbar service badge, one shade too light at 4.08:1.
  • Model: a footer byline color deliberately darkened past its parent's already-passing value (3.19:1), plus a link embedded mid-sentence that relied on color alone — no underline, negligible hue contrast against the surrounding text — to be recognized as a link at all.

One payload bug, three pages

Trucking, Model, and Landscaping were all serving the 720p version of their Mixkit hero video instead of the 360p variant our own hero-video standard calls for. The page looked identical — that's exactly why it slipped through. It just cost roughly 2.9MB of unnecessary transfer and enough Largest Contentful Paint delay to knock Trucking's Performance score from 100 to 99.

Adjacent, not part of this pass

While checking the Content-Security-Policy header for a mixkit-related warning in Chrome's Issues panel, we found eight self-redirect loops in the site's .htaccess — and they turned out to be the same eight loops we'd already logged fixed two days earlier. Somewhere between that fix and the copy we worked from this week, the correction didn't stick. Fixed again, and we're checking what's actually live on the server before calling this one closed. We also confirmed the CSP media-src allowance for Mixkit was already correctly configured in the pending .htaccess — the live violation PageSpeed caught was from whatever's currently deployed, not from anything wrong in the fix.

(Full account of the regression, and the open question of which .htaccess is actually live, is logged as incident 11.85 in the design system.)

The full tally

  • CleaningFooter, plan labels, guarantee text — all under 4.5:1
  • PlumbingDuplicate CSS rule silently overriding button contrast
  • LandscapingNew header-phone token too light on cream
  • ElectricalEyebrow + contact paragraph on navy, two rounds
  • Pest ControlSame header-phone bug, caught proactively before it was reported
  • Trucking720p hero video → standard 360p encode
  • ModelSame video bug, plus footer contrast and a color-only link
  • Salon & BeautyTopbar badge, 4.08:1 → 5.48:1

What we're changing going forward

Two new standing rules came out of this pass, now logged in the design system as incidents 11.78 through 11.86:

  • Brand accent colors are backgrounds and borders by default, not text colors. Any time coral, amber, gold, or rose is used as direct text, it gets a measured contrast check against its actual rendered background — light and dark — before it ships. Reusing a token that passed somewhere else isn't a substitute for checking it in the new context.
  • Mixkit hero video URLs get a suffix check. -360.mp4, not -720.mp4, every time — added to the existing CRF 32 / 960×540 / faststart checklist, since the wrong file renders identically and only shows up as a payload regression.
The pattern underneath almost every one of these: a bug that renders correctly and only fails when something actually measures it. That's the whole argument for testing against the real tool instead of eyeballing a color or a video file and moving on.

Every blueprint on this site is held to the same checklist as our own homepage — published, dated, and not retouched after the fact.

See all eight blueprints →