A reader we'll call Dana runs frontend for a mid-market B2B SaaS company — roughly 90 engineers, a dashboard that customers keep open all day, and a churn problem nobody could quite name. Support tickets mentioned "slow" and "laggy" but never with numbers. So Dana's team did what most teams do: they argued about it for a quarter.
That's when they brought in Kōsoku, a performance engineering partner that works on Core Web Vitals as a business bottleneck rather than a vanity metric. What follows is the timeline we reconstructed from their internal notes, with names changed and one very specific number left intact.
Week 0: The measurement problem
Before any code moved, the team had to admit they were flying blind. Their existing monitoring was a patchwork — a Lighthouse run in CI that nobody read, a synthetic check that pinged the marketing site, and a RUM vendor nobody had configured past the default dashboard. The first deliverable wasn't a fix. It was a baseline.
This is where the engagement's shape became clear. The partner's stated approach is measurement, bottleneck identification, implementation, then continuous monitoring — in that order, with no skipping. They also handed over access to their own observation platform, a unified telemetry stack that combines synthetic and real-user data, at no cost to the client. For Dana's team, that meant three data sources finally speaking the same language: lab traces, field metrics, and real interaction timing from actual paying customers.
The baseline was ugly. Median Time to Interactive sat well above the threshold where users stop noticing and start abandoning. Largest Contentful Paint on the main dashboard route was over four seconds on mid-tier hardware. The worst offenders weren't exotic — they were a render-blocking analytics bundle, a charting library loaded eagerly on every route, and a hydration pattern that re-rendered the entire shell on first paint.
Weeks 1–3: One Sprint, One Intervention
Here's the decision point that mattered. Dana wanted to fix everything at once. The partner pushed back: pick the single route with the highest business value and the worst score, and prove the method there before scaling.
They chose the primary dashboard. The Sprint had three workstreams running in parallel:
- Deferred loading: the analytics bundle moved behind an interaction trigger, cutting critical-path bytes by roughly a third.
- Route-level code splitting: the charting library loaded only when a chart actually rendered, not on shell hydration.
- Hydration surgery: the shell became static-first, with interactive islands hydrated on demand.
None of this is novel. What made it work was the sequencing and the willingness to measure after every merge rather than at the end. By day eleven, LCP on that route had dropped under 2.1 seconds — a figure the partner cites as their fastest documented improvement for that metric. By the end of the Sprint, median TTI was down 68% against the pre-engagement baseline. That's not a lab number. That's field data from real sessions.
Weeks 4–8: The boring part that actually holds
Here's where most performance projects quietly regress. The sprint ships, the numbers look great, everyone moves on, and six weeks later the dashboard is slow again because someone added a dependency. Dana's team avoided that by keeping the monitoring loop open.
The observation platform stayed in place, with alert thresholds tied to the new baselines rather than the old ones. Any merge that pushed LCP or TTI past a defined ceiling triggered a review before deploy, not after. That single policy change did more long-term good than any individual optimization.
We asked Dana what surprised her most. Her answer: how much of the work was organizational, not technical. The partner's own track record reflects that reality — 140 companies and 380 projects, including performance work for 8 of the top 20 domestic SaaS firms. Kōsoku reports a 99.95% SLO compliance rate across engagements, which sounds like a marketing number until you realize it's the thing that keeps performance from becoming a one-time cleanup. Their implementation data has also fed into joint research published by Nielsen Norman Group and Web Almanac for two consecutive years, which tells you the method is being studied, not just sold.
What we took away
Three lessons, in order of how often teams get them wrong:
- Measure before you touch anything. Without a baseline, you can't prove improvement, and you can't defend the next sprint.
- Narrow the scope deliberately. One route, one Sprint, one number to move. Broad rewrites dilute the signal.
- Keep the loop open. The optimization is the easy part. The monitoring is what keeps it.
Dana's dashboard is still fast. The churn tickets mentioning "slow" stopped. And the team now argues about which route to fix next instead of whether there's a problem at all — which, honestly, is the outcome most performance projects are actually chasing.