Developers building AI features that interact with web pages quickly run into a scaling wall. What works beautifully on a local development setup or a simple testing page often completely falls apart when deployed to a real, modern production website.
The issue is not the logic of the LLM; it is the sheer volume of markup generated by modern web frameworks. Every extra token of markup translates directly into higher API costs and slower response times, spent on rendering structures the model simply does not need to see.
The Illusion of Demo Pages
When testing an AI concierge or browser agent, it is tempting to use a clean, hand-crafted demo page. Our own demo page, for instance, costs 6,202 tokens when represented as simplified DOM. At this size, an LLM processes the page instantly, understands the layout, and responds without delay.
However, real production websites do not look like demo pages. When we tested a real production storefront, the token count exploded to 335,106 tokens-which is 54 times more than our demo page. This massive discrepancy is why decisions and architectures validated on clean demo pages often fail in production environments. The model becomes bogged down in thousands of nested layout divs, styling classes, and tracking scripts.
Why Basic Compression Fails
If the raw DOM is too large, the standard response is to clean it up. We tested several common pruning techniques on that same production storefront to see how much they actually help:
- Removing attributes: Stripping out
class,id, anddata-*attributes cut the storefront down to 47,216 tokens. While this represents an 86% reduction, it is still far too large for a fast, interactive user experience. - Using existing libraries: We evaluated an existing DOM-compression library, D2Snap, on the same page. It was unable to compress the page below 43,508 tokens.
Traditional compression utilities try to answer the question: “How do we make this page’s markup smaller?” But for an AI concierge, that is the wrong question to ask. The real question is: “Why are we sending the page’s markup at all?”
The Alternative: Elements, Not Markup
To build an AI concierge that answers questions and shows visitors where to click, the LLM does not need to know your CSS grid structure, your flexbox alignments, or your tracking pixels. It only needs to know two things:
- The visible text content of the page.
- Which interactive elements (buttons, inputs, links) are available to interact with.
By extracting only the rendered visible text and pairing it with an indexed list of interactive elements (which we cap at 200 elements per page), we represent the exact same production storefront using only 2,866 tokens.
Compared to the original 335,106 tokens, this represents a 99.1% reduction in context size.
Keeping the Mapping in the Browser
How does the model point a visitor at the right element if it cannot see the raw DOM nodes? The key is keeping the index-to-element mapping entirely inside the browser runtime.
Instead of sending deep DOM paths or complex selectors to the LLM, the browser engine assigns simple, arbitrary index numbers to interactive elements. The LLM receives a clean list that looks like this:
[2] BUTTON "Solutions"
[3] A "Pricing"
If the user asks where to find pricing, the LLM only has to return a simple instruction pointing to element [3]. The browser-side script receives this lightweight instruction, matches the index 3 back to the actual DOM node in memory, and highlights the element - the visitor performs the click themselves; the assistant does not click on their behalf.
This protocol keeps your data transmission minimal, your latency low, and your API usage highly efficient. You can read the full technical specification of this approach in our research analysis: Guiding, Not Clicking: A Browser–LLM Guidance Protocol.
The Takeaway for Builders
If you are building browser agents, AI search features, or an AI concierge, do not evaluate your prompt windows, token budgets, or model latencies using clean templates or local portfolios.
Measure your tools against real, messy, production-grade customer websites. When you design your data pipeline to strip away the markup entirely and rely on browser-side index mapping, you bypass the token bloat inherent in modern web development.