AI in performance optimisation: great assistant, bad source of truth

"AI fixed our LCP."

Increasingly common claim, increasingly worth interrogating. AI is genuinely useful in web performance work, both Google and Microsoft have shipped first-party AI assistance into the tools developers use to do this job. It is also one of the easiest places to over-trust an AI suggestion and quietly make the site worse.

This article is the practitioner-level read on where AI earns its place in performance optimisation, where it cannot go, and what an AI-led performance audit gets wrong.

The short version#

AI is a strong assistant in performance work. It accelerates trace summarisation, code-fix drafting, hotspot identification, and pattern-spotting across templates. It is a poor source of truth on which user cohort matters, which template carries the revenue, and whether a fix actually improved things in the field.

Two pieces of evidence anchor the framing. Chrome DevTools now exposes Gemini-based AI assistance (opens in new tab) explicitly for performance investigation, Google has taken the position that AI belongs in the performance toolchain. At the same time, the 2025 paper in Empirical Software Engineering on AI-generated code performance (opens in new tab) reports that AI-generated code is often functionally correct but introduces performance regressions (inefficient calls, redundant looping, language-feature misuse) that benchmark tests do not catch.

Both can be true. AI accelerates the diagnosis and first-pass fix. The measurement and the trade-off calls still belong to humans with field data and business context.

If you only do three things#

1. Use AI to summarise traces and draft fixes; never use AI summaries as the basis for a priority list.
2. Anchor every claim of improvement in field data, CrUX, Search Console, or RUM, over a meaningful window.
3. After every AI-suggested fix, re-measure. AI is good at proposing changes. It is not good at predicting whether they actually helped your users.

Where AI is genuinely useful in performance work#

The performance work AI accelerates is the work an experienced engineer would do anyway, given enough hours. Five places it earns its place:

Trace summarisation#

Performance traces are dense. A 30-second DevTools recording can contain thousands of events across the network, main thread, paint, and compositor timelines. Reading a trace from cold takes time even for engineers who do it often.

Gemini in Chrome DevTools' Performance panel (opens in new tab) compresses that initial read. "Help me optimise my LCP score" is, by Google's own framing, a reasonable question to ask of the trace it is looking at. The AI's answer is a hypothesis, not a verdict — but it is a faster hypothesis than reading the trace from the top.

A small example of how this plays out in practice: on a recent audit, the AI summary of a Lighthouse trace pointed confidently at the hero image as the LCP problem, recommending compression and a smaller srcset. The actual culprit, visible once the engineer read the trace properly, was server response time — TTFB was running at 1.8 seconds before the image was even requested. Compressing the image would have shaved off a fraction of the smallest sub-part. The fix was a server-side caching change, ten times the impact for a fraction of the work. AI's read of the trace was fluent. It was also wrong about which sub-part mattered.

The same is true of WebPageTest waterfalls and Lighthouse traces. AI is good at the "where do I start looking" question. It is much weaker at the "what should I do about it" question, and weaker still at "is this the most important thing to fix."

Hotspot identification across the codebase#

A performance issue that shows up on one template often exists on five. Finding the others by hand involves grepping for patterns, opening files, and reading components. AI is fast at this kind of structural pattern-matching — "every page that renders a hero image with this layout pattern" — and the result is a list an engineer can review and act on.

GitHub's documentation describes Copilot as useful for identifying hotspots and suggesting performance-oriented refactors (opens in new tab) — better data structures, fewer redundant computations, caching opportunities. That framing is realistic: AI proposes; the engineer validates against the actual cost in a trace.

First-pass fixes#

The fixes that occur most often in performance work are largely formulaic: explicit image dimensions to prevent CLS, font-display settings, deferred third-party scripts, removed render-blocking resources, preload hints for the LCP image. None of these are intellectually interesting; all of them take time to apply across a codebase.

AI is faster at applying these patterns, and the engineer's time is freed up to focus on the trade-off calls — which third party can be removed entirely, which template needs a structural change, which user cohort to defend first.

Code drafting for known patterns#

