Fixing Slow Rendering That Makes AI Agents Give Up

What "ready" means to an agent

A person looking at a page makes allowances. They see a spinner and wait, see a button and try it, notice the layout jump and click again. An agent is less forgiving. Browser-driving agents typically wait for the page to settle, take a screenshot, read the accessibility tree, decide on an action and carry it out. Each of those points can go wrong on a page that is still busy:

• Too little to read. If the first screenshot shows a loader or an empty frame, the agent has to decide whether to wait or leave. Different agents make that choice differently, and none of them publish a fixed time limit you can design to.
• Controls that look ready but are not. A button drawn by server-rendered HTML may do nothing until the page's JavaScript has loaded and attached its handlers. The agent clicks, nothing happens, and it concludes the button is broken.
• A moving target. The agent works out where to click from a screenshot. If a banner, image or widget arrives between that screenshot and the click, the target has moved and the click lands on something else.
• A page that never settles. Chat widgets, analytics beacons, live polling and animated carousels keep the page busy indefinitely, so an agent waiting for things to go quiet waits in vain.

Agents that fetch HTML without running scripts have a simpler problem: whatever is not in the first response does not exist. That side, including server response time and caching, is covered in slow pages for AI crawlers. This guide concentrates on what happens in the browser after the HTML arrives.

Measuring the gap

You need to see the page change over time, not just a single score. Three tools do this well.

The Performance panel in Chrome or Edge

Open developer tools, choose Performance, set CPU throttling to a slower setting and network to a fast mobile connection, and record a page load. The screenshot strip across the top shows what the page looked like at each moment. The main thread track shows long tasks, marked with a red corner, which are periods when the browser cannot respond to a click. Layout shifts are marked in their own track.

WebPageTest

Run a test from a location near your audience and look at the filmstrip view. It shows the page frame by frame, which makes a spinner that lasts three seconds, or a hero image that pushes everything down at the four second mark, easy to see and easy to show to whoever built the site.

PageSpeed Insights field data

The field data at the top of PageSpeed Insights comes from real Chrome users. The two figures that matter most here are Interaction to Next Paint, which reflects how quickly the page responds to clicks and should be 200 milliseconds or less at the 75th percentile, and Cumulative Layout Shift, which should be 0.1 or less. Poor figures for real people almost always mean a poor experience for agents too.

Dead clicks and the hydration gap

Many modern sites render HTML on the server, then load JavaScript that "hydrates" the page by attaching behaviour to it. Between the two, the page looks complete but its buttons do nothing. On a fast laptop the gap is short. On a busy cloud browser with limited CPU, which is where many agents run, it can be long enough for the agent to click, see no result and give up on that control.

There are two ways to close the gap: make it shorter, and make controls work without waiting for it.

Make controls work without scripts

A form with a real action and a submit button works the moment the HTML arrives. A link with a real href works the moment it is drawn. Script can then improve the experience, for example by submitting in the background, but the basic action does not depend on it.

<!-- Dead until the script loads -->
<button type="button" class="js-add-to-basket" data-sku="KT-204">Add to basket</button>

<!-- Works immediately; script can enhance it later -->
<form action="/basket/add" method="post">
  <input type="hidden" name="sku" value="KT-204">
  <label for="qty">Quantity</label>
  <input id="qty" name="qty" type="number" value="1" min="1">
  <button type="submit">Add to basket</button>
</form>

Frameworks increasingly support this directly. Remix and React Router form handling, Next.js server actions used with forms, SvelteKit form actions and Nuxt server routes can all accept a normal form post before client code has loaded.

Make the gap shorter

• Ship less JavaScript to the pages agents use most: product, service, booking and contact pages.
• Hydrate only the parts that need it. Island approaches, as used by Astro and similar tools, leave most of the page as plain HTML and only load script for interactive pieces.
• Load the script for the main action first, and push reviews, recommendations and chat further back.

Loaders and snippets that hide the page

Anti-flicker snippets

Many A/B testing and personalisation tools ask you to add a small snippet to the head that hides the whole page, usually by setting its opacity to zero, until the experiment script has loaded and made its changes. The idea is to stop visitors seeing the original version flash before the variant. The effect for an agent is a blank page for as long as the testing script takes, up to whatever timeout the snippet sets.

If you still run experiments, ask whether the snippet is needed at all. Server-side testing, where the variant is chosen before the HTML is sent, avoids it entirely. If you must keep it, shorten the timeout, limit it to the pages actually in a test, and remove it from pages with no running experiment. Check the head of your page source for any leftover snippet from a tool you no longer use; they often outlive the tool.

Full-page loaders and splash screens

Some themes add a loading overlay that covers the page until every image and script has loaded, sometimes with an animation. It serves no purpose for the visitor and hides a page that is often usable well before the overlay lifts. Remove it.

Spinners in place of content

A spinner where the price, stock level or opening hours should be means that information is fetched by script after load. If the fetch is slow, or blocked for an automated visitor, the agent sees a spinner indefinitely. Put that information in the server-rendered HTML and refresh it with script afterwards if it changes often. The JavaScript-only content guide covers the details.

The fix, step by step

Third-party scripts and layout shifts in practice

On most small business sites, the site's own code is not the main problem. Third-party scripts are. Each one is small on its own, and together they fill the main thread during the first seconds of the visit, exactly when an agent is trying to act.

A reusable CSS rule for reserving space for a late widget:

.reviews-summary {
  min-height: 3.5rem;   /* the height the widget takes once loaded */
}
.hero img {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

Platform notes

• WordPress. Page builders and themes often add a preloader and several sliders; remove the preloader and replace sliders with a single static image. Cache plugins that delay all JavaScript until interaction can leave buttons dead on first load; exclude the scripts your key actions depend on. The WordPress guide covers this.
• Shopify. The theme usually renders well; slowdowns come from app embeds. Turn embeds off one at a time in the theme editor to find the heavy ones, and see the Shopify guide.
• React, Vue and other frameworks. Use the framework's server rendering or static generation for public pages, keep client-only components for genuinely interactive parts, and split code by route so each page loads only what it needs.
• Static sites. Usually fast already. Watch for third-party embeds and web fonts, which are then the main cause of delay and movement.