How to improve Core Web Vitals and page speed with Claude Code

To improve Core Web Vitals with Claude Code, start with real-user data to find which templates fail which metric, then let Claude diagnose one template in a lab test, make one change at a time on a branch, and re-measure. Claude is good at the investigation and the code: finding render-blocking files, oversized images, layout shifts from images without dimensions, and scripts that tie up the browser. People decide the trade-offs, like whether a chat widget or tracking tag is worth its cost, and confirm in a real browser that nothing broke.

Speed work can break things, because the quickest change is often to remove or delay something the site depends on. This guide gives the steps, example prompts, the checks and what a person reviews, plus what we learned speeding up eseospace.com.

The metrics and what Google says about them

The Web Vitals guide defines the targets: "LCP should occur within 2.5 seconds," "pages should have a INP of 200 milliseconds or less," and pages "should maintain a CLS of 0.1. or less." A page passes "if it meets the recommended targets at the 75th percentile for all three." LCP (Largest Contentful Paint) measures when the main content appears. INP (Interaction to Next Paint), which replaced First Input Delay in March 2024, measures how fast the page responds to taps and clicks. CLS (Cumulative Layout Shift) measures how much the layout jumps around.

Google's page experience FAQ keeps this in proportion: Core Web Vitals are used in ranking, but good results "doesn't guarantee that your pages will rank at the top of Google Search results," and "trying to get a perfect score just for SEO reasons may not be the best use of your time." The better reason to do this work is visitors, especially on phones.

Step 1: Find what's failing in the field

Start with real-user data, grouped by template. Search Console's Core Web Vitals report shows how your pages perform, and the field section of PageSpeed Insights draws on the Chrome User Experience Report, Google's dataset of real Chrome users. PageSpeed Insights notes that a page "might not have sufficient data" if it's new or low-traffic, so look at groups of similar pages, not just one URL.

Write down, per template, which metric fails on mobile and desktop. A blog template failing LCP and a product template failing INP are two different projects.

The check: you have a short table of template, metric, device and current value. If everything passes in the field, stop. There may be nothing worth the risk.

Step 2: Get a repeatable lab baseline

Field data tells you what's slow; lab data tells you why. Lighthouse, Google's open-source auditing tool, runs "in Chrome DevTools, from the command line, or as a Node module," and PageSpeed Insights uses it for its lab section. Lab and field numbers sometimes disagree, as the PageSpeed Insights docs explain; use the lab only to compare before and after on the same setup.

Example prompt: Install the Lighthouse CLI and write a script that runs a mobile performance audit three times each on these five staging URLs, one per template, and saves the median LCP, CLS, Total Blocking Time and the LCP element for each. Save the results as baseline.json. Don't change any site files.

Total Blocking Time is a lab metric for how long long-running tasks block the browser after the first content appears. web.dev calls it "a reasonable proxy metric for INP for the lab but it's not a substitute for INP," which is best measured in the field.

The check: the three runs per URL are close to each other. If they swing widely, fix the test setup before trusting any comparison.

Step 3: Have Claude diagnose one template

Pick the worst template with the most traffic and ask Claude to explain the cause before proposing anything. Start in plan mode (/plan).

Example prompt: Using the Lighthouse report for the blog template, explain what delays LCP and what causes layout shift. Identify the LCP element, every render-blocking stylesheet and script, images without width and height, and the scripts with the most main-thread time. Propose fixes in order of expected impact and risk. Don't edit files.

Ask it to tie each finding to web.dev's breakdowns. LCP has four parts: "Time to First Byte (TTFB)," "Resource load delay," "Resource load duration" and "Element render delay." The most common CLS causes are "Images without dimensions," ads, embeds and iframes without dimensions, injected content and web fonts. INP delays come from long tasks, often script evaluation during load.

Step 4: Fix one thing at a time

Common fixes Claude can make, and what to watch with each:

Example prompt: On a new branch, add width and height attributes to every content image in the blog template using each image's real dimensions, and reserve space for the embedded video. Change nothing else. Then re-run the baseline script for the blog URL and compare.

One change per branch makes the cause of any regression obvious, and makes the diff short enough for a person to read.

Step 5: Prove nothing broke, in a real browser

A faster page that doesn't work isn't an improvement. After each change, check the pages in a real browser: menus open, accordions expand, sliders move, forms submit, the consent banner appears, and analytics events still fire. Claude Code's Chrome integration can drive a visible Chrome window, read console errors and inspect the page; see Claude Code and Chrome. A person should still click through the key journeys.

When we rebuilt eseospace.com, the first attempt was a clean rebuild that stripped the theme's JavaScript. It broke animations, accordions, widgets and menus, and a person decided on day one to keep the theme's own JavaScript. Later, combining many stylesheets exposed a theme file with an unclosed brace that swallowed header styles site-wide. Neither is the kind of break a performance score reports. Add these checks to your QA routine before every deploy.

Step 6: Re-measure in the lab, then wait for the field

Re-run the baseline script and compare medians.

A person approves the deploy. Field data then takes time to reflect the change, because it covers a trailing 28-day window. Check Search Console and PageSpeed Insights again after a few weeks, and judge the change on field data, not on one lab run.

What we did on eseospace.com

These figures are from eseospace.com's own site, not client work. In our own lab test with PageSpeed Insights (desktop, specific pages, not field data), the score went from 56 to 86 and Total Blocking Time fell from about 1,200 ms to near zero, mainly by delaying theme scripts until first interaction. CSS requests on a typical page dropped from 75 to 4. People chose fidelity over clean code and approved every deploy; Claude Code wrote and applied the changes. The full story is in the guide to rebuilding a website with Claude Code.

What a person must review

• Which templates and metrics are worth fixing, based on field data and traffic.
• Any change that removes or delays a third-party script, with whoever owns it.
• Real-browser checks of key journeys after every change.
• The diff and the before-and-after numbers, before deploy.

Speed sits alongside the other site-wide jobs in Claude Code for technical SEO. On WordPress, our PageSpeed playbook for WordPress covers platform-specific fixes.

Conclusion

Claude Code is useful for speed work because it can read a Lighthouse report, trace each problem to a file and make a targeted change. The discipline that makes it safe is the same every time: start from field data, keep a repeatable lab baseline, change one thing per branch, prove the page still works in a real browser, and judge the result on field data weeks later. If you'd like the work done for you, see our site speed optimization service. More guides are in our Claude Code Guide.

Frequently asked questions