First rule: measure where real users are, not where a robot visits
Core Web Vitals are a field metric, the scores that affect rankings and real experience come from actual Chrome users, aggregated at the 75th percentile, segmented mobile and desktop (Search Console's Core Web Vitals report and PageSpeed Insights both surface it). A lab tool can flag a lab-only problem, but fixing lab scores while field scores stay red is the classic speed-rescue failure. Step one is always: open Search Console, find which URLs and which of the three metrics fail on real devices. The current thresholds, per Google's documentation: LCP ≤2.5 seconds (main content painted), INP ≤200 milliseconds (responsiveness, INP replaced FID as a Core Web Vital in March 2024, so any old "first input delay" advice is stale), and CLS ≤0.1 (layout stability). The service framing lives at website performance; this is the triage order.
Triage 1, LCP: the loading story
LCP answers "when did the main thing appear." Causes in frequency order: slow server response (Time to First Byte, hosting tier, missing caching, distant servers), render-blocking CSS and JS above the fold, oversized hero images, late-loading fonts. Rescue order: fix TTFB first (caching, better hosting, it caps everything else), preload the LCP image and serve it sized for the viewport, defer everything that is not the hero. On WordPress the usual culprits are a page builder stacking six render-blocking stylesheets and a slider plugin loading three megabytes for a hero nobody watches. Discipline: change one thing, re-measure, lab numbers for direction, field numbers for truth.
Triage 2, INP: the interactivity story
INP answers "does the page respond when touched", and since it replaced FID it scores the worst-ish interaction across the whole visit, so every tap counts. Causes: long JavaScript tasks (chat widgets, analytics stacks, jQuery-heavy themes), heavy event handlers, frameworks re-rendering too much. The rescue: attribute the slow interactions (field data + DevTools), split long tasks, defer non-critical third-party scripts until after first interaction, and delete scripts whose only job is vanity. On stores, the cart-drawer scripts are the usual offender, and when the slowness is admin-side instead, that is the slow-store triage.
Triage 3, CLS: the stability story
CLS answers "did the page jump while I was reading." Causes: images and embeds without reserved dimensions (the classic: ads and late iframes pushing content down), web fonts swapping late, injected banners. The rescue is boring and permanent: width and height on every media element, font-display with fallback metrics, space reserved for anything that arrives late. CLS fixes are the cheapest of the three, an afternoon for most sites.
What a rescue engagement looks like
Measure field → fix in triage order → re-measure field → repeat until the 75th percentile passes on mobile and desktop. Most sites need the hosting/cache layer (LCP), a third-party diet (INP) and media hygiene (CLS), in that order, because LCP caps everything. No fix ships without a before/after number: the Core Web Vitals page covers the standing discipline, the maintenance retainer stops the re-creep, and the failing URLs from Search Console are the brief.