How to fix Core Web Vitals on a WordPress site
From a page builder at 70 to native blocks at 95, with no performance plugin.
Why plugins stop working after a point, what actually moves LCP, CLS, and INP, and how an AI agent runs the whole job on a copy of your site.
To fix Core Web Vitals on a WordPress site built with a page builder, stop optimizing around the builder and remove it: rebuild the pages as native Gutenberg blocks so the layout ships as markup and one stylesheet, then make a second pass at the specific metrics (a preloaded LCP image, reserved image dimensions for CLS, and less main-thread JavaScript for INP). Do the work on a disposable copy of the site, measure before and after on the same page, and ship only when the numbers hold.
Watch it happen: 70 to 95 in one run
A legacy Divi and WooCommerce site scoring 70 on mobile, rebuilt as native blocks and measured again on staging at 95. No performance plugin, no caching plugin, one stylesheet.
Why performance plugins stop working after a point
A page builder does not store your layout as markup. It stores it as instructions, then renders those instructions into deeply nested containers and loads its own CSS and JavaScript on every request so the layout holds together. That weight arrives before your content does.
Caching and optimization plugins work on top of that weight. They can defer it, minify it, combine it, and serve it from a cache, and all of that helps. What they cannot do is remove it, because the weight is the theme. That is why so many sites plateau in the seventies and eighties no matter how many plugins get stacked on the problem: every plugin is treating a symptom that the theme keeps reproducing on the next request.
Native Gutenberg blocks change the arithmetic. The layout is markup, styled by theme.json and one stylesheet, with no builder runtime in front of it. Once the render-blocking weight is gone, the three Core Web Vitals move for structural reasons rather than tuning reasons: Largest Contentful Paint gets a shorter critical path, Cumulative Layout Shift stops inheriting the builder’s late-loading styles, and Interaction to Next Paint gets a main thread that is not busy hydrating a layout engine.
The steps, start to finish
The order matters. Measure first, work on a copy, remove the builder, then tune the metrics that are left.
Measure first, and write the number down
Run PageSpeed Insights on the page that matters most, on mobile, and record the score plus which metric is actually failing. Mobile is the harder test and the one Google reports on. Without a baseline on a specific URL you cannot prove the work later, and you will end up arguing about impressions instead of numbers.
Work on a disposable copy, never production
Clone the live site into an isolated dev playground on your own machine. Performance work means ripping out a theme, and that is not something to do on a live store. On a throwaway copy a bad idea costs nothing: delete it and clone again.
Find what is actually blocking the render
Open the PageSpeed report and look past the score at the treemap and the render-blocking list. On a page-builder site the pattern is consistent: several hundred kilobytes of builder CSS and JavaScript loading before any of your content, plus a hero image that is neither sized nor preloaded.
Rebuild the pages as native blocks, pixel for pixel
This is the step that moves the score, and the one plugins cannot do for you. Rebuild each page as native Gutenberg blocks, with the design extracted into theme.json tokens and one stylesheet. Work page by page against the original as reference, so the rebuild is a faithful copy rather than a redesign in disguise.
Make a second pass at the metrics that remain
With the builder gone, the rest is specific and small. Preload the Largest Contentful Paint image and stop lazy-loading it. Give every image explicit width and height so nothing shifts. Serve fonts locally with font-display: swap. Then look at what JavaScript is still running on the main thread, because that is what Interaction to Next Paint is measuring.
Re-measure the same URL, same conditions
Run PageSpeed Insights again on the exact page you baselined, on mobile, and compare like with like. Scores vary between runs, so take a couple of readings. If the improvement is real it will be obvious; if it is noise, the second reading tells you.
Ship it, with the old theme kept as rollback
Push the verified result to staging first, look at it with your own eyes, then deploy. Keep the old theme installed and inactive so reverting is one click. Nothing about this workflow requires you to gamble the live site to find out whether it worked.
The shortcut: let an agent run it with /retheme
Steps 3 through 6 are exactly what Pete Panel’s /retheme workflow automates. Inside a local agentic WordPress environment, Claude inventories the existing theme, extracts the palette, fonts, and section structure, rebuilds them as a Full-Site-Editing theme, then converts every main-menu page one at a time and verifies each render before moving on. A second pass goes after the Core Web Vitals specifically. Production is never touched, and the old theme stays installed as rollback. That is the run in the video above:
/retheme <PETE_SITE_LOCAL_URL>
When the result is approved, /push_page ships it one page at a time, backed up before it overwrites. If you want the full migration mechanics rather than the performance angle, the companion guide covers them: how to migrate a Divi site to a block theme.
Frequently asked questions
Why is my Divi or Elementor site slow on mobile?
Because the builder ships a layout engine to the browser on every request. Your layout is stored as instructions, rendered into deeply nested containers, and held together by the builder’s own CSS and JavaScript, all of which loads before your content. Mobile has less CPU and less bandwidth to absorb that, which is why the mobile score is usually far below the desktop one.
Can a caching or optimization plugin fix Core Web Vitals?
Up to a point. Caching, minification, and deferral genuinely help, and you should use them. What they cannot do is remove weight the theme regenerates on every request. If you have stacked optimization plugins and the mobile score still sits in the seventies, the plugins are not the missing piece; the theme is.
Does rebuilding as native blocks change how my site looks?
It should not. The rebuild is pixel for pixel: the same palette, fonts, spacing, and section structure, expressed as native blocks instead of builder instructions. Each page is verified against the original before the next one starts. If you want a redesign, that is a separate decision made deliberately, not a side effect of the migration.
What score can I expect?
It depends on the site, the hosting, and what else is loading, so treat any number as an example rather than a promise. In the run shown above, a legacy Divi and WooCommerce site went from 70 to 95 on mobile PageSpeed after the rebuild, measured on staging with no performance plugin and no caching plugin installed. Your baseline and your plugin load will decide where you land.
Is my live site at risk while this happens?
No, and that is the point of doing it this way. The rebuild happens on a disposable copy inside a local playground with its own database and files. Production is never touched during the work. You review the result, approve it, and only then does anything ship, one page at a time, backed up before it overwrites.
Do I still need a caching layer in production?
A fast theme and a fast server solve different problems, so yes, you still want caching in production for traffic. The difference is that caching becomes an amplifier rather than a life-support system. Pete Panel’s production stack ships Redis object caching, OPcache, and page caching by default, which is what the benchmarks measure.
Fix your Core Web Vitals the agentic way.
Spin up a free dev playground, measure your baseline, and let Claude do the rebuild on a copy. You approve what ships.