The CWV audit gives you a number. 3.2 seconds to Largest Contentful Paint on mobile, 0.18 Cumulative Layout Shift, 320ms Interaction to Next Paint. Google's "good" thresholds are 2.5s, 0.1, and 200ms respectively. Miss them and your page quietly drops in rankings.
The audit does not tell you what to change. That's the gap this tool fills.
The CWV Fix Generator holds twenty concrete code patterns, one per common failure, and lets you either paste the audit output (the tool parses keywords and auto-selects matching patches) or check the boxes manually. What you get back is an HTML block, a CSS block, a JS block, and an AI prompt that ties them to your specific page.
What's in the pattern library
Three metrics, broken into fixes by where the fix lives.
LCP, the hero image is the usual culprit. Seven patterns cover every way an LCP image can be slow. <link rel="preload" as="image" fetchpriority="high"> in the head to discover the image before CSS parses. <picture> with AVIF + WebP + JPEG fallback so the browser picks the smallest format it can render. srcset with sizes so mobile users don't download the desktop-sized asset. Critical CSS inlined in <head> and the rest of the stylesheet loaded async via preload + onload="this.rel='stylesheet'". font-display: swap on every @font-face so text shows up in a fallback while the webfont loads. preconnect hints to third-party origins your LCP resource depends on. And if the image is still JPEG in 2026, the pattern for converting to AVIF with ImageMagick is one line: magick hero.jpg -quality 65 hero.avif, AVIF at 65% quality looks equal to JPEG at 82%.
CLS, the page is shifting under the user. Four patterns. Every <img> and <video> and <iframe> needs width and height attributes, because without them the browser reserves zero pixels until the asset loads and shifts everything down when it arrives. Ad slots and dynamic embeds need CSS aspect-ratio on their container so the space is held before content arrives. Web fonts need a metric-matched fallback via ascent-override and size-adjust so the swap is invisible rather than a reflow. And min-height on user-generated content blocks prevents the shift when comments or reviews stream in after paint.
INP, something on the main thread is slow. Five patterns. defer or async on every non-critical script. Passive listeners ({ passive: true }) on scroll, touchstart, wheel, a single non-passive scroll listener can cause jank across the whole page. Debounce for "on change" handlers that fire 60 times a second, throttle for scroll-position handlers, requestAnimationFrame for visual updates that need to align with paint. scheduler.yield() or requestIdleCallback for long-running tasks that would otherwise block every click for 200ms. And lazy-loading third-party scripts (chat widgets, analytics pixels) until the user interacts with the page, the single highest-use INP fix for most content sites.
TTFB, the server or network is slow. Two patterns that cover most cases. Cache-Control headers that cache things (static assets get max-age=31536000, immutable with hashed filenames; HTML gets stale-while-revalidate so users get an instant response while the browser revalidates in the background). And Brotli or gzip compression on text assets, most CDNs do this by default but self-hosted nginx or Apache needs explicit config.
Why the patches are paired with an AI prompt
A pattern library alone is a good starting point. It's not the answer for any specific page.
Every real page has specifics the patterns can't anticipate: which image is the LCP candidate, which ad slot is the worst CLS offender, which scroll handler is blocking INP, whether the page is even the bottleneck versus the network. A competent LLM handed the patterns plus the page HTML can tell you which ones apply, point at the exact elements that need the fix, estimate the expected metric improvement, and produce a ranked remediation plan.
The prompt the tool emits does this explicitly. It carries the patterns as starting material, but it asks the model to identify specific offending elements, group patches by file, rank by expected impact, and flag anything that needs infrastructure changes (image conversion, nginx config) versus pure code changes. That's the workflow that ships: the model writes the commit, you review the diff, you deploy, you re-measure.
The re-measure step matters
CWV work is easy to fake. You ship a patch, Lighthouse looks greener, and you call it done. Meanwhile real users on mid-tier Android phones on patchy 4G still see the same 3.2-second LCP because you tested on a MacBook on office wifi.
Re-measure with something that reflects real user conditions. The built-in CWV audit at /tools/cwv-audit/ is fast for a sanity check. PageSpeed Insights at pagespeed.web.dev runs a real Lighthouse on a 4x-throttled CPU and reports both lab and field data (field data comes from the Chrome User Experience Report and is what affects rankings). Chrome DevTools Performance tab with CPU throttling set to 4x and network throttling set to Fast 3G or Slow 3G will tell you what happens on the phones most of your users are carrying.
The workflow the tool's roadmap recommends: ship patches for the biggest-impact metric first, wait 28 days for the field data to update, then re-measure. If CrUX field data shifts into the green, the fix worked. If only lab data moved and field data didn't, you optimized the wrong thing.
Where this fits with the other tools
The CWV Audit finds the problems. This generator emits the fixes. The Mega Analyzer surfaces them in context with everything else. The Security Headers tool now emits the Cache-Control headers that matter for TTFB, in the syntax your host expects, Netlify, Cloudflare Pages, Cloudflare Workers, Vercel, nginx, Apache, Caddy, AWS CloudFront, DigitalOcean App Platform. And the Mobile Parity audit catches the mobile-only regressions that desktop testing misses.
Four tools, one loop: audit, fix, ship, re-measure.
Related reading
- Auditing Core Web Vitals, A Client-Side Approach Without the PSI Quota
- Mobile-First Indexing Is Indifferent to Desktop
- Hosting & Indexing Health Checks: Fix GSC Errors Fast
If you're running a content site that lives or dies on Google rankings, the $97 Launch walks through the stack-level CWV decisions: The $97 Launch.
Fact-check notes and sources
- Core Web Vitals "good" thresholds (LCP ≤ 2.5s, CLS ≤ 0.1, INP ≤ 200ms): web.dev, Core Web Vitals (accessed 2026-04-20)
- INP replaced FID as a Core Web Vital in March 2024: web.dev, Introducing INP
fetchpriorityattribute browser support: caniuse.com/mdn-html_elements_img_fetchpriorityscheduler.yield()API: developer.mozilla.org, Scheduler.yield()content-visibility: autorendering benefits: web.dev, content-visibility- Chrome User Experience Report (CrUX) as the source for field CWV data: developer.chrome.com/docs/crux
