Going into a holiday traffic peak, an agency's Core Web Vitals work should narrow to three measurable targets per template: Largest Contentful Paint (LCP) under 2.5 seconds, Interaction to Next Paint (INP) under 200 milliseconds, and Cumulative Layout Shift (CLS) under 0.1, all measured at the 75th percentile of real visits. Everything else on a pre-holiday checklist is either a way of hitting those numbers or a way of proving you hit them.
Core Web Vitals are Google's three field metrics for loading speed, responsiveness, and visual stability. The holiday risk is not that a site is slow in a lab test — it is that the templates carrying the most revenue degrade under concurrency, third-party script load, and promotional markup that nobody tested. This checklist is ordered for that situation: freeze what you can, measure the field, fix the small number of causes that dominate, and leave yourself a rollback.
Table of Contents
- Set the scope before you set the sprint
- Measure the field, not the lab
- The LCP checklist for a traffic peak
- INP and CLS — the two that promotional markup breaks
- What to do when the peak is already here
- Reporting the work so the client can see it
- Frequently Asked Questions
Set the scope before you set the sprint
Pick templates, not pages. Most sites reduce to five or six: home, category or listing, product or article, search results, cart or lead form, and checkout. Core Web Vitals are assessed per URL, with Chrome's Chrome User Experience Report (CrUX) grouping low-traffic URLs into origin-level data, so one fixed page on a broken template buys almost nothing. Rank those templates by the revenue or conversion that passes through them, then by current field performance.
A category page at LCP 4.1s that receives a third of sessions outranks a blog template at 2.8s. Agencies working on retainer should get this ranking agreed in writing with the client before the freeze, because mid-December is the worst time to argue about priority. Then write down the freeze. Decide which date new plugins, new tag manager containers, new A/B tests, and theme updates stop shipping, and who can grant an exception. A measured improvement in November is routinely erased by a marketing tag added in December, and without a freeze nobody can tell which change caused the regression.
Measure the field, not the lab
Lighthouse and PageSpeed Insights run a simulated load on one device profile. That is a lab test, and it is useful for diagnosis — it names the render-blocking resource or the unsized image. It does not tell you whether you pass, because assessment uses field data from real Chrome users over a 28-day rolling window. Use both, for different jobs.
PageSpeed Insights shows CrUX field data for the URL or origin alongside the lab run; Search Console's Core Web Vitals report groups URLs into good, needs improvement, and poor buckets by template-like URL patterns, which is the fastest way to find a bad template. For INP in particular, field data is close to mandatory — INP measures the latency of real interactions, and a lab load with no clicks in it cannot observe one. Two measurement traps worth naming. First, the 28-day window means a fix deployed on December 10 will not be fully reflected in CrUX until January; if you need faster feedback, collect your own field metrics with the `web-vitals` JavaScript library and attribution build, which reports the specific element and script behind each metric. Second, your own browsing is not representative: your cache is warm, your connection is good, and you do not click the newsletter modal.
The LCP checklist for a traffic peak
LCP is the render time of the largest element in the viewport — usually a hero image, a banner, or a large text block. Under holiday load, the causes that dominate are a slow server response, a discovery delay on the hero image, and render-blocking resources in the head.
Work through these in order: On WordPress and Drupal specifically, audit the page caching layer and the optimization plugin together. Two plugins both minifying and deferring the same assets is a frequent source of inconsistent LCP and broken layouts, and the symptom often appears only for logged-out traffic.
- Measure Time to First Byte under realistic concurrency, not at 3am. If TTFB alone is over roughly 800ms, no front-end work will save the metric — fix caching first.
- Confirm full-page caching is on and that promotional query strings (`?utm_source=`, `?promo=`) are not bypassing the cache. This single misconfiguration is a common cause of a site that is fast in testing and slow on Black Friday.
- Preload the LCP image with `fetchpriority="high"`, and never lazy-load it. `loading="lazy"` on a hero image is a self-inflicted LCP delay and is easy to introduce when a theme lazy-loads everything by default.
- Serve the hero as WebP or AVIF at the dimensions it actually renders, with explicit `width` and `height`.
- Move non-critical CSS and all non-essential JavaScript out of the blocking path, using `defer` or `async`.
INP and CLS — the two that promotional markup breaks
INP replaced First Input Delay as a Core Web Vital in March 2024, and it is stricter in a way that matters commercially: it measures the full latency from interaction to the next painted frame, across all interactions in a visit, reporting roughly the worst one. Long tasks on the main thread are the usual cause, and holiday sites accumulate them — chat widgets, countdown timers, personalization scripts, affiliate trackers, consent managers. For INP, the practical moves are to cut main-thread work and to break up what remains.
Audit third-party scripts and remove or delay anything not tied to revenue; load tag manager containers with the smallest viable tag set; and for your own code, yield to the main thread inside long handlers rather than doing all the work before the next paint. Test the interactions that matter — add to cart, filter a category, open the mobile menu, submit a form — on a mid-range Android device, not a current flagship. CLS is layout shift after initial paint, and promotional markup causes most of it. Sale banners, free-shipping bars, cookie notices, and ad slots injected above existing content shift everything below them.
- Reserve space for every injected element: fixed-height containers for banners, `min-height` on ad slots, CSS `aspect-ratio` on media.
- Give all images and video explicit dimensions, including ones inside promotional blocks.
- Use `font-display: swap` with a size-adjusted fallback so the web font swap does not reflow text.
- Insert announcement bars as overlays or in pre-reserved space rather than prepending them to the DOM at runtime.
- Re-test CLS after every promotional change, because the shift arrives with the banner and not with the code that was reviewed.
What to do when the peak is already here
If the freeze is in effect and traffic has started, change management matters more than optimization. Keep a short list of reversible levers you can pull per template, and know in advance who approves pulling them. The reliable emergency levers are: disable or delay a specific third-party script; turn off a running A/B test; remove a promotional banner that is shifting layout; raise cache TTLs; and switch an optimization plugin's aggressive setting back to its default.
Each of these is a one-line change with a known rollback, which is the property you want under pressure. What not to do mid-peak is deploy a theme update, change the caching architecture, or refactor a template's JavaScript. The downside is an outage during the highest-revenue week of the year, and the upside is a metric that will not appear in CrUX until the peak is over. Log the regressions you cannot safely fix and schedule them for January, when a 28-day measurement window is an acceptable feedback loop again.
Reporting the work so the client can see it
Report per template, per metric, at the 75th percentile, with the date of each deployment marked. A single sitewide score hides the case that matters — one revenue template regressing while the average improves — and it gives the client no way to connect a change to an outcome. Be explicit about the limits of what you are showing.
Core Web Vitals are one part of Google's page experience signals and do not by themselves determine ranking; passing all three thresholds is a user-experience and conversion argument first. Tie the numbers to behaviour the client already tracks — bounce, add-to-cart rate, form completion on mobile — rather than promising a ranking movement the metric does not guarantee. Finish the engagement with a written record of what was deferred during the freeze: the scripts you delayed, the exceptions that were granted, and the regressions logged for January. That document is what prevents next year's pre-holiday audit from starting from zero.
Frequently Asked Questions
How long before the holidays should the Core Web Vitals work start?
Early enough that CrUX's 28-day rolling window can reflect the fixes before the peak, which in practice means finishing deployments four to six weeks ahead.
Does a passing PageSpeed Insights score mean the page passes Core Web Vitals?
No. The Lighthouse performance score is a lab result on a single simulated device; assessment uses field data from real Chrome users at the 75th percentile.
Which Core Web Vital is most often broken by holiday promotions?
CLS, because sale banners, shipping bars, and ad slots are injected above existing content without reserved space, shifting everything below them.
Can INP be tested without real traffic?
Only partly. You can find long tasks and slow handlers in a lab by manually interacting with the page on a throttled mid-range device, but the reported INP value itself requires real interactions in the field.
