Core Web Vitals rescue for AI-built WordPress sites

#Core Web Vitals rescue for AI-built WordPress sites: the post-build problem

An AI assistant can put a WordPress site online in an afternoon. It cannot tell you that the fourth “speed” plugin it recommended is fighting the second cache layer it recommended two prompts earlier. Owners usually find out from a PageSpeed Insights screenshot with red numbers, or from a stakeholder asking why a fast-looking site loads like it is 2015. This is a rescue for exactly that failure mode: Core Web Vitals broken specifically because the build was assembled by prompt, not because the business chose a heavy theme on purpose.

This is a narrower service than general speed optimisation. A standard performance audit assumes deliberate, if imperfect, architectural choices made over time. This rescue assumes an assistant that answered ten separate requests with ten separate plugin installs in a single build session, and a page builder that ships every block’s markup, CSS, and JavaScript regardless of what actually renders above the fold.

#Why AI builds destroy Core Web Vitals

Three mechanisms show up on almost every AI-assisted build we open, usually together.

Plugin sprawl. Large language models do not hold a live inventory of what is already installed. Prompt one gets a form plugin. Prompt fifteen gets a second form plugin because the model does not remember prompt one. Each install is individually defensible; the cumulative weight is not. We documented the anonymised numbers behind this pattern in plugin sprawl after an AI build: 38 active plugins is a routine starting point for a three-week AI-assisted build, not an outlier.

Duplicate optimizers. The instinctive fix for a slow page is “install a cache plugin.” When TTFB is still high a week later, the next prompt is “install a faster cache plugin,” often without deactivating the first one. We regularly find two full-page caches, two minifiers, and two image-optimisation plugins running against each other on the same site, sometimes producing intermittent broken JavaScript because two minifiers rewrite the same assets differently.

Render-blocking builder output. Page builders generate generic, reusable markup so any block works in any layout. That genericism means every block ships its own CSS and JS, loaded regardless of viewport position. A hero section built with a drag-and-drop builder plus an addon pack routinely ships more render-blocking CSS than the entire page needs, which is exactly what drags LCP and INP into the red on mobile.

#Proof from practice: 38 plugins to 21, TTFB 1.47s to 0.68s

The clearest evidence is the anonymised case documented in full in plugin sprawl after an AI build. A B2B professional services site, built over roughly three weeks with AI-assisted tooling, arrived with:

Hosting and theme did not change. The win came from removing duplicate SEO, cache, and analytics plugins, merging three form builders into one, and auditing three custom mu-plugins the assistant had generated, of which two were deleted after a security pass. That is the shape of a Core Web Vitals rescue on an AI-built site: mostly uninstalls and merges, not new infrastructure.

#Triage table: symptom, cause, action

Run this before committing to a full engagement. It tells you whether a quick pass is enough or the build needs a staged teardown.

If most rows point to isolated plugin duplication, a focused teardown is usually enough. If custom AI code, plugin sprawl, and broken user flows show up together, scope the fuller rescue rather than patching performance in isolation.

#Staged teardown order

Performance work follows a fixed order so a fix does not get undone by the next batch, and so security issues in custom code do not get exposed by removing the plugins that were quietly working around them.

1. Freeze new installs. No plugin answers until the audit ledger exists.
2. Remove duplicate caching and optimisation plugins first. Two full-page caches fighting each other is the single most common cause of inconsistent PageSpeed results; fix this before touching anything else.
3. Audit custom AI-generated code before deleting commercial plugins around it. If a generated mu-plugin quietly depends on a plugin you are about to remove, deleting the plugin first breaks the site.
4. Merge overlapping tools in batches of five to eight, testing checkout and forms after each batch, measuring TTFB and query count.
5. Fix render-path issues on the templates that carry traffic: defer non-critical JS, add explicit image and font dimensions, reduce builder addon usage on the hero.
6. Remeasure and set a plugin budget so the next AI-assisted change does not reopen the same holes.

#Measurement checklist: LCP, INP, CLS, and TTFB

Track all four together. A PageSpeed score alone hides which specific metric is driving the business impact.

• LCP (Largest Contentful Paint) - target under 2.5s. Measure on the actual hero template, not a lightweight test page.
• INP (Interaction to Next Paint) - target under 200ms. Test on a page with a form or filter, where users actually interact.
• CLS (Cumulative Layout Shift) - target under 0.1. Test with cookie banners and lazy-loaded images present, since those are common CLS sources on AI-built sites.
• TTFB (Time to First Byte) - target under ~800ms uncached on a standard page. Measure with curl or WebPageTest across five runs and use the median, not a single sample.
• Database queries per view - track with Query Monitor; flag anything above roughly 120 on a content page.

Measure on the homepage, the heaviest landing page, and checkout or contact. A site that looks fast on the homepage and slow on checkout is a common AI-build pattern, because the builder-heavy pages are rarely the ones anyone tested last.

#What not to do

• Do not install another optimizer plugin to fix a slow site caused by too many plugins. That is how sites reach 40 plugins in the first place.
• Do not run two full-page caches “to be safe.” Pick one and configure it properly.
• Do not delete custom AI-generated mu-plugins before auditing what they depend on. Some quietly patch a gap another plugin left open.
• Do not chase a synthetic 100 PageSpeed score at the expense of real LCP/INP/CLS on the templates that generate revenue.
• Do not skip measuring checkout and contact pages because “the homepage is fine.” Builder-heavy secondary templates are usually where the worst numbers live.

#How the engagement runs

Step 1 - baseline. We measure LCP, INP, CLS, and uncached TTFB on representative templates, plus a full plugin and database inventory.

Step 2 - audit. Every plugin gets mapped to its actual job; duplicates and render-blocking builder output get flagged.

Step 3 - staged teardown. Batches of five to eight plugins, deactivated, tested, measured, then deleted. No bulk deletes on production.

Step 4 - render-path fixes. Defer non-critical scripts, fix image and font loading, consolidate to one cache layer.

Step 5 - remeasure and lock in a budget. Same templates, same tools, documented before/after, plus a rule that no new plugin ships without retiring or merging an existing one.

#Related services and deep-dives

This rescue sits alongside the broader remediation work we do on generated sites:

Blog deep-dive: Plugin sprawl: when an AI build leaves you 40 plugins deep - the full anonymised case behind the numbers used above.

Pricing is individual and scoped after the baseline audit. Contact us with the site and a short note on how it was built.