If the diagnosis is "long task in this event handler, split it into smaller chunks using scheduler.yield," AI can draft the change. If the diagnosis is "the LCP image is being lazy-loaded because the framework defaults to it, add fetchpriority='high' and loading='eager'," AI can apply that across the templates.

The pattern is the same one across all four points above: the answer is largely already known. AI compresses the time between knowing the answer and shipping it.

Explaining a regression to stakeholders#

This one matters more than it sounds. Stakeholders rarely want a trace; they want a sentence. AI is good at translating "the LCP regression is driven by a 1.4-second increase in image load delay introduced when the homepage was migrated to a new CMS template" into something a marketing director can act on without losing the technical truth. That translation is real value, especially in agency settings where the audit's job is to drive a decision

Where AI cannot go: measurement and prioritisation#

The asymmetry is sharp. AI is good at the work after the data is in. It is poor at deciding which data to trust, which user cohort matters, and what counts as success.

Field data still rules#

Lab data is reproducible and useful for diagnosis. It is not what Google ranks on, and it is not what affects revenue. The 2025 Web Almanac performance chapter (opens in new tab) and web.dev's lab-vs-field guidance (opens in new tab) both make the same point: lab and field data measure different things, and using only one will mislead you.

The most consistent failure mode in AI-led performance work is treating a Lighthouse trace as the truth. HTTP Archive analysis (opens in new tab) found that 43% of pages with a Lighthouse score of 90+ still failed at least one Core Web Vitals threshold in the field. Philip Walton, the engineer behind Google's Web Vitals library, puts it bluntly (opens in new tab): a perfect Lighthouse score is "a very good sign" but does not guarantee real-world performance.

AI does not change this. If anything, AI makes it easier to mistake a confident-sounding lab-only summary for a diagnosis. The discipline that protects against it is procedural: every claim of improvement is anchored in field data — CrUX (opens in new tab), Search Console (opens in new tab), or RUM — over a meaningful window. AI summarises; the field data verifies.

Cohort selection is a business decision#

Which users to defend first is not a technical question. The site's mobile users in a particular market may be the most performance-sensitive cohort; or it may be desktop users on the checkout flow; or it may be the third-party-script-heavy product listing template that drives organic traffic. The right answer depends on revenue distribution, user research, and business strategy.

AI does not know any of this. It can read a trace, but it cannot read your analytics, your conversion funnels, or the meeting where the marketing director explained which campaign matters most this quarter.

"Functionally correct, slightly slower"#

The 2025 ESE paper on AI-generated code performance is the technical version of this point. AI-generated code can be:

• correct on its own terms,
• pass the test suite,
• and still introduce a measurable performance regression — through inefficient function calls, redundant looping, or use of language features that benchmark poorly.

The same "passes tests but" pattern shows up across review, accessibility, and maintainability. The implication for performance work is direct. AI-suggested fixes need to be measured against the previous performance, not just shipped because they look right. A fix that solves the diagnosed problem but introduces a new one is a worse outcome than no fix. The discipline of "measure, change, measure again" is unchanged by AI; it is more important, not less, because the rate of changes goes up.

Trade-off calls#

Performance work is full of trade-offs that have no technical answer. Should the consent banner block tags until consent, or load them async with deferred firing? Should the live chat widget be facade-loaded with a delay or removed entirely? Should the experimentation script be moved server-side, even though that is a six-month project? Each of those depends on the business, the team, and the stakeholders — not on the trace.

What an AI-led performance audit gets wrong#

A few patterns that show up most often when AI is treated as the audit rather than the assistant:

