Context
A production B2B SaaS product at Ranium Systems, built on Vue and Nuxt, serving business users on a mix of office networks and mobile connections. I led the performance workstream.
Problem & baseline
Largest Contentful Paint on key routes was 4.2s — well outside the 2.5s threshold Google treats as "good", and slow enough that users felt it.
The usual suspects were all present: full-resolution images shipped to every viewport, no edge caching in front of the origin, and every route's JavaScript loaded up front.
Options & trade-offs
Performance work is mostly choosing what not to do. The candidate levers: an image CDN service versus a build-time conversion pipeline, SSR and caching changes at the edge versus origin tuning, and route-level code splitting versus a broader bundle rewrite.
Interventions
- WebP image pipeline — images converted at build time with fallbacks, sized per viewport instead of shipping originals.
- CloudFront edge caching — static assets and cacheable responses served from edge locations instead of the origin.
- Route-level lazy loading — each route loads its own chunk; heavy below-the-fold components load on intersection.
- Lighthouse CI budgets — performance budgets asserted on every pull request (see Enforcement).
Enforcement
One-off optimizations decay. The part of this program designed to outlive me is the Lighthouse CI budget: pull requests that push LCP or bundle size past the agreed thresholds fail before review.
Results
LCP on the targeted routes went from 4.2s to 2.5s — a 40% improvement — and the CI budget keeps it from regressing quietly.
What I'd do differently
Write-up in progress.