Proof of Work
Performance Log
We don't just claim the scores — we log them. Every entry below is a real Lighthouse run, what changed, and why. Keeping a 100 score takes ongoing upkeep — for most sites, a score in the 90s is more than enough.
July 16, 2026
🔗LOG-07The Problem: Dark-on-Dark Contrast Regression on Blog Series Footers
While checking our blog index sweeps, we discovered a contrast regression on the Suno post page. When we previously darkened our brand pink to #C4005E to clear contrast checks on light paper backgrounds, the change cascaded into our 'Explore the Series' callout footer block. Because this component sits inside a dark charcoal container (bg-[#222222]), using the darkened magenta created a dark-on-dark contrast clash that failed the WCAG minimum threshold, dropping our Accessibility rating back to 96.
The Solution
Restore context-specific color scaling across template surfaces:
- Updated our blog template series wrapper to check background density.
- Changed the heading element inside dark bg-[#222222] wrappers back to our bright brand pink #ED1E79, which easily passes contrast rules against dark surfaces.
This confirms our rule that contrast is directional: we use deeper tones on light backgrounds, and brighter values on dark backgrounds. Swapping the template back to the brighter pink cleared the warning and returned the blog post back to a clean 100.
July 16, 2026
🔗LOG-06The Problem: Render-Blocking Layout Styles and Cumulative Layout Shift (CLS) on Mobile Viewports
While our core page engines scored highly, two issues compromised our critical rendering path and mobile user experience. First, Astro's default build compiler loaded styles in separate external files (compiler.css and page-specific CSS), introducing two render-blocking network requests that cost 320ms of load latency. Second, mobile field telemetry caught a massive layout shift (CLS: 0.938) that was invisible to static headless audits. The shift had two structural culprits: the default browser stylesheet applying an initial 8px body margin that snapped to 0px after our Tailwind styles initialized, and a min-h-screen (100vh) wrapper that forced the layout engine to recalculate container scaling every time the mobile URL navigation bar retracted on scroll.
The Solution
A zero-shift styling architecture and optimized edge compilation rules:
- Injected build: { inlineStylesheets: 'always' } inside astro.config.mjs to inline all compiled CSS directly into the HTML document header, completely bypassing render-blocking stylesheet network roundtrips.
- Neutralized the default browser body margin before the initial paint pass by hardcoding a raw, inline html, body { margin: 0 !important; } reset style block into the page layout.
- Replaced the dynamic min-h-screen wrapper class with min-h-svh (Small Viewport Height) to lock container boundaries and prevent scroll-induced layout geometry recalculations.
With render-blocking stylesheet chains completely bypassed and layouts anchored to stable viewport geometry, Cumulative Layout Shift dropped from a critical 0.938 to an absolute 0. Real-world mobile rendering latency plummeted, securing a validated, perfect 100/100/100/100 mobile and desktop score.
July 16, 2026
🔗LOG-05The Problem: The CDN's Own 'Optimization' Features Were the Last Thing Between Us and 100
With the contrast fix shipped, Performance was still stuck hovering at 98–99. The diagnostics pointed at two scripts we never wrote and couldn't find anywhere in our codebase: rocket-loader.min.js and beacon.min.js. Both are injected by Cloudflare at the edge — the CDN rewrites the HTML as it passes through the proxy, so they exist in the delivered page but not in source control. Rocket Loader is Cloudflare's script-deferral feature, adding 4 KiB of JavaScript to solve a problem we'd already solved with our own deferred GA4 loading. The beacon is Cloudflare Web Analytics — a second tracker running alongside GA4, 11 KiB with a one-day cache lifetime that Lighthouse flagged. Fifteen kilobytes of third-party JavaScript, double analytics, and a cache warning — all from features marketed as making the site faster.
The Solution
Two toggles in the Cloudflare dashboard — zero code changes, zero commits:
- Turned off Rocket Loader (Speed → Settings). Our GA4 script already defers until first interaction; the site didn't need a second deferral layer.
- Disabled Web Analytics real-user measurement. GA4 is our analytics source of truth — the duplicate beacon was pure overhead.
Largest Contentful Paint dropped from 1.9s to 1.1s on throttled mobile — a 40% improvement — and Total Blocking Time hit 0ms. The lesson: audit what your CDN injects, not just what you ship. The only render-blocking flags on this site came from the layer that promised to speed it up.
July 16, 2026
🔗LOG-04The Problem: A Third Pink in the Codebase Failing Contrast on Small Text
Our daily Lighthouse monitoring workflow filed the issue automatically: Accessibility dropped to 96. The failing element was the eyebrow label above our call-to-action blocks — small, uppercase, tracked-out text like "Identify Your Next Vulnerability" — set in a hot pink #FF1053. Against our paper background it scores roughly 3.5:1. Large headlines can pass at 3:1, but this label is 12px, and small text needs the full WCAG 4.5:1 minimum. The deeper miss: #FF1053 isn't even our brand pink. Our palette pink is #ED1E79, and a search of the codebase found the stray value in five separate files. Color drift happens quietly: one eyeballed hex during a late-night build, copied twice, and suddenly the "brand color" exists in three versions — one of which locks readers out.
(Mobile)
(Desktop)
The Solution
One find-and-replace across the repository — then a second lesson one round later:
- Replaced every instance of #FF1053 with #C4005E — a deeper hot magenta that keeps the pop-art energy but clears 4.5:1 on the paper background (roughly 5.4:1).
- The desktop audit then caught the flip side: the darkened pink failing on dark card backgrounds where the brighter pink had passed. Those instances went back to #ED1E79.
The final rule: #C4005E on light backgrounds, #ED1E79 on dark backgrounds and large display text. One hue, two contrast-safe tiers — the same discipline we applied to oxblood. Contrast is directional: darkening a color to pass on paper can make it fail on ink.
July 13, 2026
🔗LOG-03The Problem: Failing the Contrast Check Inside Callout Boxes
When we recently added contextual internal links to our blog posts, we styled them with our brand's oxblood red #B93B26. Against a standard paper background, this color passes accessibility checks perfectly. However, we placed some of these links inside gray callout boxes. That slightly darker gray background ate into our contrast margin, dropping the ratio below the WCAG 4.5:1 minimum. Lighthouse caught it immediately and knocked our Accessibility score down to 96. We document these drops because it is a perfect example of how small, easily overlooked design choices compound. Accessibility isn't just a technical metric to game—it is a user-facing reality every single time someone loads a page. Low-contrast text physically locks people out of your content. These small missteps are common, but more importantly, they are entirely within our control to fix. We value 100/100 Accessibility scores because they mean we aren't leaving any readers behind.
(Mobile)
(Desktop)
The Solution
One CSS value needed a slight adjustment:
- Darkened the body link color from #B93B26 to #8A2A1A in our Astro templates.
This new hex code is the exact same hue, keeping the site firmly on-brand, but it securely passes the contrast check on both the standard paper background and the gray callouts.
July 1, 2026
🔗LOG-02The Problem: Low-Contrast Text on the Blog Index
Adding a read-time label to each blog post row dropped Accessibility to 94 on both mobile and desktop. The muted gray used for that text #8a8880 scored roughly 3.1:1 against the paper background — below the 4.5:1 minimum WCAG requires for small text. Lighthouse flagged the same span six times, once per post row.
(Mobile)
(Desktop)
The Solution
One value needed to change:
- Darkened the read-time text from #8a8880 to #6b6a63.
Still visually secondary to the date and category, but now clears 4.5:1 against the background. One color value changed, no layout impact.
June 31, 2026
🔗LOG-01The Problem: Google Analytics (GA4) Flagged as Unused JavaScript
Google Analytics (GA4) loads a script that Lighthouse flags as 67 KiB of unused JavaScript. Most of that code doesn't run during a page's first few seconds — it's there for later tracking events, not initial render. That's a common tradeoff: real analytics data costs you page-speed points.
(Mobile)
(Desktop)
The Solution
Three options were on the table:
- Leave it alone and accept the flag.
- Drop GA4 for a lighter analytics tool.
- Delay GA4 until the visitor actually interacts with the page.
We went with option 3 — GA4 now loads only after a scroll, click, or mouse move, with a timeout fallback so visitors who bounce without interacting still get counted. Analytics stays accurate, but the script no longer competes with the content for load time.