Performance & caching
Fast first loads, fast repeat visits, and effects that fit the device
Frontend performance comes down to three things: sending less code, caching what was already sent, and not asking a device to do more than it can. We set performance budgets in CI, cache at every layer from the CDN to the browser, and scale visual effects to each device's capability.
Core Web Vitals targets
We build to Google's “good” thresholds at the 75th percentile of real users:
| Metric | Measures | Target |
|---|---|---|
| Largest Contentful Paint (LCP) | How fast the main content appears | 2.5 s or less |
| Interaction to Next Paint (INP) | How fast the page responds to input | 200 ms or less |
| Cumulative Layout Shift (CLS) | How much the layout jumps while loading | 0.1 or less |
Real-user monitoring tracks these after launch, and bundle-size budgets in CI catch regressions before merge.
Caching at every layer
| Layer | What we cache | How it stays fresh |
|---|---|---|
| CDN edge | Static assets, rendered HTML | Content-hashed file names; stale-while-revalidate for HTML |
| HTTP cache | Assets in the user's browser | Long-lived immutable headers for hashed files |
| Service worker | App shell, key routes, images | Versioned caches replaced on deploy |
| In-app data cache | API responses | Per-query staleness rules and targeted invalidation |
| IndexedDB | Data needed offline | Sync with the server when online |
| Server cache | Rendered pages and API results | Revalidation on content change |
Each layer has a defined invalidation rule. Users don't get stuck on stale prices, and the server doesn't rebuild what hasn't changed.
Visual effects that adapt to the device
Translucent glass surfaces (like Apple's Liquid Glass style), heavy blur, shadows and large animations look good on new hardware and stutter on older devices. We build effects in tiers:
- 1
Full
The full effect on capable devices.
- 2
Lighter
A lighter version (less blur, fewer layers) when frame times rise.
- 3
Solid
A solid, static fallback for low-end devices and for users who set prefers-reduced-transparency or prefers-reduced-motion.
The page measures itself and moves between tiers, so everyone gets the best version their device can run smoothly.
Smaller assets
Images are served in AVIF or WebP at the right size for each screen. Fonts are subset to the characters you use. Third-party scripts load after the main content, or not at all until they're needed.
FAQ
Frequently asked questions
01Our Lighthouse score is fine. Why are users still complaining?
Lighthouse runs on a lab device. Real users have slower phones and networks. We look at field data from your actual users to find the gap.
Next step
Start with a review of what you have
Send us your repository or a staging link. We'll come back with the three changes that would make the biggest difference to your release speed, performance and reliability.