The Latency Budget: How Long Agents Wait Before Moving On

A shopping agent comparing prices across five stores does not have all day. It has a budget: a fixed amount of time to complete the task before the user gets impatient or the orchestration system kills the process. Every second your site takes to load is a second the agent cannot spend on extracting data.

How Time Budgets Work

Agent orchestration systems typically allocate a total time budget for a task. A comparison shopping task might get 60 seconds. That budget gets divided across all the sites the agent needs to visit. Five sites means roughly 12 seconds each, minus overhead for processing and decision-making. The actual time available for loading and parsing each site might be closer to 5-8 seconds.

If a site does not return useful content within its allocation, the agent moves on. It does not wait. It does not retry. It marks the site as unresponsive and continues with the data it has from other sources. Your products never make it into the comparison.

This behaviour is rational. From the user's perspective, a result that takes 10 seconds and covers four stores is better than a result that takes 60 seconds and covers five. The agent optimises for the user's experience, and slow sites are the easiest thing to cut.

What Counts as "Fast Enough"

The answer depends on what the agent needs to do. There are really two timelines that matter:

Time to first useful data. This is the time from initial page request to the moment the agent can start extracting information. For a page with server-side rendered HTML and structured data in the head, this is essentially the Time to First Byte (TTFB) plus HTML parsing time. For a client-side rendered page that loads a JavaScript bundle, executes it, fetches data from an API, and then renders the content, this could be several seconds.

Time to complete interaction. For tasks that require multiple steps (searching, filtering, clicking through to a detail page), total interaction time matters. Each step involves loading a page, processing it, making a decision, and executing an action. A site that loads in 500ms per page but requires five page loads is slower overall than one that loads in 1 second but shows everything on a single page.

For most agent use cases, TTFB matters more than total page load time. Agents do not need your fonts to finish loading. They do not care about hero image animations. They need the HTML content and structured data, and they need it fast.

The Performance Waterfall

Here is how a typical agent interaction breaks down in terms of time:

1. DNS lookup and connection: 50-200ms (usually cached after first visit)
2. TTFB: 200ms-3s (varies enormously by site)
3. HTML download and parse: 50-200ms
4. JavaScript execution (if needed): 0-5s
5. Dynamic content loading: 0-3s
6. Agent processing and decision-making: 500ms-2s
7. Action execution: 100-500ms

Steps 2-5 are where most sites lose agents. A server-rendered page with good infrastructure hits steps 2-3 in under 400ms and skips steps 4-5 entirely. A heavy single-page application might spend 3 seconds on TTFB, another 2 on JavaScript execution, and another 2 waiting for API calls, putting the total well past most agents' patience threshold.

Performance budgets are not just a developer best practice anymore. They directly affect whether agents will include your site in their results.

What Agents Do When You Are Slow

Agents do not just skip slow sites once. Many agent systems maintain a performance profile for sites they have visited. If your site consistently takes 8 seconds to return useful data, the agent system may deprioritise you in future tasks, allocating even less time or skipping you entirely.

This creates a negative feedback loop. Slow sites get fewer agent visits, which means less agent-driven traffic, which means less incentive to optimise, which means the site stays slow. The sites that lose the most are the ones that do not realise they are being skipped.

Practical Speed Improvements

The highest-impact changes for agent latency are:

Server-side rendering. Send the content in the initial HTML response. Do not make agents wait for JavaScript to render your product listings. This single change can cut time-to-useful-data from 5 seconds to 500 milliseconds.

Structured data in the HTML head. JSON-LD structured data loads with the initial page response. An agent can extract pricing, availability, and product details before the page even finishes rendering visually.

Fast TTFB. Use a CDN. Cache aggressively. If your server takes 2 seconds to generate a response, every agent that visits is waiting those 2 seconds before anything else can happen.

Avoid unnecessary redirects. Each redirect adds a full round-trip. Two redirects before the final page can add 500ms or more, which is significant when the total budget is 5 seconds.

Minimise blocking JavaScript. Large JavaScript bundles that block rendering are the most common cause of slow time-to-content. Lazy loading content below the fold is fine, but make sure the critical information loads immediately.

Speed has always mattered for user experience and SEO. Agent traffic adds another reason to care, and agents are less forgiving than humans. A human might wait 4 seconds for a page. An agent will not.