An AI coding agent can turn a feature that once looked like two weeks of work into five minutes of generation.
That is still slightly terrifying and brilliant every time it happens.
The danger is that delivery time has collapsed while operational consequences have not. A generated feature can still make six database calls, ship a huge image, block rendering on a third party and return far more data than the page uses.
The code arrived quickly. The performance debt arrived with it.
Performance is an architecture decision first
Teams often wait for Lighthouse or a real user to report a slow page before discussing performance.
By then, the shape of the problem may already be embedded in:
- where data is fetched;
- how many services a request crosses;
- which components require client-side JavaScript;
- whether the database has the right indexes;
- how images and fonts are delivered;
- which third-party scripts run before the page is useful;
- whether the UI waits for everything before showing anything.
You can optimise around those decisions later, but prevention is cheaper.
Make performance part of the build instruction:
“As you design this feature, minimise network and database round trips, keep server-only work off the client, identify the critical rendering path, and explain any dependency or third-party script added to it.”
That does not guarantee a fast application. It makes speed an explicit constraint instead of a surprise audit category.
“It loads quickly for me” is weak evidence
The builder usually tests on a fast laptop, warm cache and reliable connection. The customer may arrive on an older phone, through a social in-app browser, with a weak signal and no cached assets.
That difference is why lab and field metrics matter.
Three useful signals are:
Time to First Byte
TTFB measures how long the browser waits for the first response bytes. A slow value can point towards server work, database queries, cold starts, an overloaded dependency or a distant origin.
It is not automatically a database problem. It is a reason to trace the request rather than polishing the loading animation.
Largest Contentful Paint
LCP measures when the largest important element in the viewport becomes visible. On a landing page, that is often the hero image or main heading area.
A huge image, render-blocking font, slow server response or excessive client-side work can all delay it.
Interaction to Next Paint
INP reflects how responsive the page is when a visitor interacts. A page can look loaded while heavy JavaScript makes the first click feel broken.
The metric is useful because perceived speed is not only about arrival. It is also about whether the interface responds when the user trusts it enough to act.
Ask the agent about round trips
AI-generated backend code often optimises for clarity of each individual step. That can produce several valid queries where one deliberate query would be safer and faster.
Use a review prompt with boundaries:
“Review the data path for this route. Count database and external-service round trips, identify duplicated or sequential work, check whether required indexes exist, and propose changes that preserve authentication, authorisation and output behaviour.”
The final clause matters. A performance fix that bypasses an auth check or changes the data contract is not an improvement.
Do not blindly combine every query either. One enormous query can be harder to cache, reason about and secure. The goal is evidence-backed efficiency, not the smallest possible query count.
Treat every dependency as a performance decision
Coding agents install packages effortlessly. The user pays for them on every page load.
Before accepting a dependency, ask:
- Is it used on the server, client or both?
- Does it enter the initial bundle?
- Is the capability already available in the platform?
- Can it be loaded only where needed?
- Does it introduce its own network calls, styles or fonts?
- What is the maintenance and vulnerability cost?
The same applies to analytics, chat widgets, consent managers and experimentation tools. Each may be justified. Together they can become the product's critical path.
Images remain the easiest avoidable mistake
Large hero images appear constantly in site reviews because they still look fine on the machine that uploaded them.
The repair is usually straightforward:
- use an appropriate modern format;
- resize to the maximum rendered dimensions;
- provide responsive variants;
- reserve width and height to prevent layout movement;
- prioritise only the actual above-the-fold image;
- lazy-load work below the fold.
A polished nine-megabyte image is not a premium experience. It is a delay with art direction.
Put performance into the definition of done
For each public feature, define a small release budget:
- no unexplained increase in client JavaScript;
- no new render-blocking third party without approval;
- responsive images with explicit dimensions;
- database and external calls counted on the critical path;
- mobile interaction tested on the deployed URL;
- material changes compared with the previous release.
The exact numbers depend on the product. The habit does not.
Then run the repo checks and inspect the live site. A local production build can catch code problems, but it cannot reproduce every CDN, header, third-party or device condition affecting the public page.
Speed is part of the promise
Performance is not a technical clean-up phase. It shapes whether the page feels safe, whether the action feels reliable and whether a visitor stays long enough to understand the offer.
AI helps us build faster. The next discipline is making sure it does not quietly help us build slower products.
PageLens AI measures the deployed surface, captures evidence and turns the highest-value performance findings into work an agent can act on.
Run the free Ship Check against the live app, then make performance part of the next prompt rather than the next incident.
— Richard