Core Web Vitals QA checklist for redesigned websites

A website redesign can pass visual QA and still damage performance. New hero media, animation, font loading, tracking scripts, form embeds, CMS components, and page-builder sections can make the site feel slower even when the design looks cleaner.

This checklist is for teams launching a redesigned marketing site, B2B website, Shopify storefront, WordPress theme, or headless commerce front end. Use it after staging content is close to final and before the redirect map, analytics plan, and launch date are locked.

Core Web Vitals QA should not start with one homepage Lighthouse score. List the templates that matter to search, paid traffic, and revenue. A redesigned site usually has different performance risks on the homepage, service page, collection page, product page, blog post, case study, contact page, and campaign landing page.

For each template, choose one best-case URL and one heavy real-world URL. The heavy URL should include normal images, embeds, forms, tracking, testimonials, related content, and translated copy where relevant. That is the page customers and search engines will experience after launch.

• Include at least 5 to 10 URLs across key templates before launch approval.
• Test mobile and desktop separately because Google evaluates field data by device class.
• Mark each URL as must-pass, monitor-only, or intentionally excluded from this launch.

Before the new site replaces the old one, record a baseline. Pull PageSpeed Insights, Search Console Core Web Vitals, Chrome UX Report data if available, and a lab run for priority templates. The goal is not to make lab and field data match. The goal is to know whether the redesign improved or worsened the experience after traffic moves.

Record the current page URL, planned destination URL, device, test date, LCP, INP or a lab proxy such as Total Blocking Time, CLS, page weight, request count, and any obvious bottleneck. Store the baseline beside the redirect map so launch decisions can connect SEO risk with performance risk.

• Use the 75th percentile when reading field data, because that is how Core Web Vitals pass/fail evaluation is normally framed.
• Keep one screenshot of the lab waterfall for every must-pass template.
• Document when data is unavailable for low-traffic pages instead of guessing.

Largest Contentful Paint measures loading performance. The current good target is LCP within 2.5 seconds of the page starting to load. On redesigned websites, LCP often regresses because the hero image, video poster, heading block, font, or first CMS image becomes larger than expected.

Open each priority URL and identify the LCP element. Then ask whether that element is necessary, optimized, and loaded with the right priority. A beautiful hero that is too heavy can make every other optimization look weaker, especially on mobile and international traffic.

• Compress and size the LCP image for its rendered breakpoint, not the largest design export.
• Avoid lazy-loading the LCP image or placing it behind late JavaScript when it is visible above the fold.
• Check font loading because a delayed webfont can hold back the visible heading.
• Watch server response and cache behavior for CMS-driven pages, not only front-end bundle size.

Interaction to Next Paint measures responsiveness. The current good target is INP at 200 milliseconds or faster in field data. A lab test without user input cannot fully measure INP, so staging QA needs real interactions plus lab proxies like Total Blocking Time.

Use the site the way customers will use it. Open menus, filters, accordions, language selectors, cart drawers, search overlays, lead forms, pricing toggles, comparison tables, and cookie banners. The redesign is not ready if the first interaction after page load feels delayed because scripts are still blocking the main thread.

• Test interactions immediately after page load and again after the page has settled.
• Prioritize components that appear on every page, such as navigation, chat, consent, analytics, and forms.
• Remove or delay scripts that are not needed for the first user action.
• Check third-party widgets separately so the team knows which owner can fix each delay.

Cumulative Layout Shift measures visual stability. The current good target is CLS at 0.1 or lower. Redesigns often fail here because new images lack dimensions, cookie banners push content, fonts swap late, sticky headers resize, or injected app blocks appear after the main layout is already visible.

Do not test only the default desktop viewport. Resize through mobile, tablet, and desktop states. Load the page with and without consent banners, announcement bars, chat widgets, embedded forms, logged-in states, and translated content. Layout shift is often conditional.

• Reserve dimensions for images, videos, iframes, embeds, and product media.
• Avoid inserting banners above content after initial render unless space is reserved.
• Check long translated headings and button labels for wrapping that changes nearby layout.
• Test slower network conditions because delayed assets can expose shifts hidden on fast Wi-Fi.

Performance bugs become harder to fix once content entry, analytics, and stakeholder review are all happening at the same time. Before launch freeze, inventory the assets that run across the site: analytics, pixels, heatmaps, chat, scheduling widgets, form embeds, review widgets, personalization, A/B testing, fonts, image formats, video embeds, and CMS plugins.

For each item, decide whether it must load on every page, only on specific templates, only after consent, or only after interaction. This is also the moment to remove legacy scripts from the old site. A redesign should not carry over tracking and embeds nobody owns.

• Map every third-party script to an owner, page scope, business purpose, and load condition.
• Subset fonts and avoid loading weights that do not appear in the final design system.
• Replace decorative video with a static poster where motion does not help the page goal.
• Confirm image components produce responsive sizes for CMS editors, not just hand-picked assets.

Not every URL needs the same launch decision. A must-pass template that drives organic revenue deserves a stricter gate than a low-traffic legal page. Define what blocks launch, what must be fixed before handoff, and what can be monitored after release.

A practical gate is simple: no must-pass template should show a clear regression against the baseline, visible mobile issues should be fixed before launch, and every known monitor-only issue should have an owner and follow-up date. This keeps performance QA connected to launch management instead of becoming a separate report nobody acts on.

• Block launch for broken layout, severe mobile LCP regression, unstable headers, or unusable forms.
• Fix before handoff when a shared component hurts multiple templates.
• Monitor after launch when field data is missing or the issue depends on real traffic volume.