Performance is not a plugin — it is a series of deliberate engineering decisions. From eliminating lazy-loaded homepage sections to replacing 381 arbitrary font sizes with a type scale, here is how we engineered intactic.net for Core Web Vitals, and the harness that keeps it honest.
Every performance story needs a measurement system before it needs an optimization, so that is where we started. Our harness lives in the repository: Lighthouse CI runs eight production URLs three times each on simulated Slow 4G with a 4x CPU slowdown, a bundle analyzer dumps the client chunk graph, and a Web Vitals reporter ships real-user LCP, CLS, FCP, INP, and TTFB from every visitor into our analytics data layer. The baseline is committed to the repository in docs/perf — numbers without a reference point are just vanity.
The first baseline told us where the truth hurt. The homepage transferred 342 KB of gzip JavaScript, the heaviest page in the app, because hero and motion code loaded eagerly. The insights and case-studies pages transferred over 420 KB of images because image optimization is disabled in the Workers runtime. And one number was already excellent: cumulative layout shift measured 0.000 on every single route, which told us the layout system was fundamentally sound.
The homepage fix changed how we think about rendering. The sections had been client components that hydrated and then lazily revealed via IntersectionObserver — a pattern that looks progressive but delays content and adds JavaScript to the critical path. We moved the homepage sections to server rendering and removed the lazy loader entirely. The sections now arrive in the document, not after hydration, and the IO dependency disappeared from the bundle.
Typography was its own performance story. A design-system audit found 381 arbitrary font-size utilities scattered across the codebase — every one a bespoke value the browser had to interpret and every one an opportunity for inconsistency. We replaced them with a deliberate type scale built on CSS variables. The visual design did not change by a pixel, but the CSS got smaller, the design got more consistent, and future pages inherit the scale automatically.
The data layer got the same treatment. The public list queries all followed a predictable shape — filter by published, order by sort order or publish date — so we added composite indexes matching those shapes in a dedicated migration, trimmed list projections to exclude multi-kilobyte markdown bodies from list reads, and added request-scoped memoization so a single request never fetches the same rows twice. None of this is exotic. All of it compounds.
The caching strategy carries the remaining weight. OpenNext incremental caching runs on R2 with a D1 tag cache and a Durable Object revalidation queue, so public pages serve from cache with a short s-maxage window and revalidate in the background. Fingerprinted build assets ship immutable cache headers. After the migration, our time to first byte measured under 200 milliseconds from APAC edge colos.
The honest summary: we did not find one magic lever. We found a CLS that was already perfect because the layout system was disciplined, a bundle that got lighter when we stopped shipping code the server could render, queries that got faster when the indexes matched the queries, and a cache that got hit more often because we configured it deliberately. Performance engineering is mostly the discipline of measuring first and refusing to ship regressions — and the harness we committed to the repository is how we hold ourselves to that.
