Performance work has a discovery problem: the tooling reports dozens of metrics, most advice is generic, and teams optimise whatever the audit flagged rather than what users experience. The three Core Web Vitals each have a small number of dominant causes, and knowing which one applies to your site is most of the work.
01Field data over lab data, always
A synthetic audit runs on a simulated device with a simulated network in a controlled environment. Your users are on real devices, real networks, with browser extensions, cold caches and thermal throttling. The two frequently disagree, and when they do, field data is correct by definition - it is what users experienced.
Collect real user monitoring from your own traffic. Lab tools are for diagnosis once you know something is wrong; they are unreliable for deciding whether something is wrong. Segment field data by device class and connection, because an aggregate number hides that low-end mobile users are having a materially worse experience.
- Instrument real user monitoring; treat lab scores as diagnostic only.
- Segment by device tier, country and connection type.
- Track p75 - the threshold the metrics are actually assessed at.
- Alert on regressions per route, not site-wide averages.
02LCP is almost always one of four things
Largest Contentful Paint measures when the main content becomes visible. In practice the cause is nearly always slow server response, a render-blocking resource, a late-discovered image, or client-side rendering that delays content until JavaScript executes.
The most common single fix is the hero image. If it is discovered only after JavaScript runs, or lazy-loaded, or served in an unnecessarily large format, LCP suffers directly. Preload it, set fetchpriority high, never lazy-load the element that is the LCP candidate, and serve modern formats at appropriate dimensions.
| Cause | Diagnosis | Fix |
|---|---|---|
| Slow server response | High TTFB in field data | Caching, CDN, faster origin |
| Render-blocking CSS/JS | Long gap before first paint | Inline critical CSS, defer the rest |
| Late image discovery | Image request starts late | Preload, fetchpriority=high |
| Client-side rendering | Content appears after JS | Server render the above-fold content |
| Web font blocking | Text invisible then appears | font-display: swap, preload |
03INP is a main-thread problem
Interaction to Next Paint measures responsiveness across the whole session, not just load, and it is dominated by long tasks blocking the main thread. When a user taps and the browser is busy executing JavaScript, nothing can respond until that work completes.
The fixes are about breaking work up rather than doing less of it. Split long tasks so the browser can respond between chunks. Move genuinely heavy computation to a web worker. Defer non-urgent state updates so they do not block the visual response to input. And be suspicious of third-party scripts, which frequently contribute long tasks that never appear in your own profiling.
04CLS is dimensions and injection
Cumulative Layout Shift is the most mechanically fixable of the three. Content moving after it renders comes from a small set of causes: images and video without reserved dimensions, ads or embeds injected into flow, fonts swapping with different metrics, and content appearing above existing content after load.
Reserve space for everything that loads asynchronously. Set width and height attributes on media so the browser allocates space before the resource arrives. Give ad slots fixed containers. Match fallback font metrics to the web font so the swap does not reflow. Insert dynamic content below the fold or in space already reserved for it.
05Prevent regressions structurally
Performance work that is not defended decays. A team spends a quarter improving load time, and six months later a marketing tag, a new dependency and an un-preloaded hero image have undone it. The fix is structural rather than motivational.
Set performance budgets in CI that fail the build when bundle size or measured metrics cross a threshold. Review third-party scripts as deliberately as dependencies, because they execute with full privileges on your critical path. And attribute the metric per route so a regression points at the change that caused it rather than a site-wide average that nobody can act on.
Topics
Priya Iyer
Staff Engineer · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.