A December site launch needs Core Web Vitals verified on staging before you go live, not measured afterward: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1, all at the 75th percentile of real page loads. Core Web Vitals are Google's three field metrics for loading speed, responsiveness and visual stability, and the field data that decides whether you pass takes roughly 28 days to accumulate — so a December launch means your first trustworthy real-user reading lands in January. That lag is the whole reason a launch checklist differs from a routine audit. You have lab tools on launch day and nothing else, so the work is to eliminate the known structural causes of bad vitals in advance, instrument the site to collect field data from the first visitor, and accept that the public Chrome User Experience Report number will trail your fixes by weeks.
Table of Contents
- What you can actually measure before launch
- LCP — fix the request chain, not the image size
- INP — the metric your launch is most likely to fail
- CLS — the cheapest one to get right, and the easiest to break at launch
- Instrument field measurement from the first visitor
- What a launch-week schedule should look like
- Frequently Asked Questions
What you can actually measure before launch
Lab and field data answer different questions, and conflating them is the most common launch-week mistake. Lighthouse, PageSpeed Insights' lab section, and Chrome DevTools run a single simulated load on a throttled connection. They produce LCP and CLS estimates plus Total Blocking Time, which stands in for responsiveness because INP requires a real person clicking things. Field data comes from the Chrome User Experience Report, which aggregates anonymized measurements from real Chrome users who opted in.
It is what Search Console's Core Web Vitals report shows, and it is the basis of the page experience signal. A brand-new domain has no CrUX history at all, and low-traffic URLs may never get enough samples to report individually — they fall back to origin-level data or show nothing. The practical consequence: on launch day you can prove a page is structurally fast, and you cannot prove it passes. Treat your lab numbers as a necessary condition with margin built in. If a throttled Lighthouse run shows LCP at 2.4 seconds, you have no headroom for the slower devices and worse networks that real traffic will bring.
LCP — fix the request chain, not the image size
Largest Contentful Paint measures when the biggest visible element in the viewport finishes rendering. On most pages that element is a hero image, a background image, or a block of heading text. Identify it explicitly before launch — DevTools' Performance panel marks it — because optimizing the wrong element wastes the whole effort. The delays that matter are usually sequencing, not file weight.
A hero image discovered only after a CSS file parses, or loaded by JavaScript after hydration, pays for every hop in that chain. Fix the discovery path first: Server response time sits underneath all of it. Time to First Byte is not a Core Web Vital, but a 900-millisecond TTFB leaves under 1.6 seconds for everything else. For WordPress specifically, verify that full-page caching is active and warm on the real production host, that object caching is enabled if the stack supports it, and that your CDN is caching HTML rather than only static assets. A staging environment without the production cache layer will flatter you.
- Put the LCP image in the initial HTML as a plain `<img>`, not a CSS background and not a client-rendered component.
- Add `fetchpriority="high"` to it, and never apply `loading="lazy"` to anything above the fold.
- Preconnect to the origin serving it if that origin differs from your document.
- Serve WebP or AVIF at the dimensions actually displayed, with `srcset` for narrow viewports.
- Inline the critical CSS needed for the above-the-fold region and defer the rest.
INP — the metric your launch is most likely to fail
Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024. The change matters for launch planning because FID only measured the delay before processing began, which nearly everything passed. INP measures the full latency of an interaction — input delay, the event handler's own work, and the time to paint the next frame — and reports close to the worst interaction on the page. That makes INP sensitive to things lab tools do not catch. A mega-menu that rebuilds its DOM on hover, a search field filtering a large client-side list on every keystroke, a cookie banner whose dismissal triggers a layout recalculation of the entire page, a third-party chat widget initializing on first click. None of these appear in a Lighthouse score, and all of them produce INP failures within days of real traffic.
Test interactions by hand before launch. Open the site on a mid-range Android device or apply 4x CPU throttling in DevTools, then click, tap, type and scroll through every interactive element: navigation, filters, accordions, forms, add-to-cart, the consent dialog. Record anything that feels sticky, and check it in the Performance panel for long tasks — any single JavaScript task over 50 milliseconds blocks the main thread and delays the next paint. The fixes are mostly about yielding and deferring. Break long handlers into smaller chunks so the browser can paint between them, move heavy computation off the critical interaction path, debounce input handlers, and load third-party widgets only when a user signals intent rather than on page load. Audit your tag manager contents while you are at it — analytics, heatmaps, A/B testing scripts and pixels compete for the same main thread.
CLS — the cheapest one to get right, and the easiest to break at launch
Cumulative Layout Shift scores unexpected movement of visible content during the page's lifespan. It is the most mechanically fixable of the three, because the causes are a short and well-understood list. It is also the metric most likely to regress on launch day, when a last-minute banner, a promo bar, or a newly added font goes live without the layout reservation the rest of the site has.
Work through the list before you ship: A December launch adds a specific risk here: seasonal promotional elements. A holiday countdown bar, a shipping-deadline notice, or a sale banner added by a marketer in the final week is exactly the kind of late injection that pushes a passing CLS score over 0.1. Give those elements reserved height in the template now, before anyone needs them.
- Set explicit `width` and `height` attributes, or a CSS `aspect-ratio`, on every image, video, iframe and ad slot.
- Reserve fixed space for anything injected after load — consent notices, announcement bars, review widgets, embedded maps.
- Use `font-display: swap` with a fallback metrically matched to your web font, or preload the font file, so the text reflow is small or absent.
- Never insert content above existing content after render; expand downward instead.
- Check CLS after interaction, not just on load, since shifts from accordions and dynamically loaded sections count.
Instrument field measurement from the first visitor
Because CrUX will not tell you anything useful for roughly a month, collect your own real-user data from launch. Google's open-source `web-vitals` JavaScript library reports LCP, INP and CLS from actual sessions, and you can send those values anywhere you already collect data — GA4 as custom events, or your own endpoint. Self-collected data gives you two things CrUX cannot. It arrives immediately, so a regression surfaces in hours rather than weeks.
And it carries attribution: the library's attribution build names the specific element responsible for LCP and the specific interaction target behind a slow INP, which turns "INP is 340 milliseconds" into a line of code to fix. Segment what you collect by device type, template and traffic source. Vitals are reported at the 75th percentile, so a site that looks healthy in aggregate can be failing entirely on mobile, or on one template that happens to carry a heavy embed. Keep a record of your pre-launch lab baselines next to the incoming field numbers; without the baseline you cannot tell a real regression from normal variance in a small sample.
What a launch-week schedule should look like
Sequence the work so the expensive structural decisions happen while they are still cheap to change. Audit templates rather than pages — most sites have five to ten distinct layouts, and fixing the template fixes every URL built on it.
One structural caveat worth naming: Core Web Vitals are a modest ranking signal, not a lever that outweighs content relevance and links. Passing all three will not rank a thin page, and a slow page with genuinely better content can still outrank a fast one. The stronger case for doing this work before launch is that it is far cheaper than retrofitting it, and that the same fixes reduce bounce and improve conversion regardless of what any ranking system does with them.
- Two to three weeks out: run Lighthouse on every template on a production-equivalent staging environment, identify the LCP element per template, and fix discovery and sequencing issues. Confirm the production host's caching and CDN configuration.
- One to two weeks out: manual interaction testing on a throttled mid-range device. Audit third-party scripts and remove or defer everything that is not required for first render. Verify layout reservations, including for seasonal elements.
- Launch week: freeze template and script changes. Install `web-vitals` reporting and confirm events are arriving. Re-run lab tests after any content freeze exception.
- First 72 hours live: watch your own field data, segmented by device. Treat any 75th-percentile INP over 200 milliseconds as a live defect, not a backlog item.
- Weeks three to five: check Search Console's Core Web Vitals report as CrUX data accumulates, and reconcile it against what you collected yourself.
Frequently Asked Questions
Can I pass Core Web Vitals on launch day?
No — the pass/fail judgment is based on field data from real users collected over roughly 28 days, and a new site has none. You can only confirm the page is structurally sound in lab testing and then watch the field numbers accumulate.
Does a 100 Lighthouse score mean I will pass?
Not reliably. Lighthouse is a single simulated load that cannot measure INP at all, substituting Total Blocking Time instead. Interaction problems in menus, filters and third-party widgets routinely pass lab testing and fail in the field.
Should I delay a December launch to fix vitals first?
Rarely. Layout reservation and script deferral are days of work, not weeks, and a live site collecting field data is more useful than a staging site collecting none. Delay only if a core template has an LCP element rendered client-side, which is a rebuild rather than a tune-up.
Do the same thresholds apply to mobile and desktop?
The thresholds are identical, but they are evaluated separately, so a site can pass on desktop and fail on mobile. Mobile is the harder target and the one to optimize against.