• Lab-only "evidence" with confident phrasing. AI is fluent. A summary that reads as if it is grounded in field data may be entirely lab-derived. A real audit names its data source — "this analysis is based on CrUX 28-day data for the product listing template, mobile cohort" — every time it makes a claim. AI does not know to do that unless it is prompted to.
• Generic recommendations dressed up as bespoke. The classic Lighthouse output — "compress images, remove unused JavaScript, defer offscreen content" — applied to a particular site, with the AI smoothly inserting the site's name, reads like a tailored audit. It is not. As the 2024 Web Almanac (opens in new tab) reported, 16% of mobile pages still lazy-load their LCP image — a Lighthouse-suggested fix applied to the wrong asset. Generic, AI-polished recommendations make this kind of misapplication more confident, not less.
• Single-run measurement. A Lighthouse run has documented variability (opens in new tab). One run is a data point; an audit needs medians across multiple runs and, more importantly, field data over weeks. AI summarising one Lighthouse run as if it were a diagnosis is an audit that mistakes noise for signal.
• No template scoping. Performance characteristics differ wildly across templates — homepage, product listing, product detail, search, checkout. An AI summary of the homepage is not an audit of the site.
• No re-measurement after fixes. AI proposes a change; the change ships; nobody verifies whether the field metrics moved. Given AI-generated code's known tendency to introduce subtle performance regressions while passing tests, this is the most dangerous failure mode. The fix list is not done at "fix shipped." It is done at "fix verified in the field."
• No third-party separation. The biggest performance contributors on most sites are scripts the agency did not write. An AI summary that recommends "optimise the JavaScript bundle" without distinguishing first-party from third-party cost is asking the engineer to fix a problem they cannot control. The breakdown matters; AI has to be prompted to do it.

XIII Studios point of view#

AI sits inside our performance work — DevTools' Gemini assistance, Copilot in the editor, AI-driven trace summaries when we are reading a long recording. It accelerates diagnosis and drafts the routine fixes. The order of operations, however, is fixed and does not change:

1. Field data first. Search Console, CrUX, or RUM. The audit is scoped to the templates and cohorts that matter to the business, not to whichever URL was easiest to test.
2. Lab data for the why. DevTools, WebPageTest, Lighthouse — used to explain the field signal, not replace it. AI is allowed to summarise the trace; the engineer reads the trace to validate the summary.
3. Sub-part attribution. LCP, INP, and CLS broken into their components. The fix list addresses the largest sub-part first, not the most visible one.
4. First-party vs third-party split. The cost is separated explicitly so the right team owns the right action.
5. AI-suggested fixes are reviewed and measured. Every change goes through the same review pipeline as any other code, and field metrics are re-checked over a meaningful window after deployment. CrUX is a 28-day rolling average; we tell stakeholders that upfront so nobody mistakes "no change yet" for "the fix did not work."
6. Trade-off calls stay with the engineers and stakeholders who own the revenue. Which third party stays, which template gets defended first, which user cohort to prioritise — AI surfaces the data; humans decide.

The version of this we tell clients out loud is short: AI shortens the time it takes to be confident in the answer. It does not change the answer.

Closing thought#

AI is the best assistant performance engineers have ever had. It is a poor substitute for the things performance engineers actually do that matter: choose what to measure, decide which users to defend, make the trade-off calls, and verify that the fix actually moved the real-user metrics.

Put another way: use AI to read traces faster, draft fixes faster, and explain findings faster. Keep the measurement, the prioritisation, and the verification with the engineer. Re-measure everything that ships. Performance work is the same work it has always been; AI just shortens the time between question and hypothesis.

If the audit you have been handed feels confident, fluent, and untethered from real users, that is what an AI-led audit looks like when nobody steered it.

From a team that cares about performance, accessibility, and straight answers.

XIII Studios builds high-performance websites and software using AI-assisted workflows — without the usual agency overhead, and without confusing AI summaries for real-user data.

If you have been handed an AI-generated performance report and you are not sure whether it is a diagnosis or a fluent summary, start with a website audit (opens in new tab). We will give you a clear, field-data-anchored read on what is actually wrong, what to fix first, and where AI assistance would genuinely help.

Or book a call with us (opens in new tab) for a straightforward conversation about your site's performance, your priorities, and where the work is worth doing now.

Related reading#

• Core Web Vitals: what actually matters for revenue — the metric-by-metric reading of where speed costs you money.
• Why site speed actually matters for conversions and SEO — the upstream commercial case.

Photo credits#

Hero and section images use Unsplash (opens in new tab) community photography. See Unsplash license (opens in new tab).