Every browser agent faces the same expensive problem: parsing HTML into structured navigation decisions. Web Speed introduces a global sitemap registry that lets one user’s parsing work become infrastructure for everyone else’s agents. The MCP-native tool parses HTML into structured sitemaps, caches them server-side, and serves them to subsequent visitors.
The architecture splits into two deployment modes. The OSS version runs locally without cache access. The post-auth version handles authenticated sessions. Both versions control your browser through MCP, but only the paid API tier gets cache reads.
How the Shared Cache Works
When an agent visits a site for the first time, Web Speed parses the HTML into a sitemap and uploads it to a central registry. The next agent that visits the same domain pulls the cached sitemap instead of re-parsing. This cuts the token cost of HTML analysis and eliminates screenshot processing entirely.
The cache hit logic depends on URL matching. If the domain and path structure match a cached entry, the agent gets the pre-parsed sitemap. If not, it triggers a fresh parse and a new cache write.
Cache decision flow:
- Agent requests navigation for
example.com/products - Server checks registry for matching domain + path pattern
- Cache hit: return stored sitemap, skip HTML fetch
- Cache miss: fetch HTML, parse, store, return sitemap
The global registry introduces a shared-state pattern that differs from typical per-session agent memory. Instead of each agent building its own mental model of a site, they all benefit from a collective map. This works well for static sites and poorly for dynamic content that changes per user or session.
Show HN Reception
The Show HN post received 4 points and 2 comments. The creator positions the global cache as the project’s differentiating feature: when one user visits a site, their parsed sitemap becomes available to all future users through the paid API tier.
Open Questions from Discussion
The HN discussion raised questions about cache invalidation and site structure changes. If a site updates its navigation between agent visits, the cached sitemap becomes stale. The available documentation does not describe automatic versioning or staleness detection mechanisms.
Commenters also questioned the economics of the free vs. paid split. Free users get local parsing without contributing to or benefiting from the shared cache. Paid users collectively build the registry, creating a network effect that only benefits other paid users. This limits the cache’s growth potential compared to a fully open model.
Security Boundaries and Cache Integrity
The MCP server, browser control layer, and shared cache API form three distinct trust zones. The available source material documents the following boundaries:
| Component | Location | Function |
|---|---|---|
| MCP Server | Local machine | Controls browser through MCP protocol |
| Cache API | Remote registry | Stores and serves parsed sitemaps |
| Browser Layer | User session | Executes navigation commands |
| Sitemap Parser | Local or remote | Converts HTML to structured sitemap |
The shared cache model introduces a trust consideration: any paid user can write sitemaps to the global registry, and any other paid user will consume them. The available documentation does not expose validation mechanisms for sitemap integrity. Without documented validation, agents must trust that cached sitemaps accurately reflect site structure.
The post-auth version adds session handling for authenticated navigation. The public repos and API documentation do not detail how session state interacts with the shared cache when logged-in views differ from logged-out structure.
Implementation Shape
The OSS version runs as a standalone MCP server. You point your MCP-compatible AI at the server, and it takes control of your browser to execute navigation commands. The post-auth version adds the ability to navigate behind login walls.
The cache API sits behind a paid tier. Free users get local parsing without cache access. Paid users get cache reads and writes. This creates a network effect where paid users collectively build the registry, but free users cannot contribute or benefit.
The parser converts HTML into a structured sitemap with links, forms, and interactive elements. The agent reads this sitemap instead of analyzing raw HTML or processing screenshots. This cuts the token count for navigation decisions but loses visual context that might matter for complex UIs.
Cost Trade-offs
The shared cache reduces per-agent parsing costs but introduces coordination overhead. Every cache write requires a network round trip to the registry. Every cache read depends on the registry’s availability. If the registry goes down, all agents fall back to local parsing.
The economics favor high-traffic sites. If 100 agents visit example.com in a day, the first agent pays the parsing cost and the next 99 get free cache hits. If only one agent visits, the cache provides no benefit and adds network latency.
The actual cost savings depend on cache hit rate, network latency, and parsing complexity. Sites with stable structure and high agent traffic see the largest benefit. Sites with dynamic content or low traffic see minimal benefit and may incur net overhead from network round trips.
What’s Missing from Public Documentation
The GitHub repos and API documentation do not expose:
- Cache hit/miss ratio per domain
- Staleness detection or versioning strategy
- Validation mechanisms for sitemap integrity
- Network latency benchmarks for cache reads vs. local parsing time
Without these details, you cannot tune the system for your workload or detect when the shared cache is serving stale data.
Technical Verdict
Use Web Speed when:
- Your agents visit high-traffic sites where cache hits are likely
- You control the agent’s navigation and can validate sitemap accuracy
- You need to reduce token costs for HTML analysis
- Your use case tolerates stale navigation data
- You work with static sites that change infrequently
Avoid it when:
- You navigate dynamic sites with per-user content
- You need visual context that sitemaps cannot capture
- You require validation of cache integrity before use
- Your agents visit long-tail sites with low cache hit rates
- You need documented versioning and staleness detection
The shared cache pattern works best for static, high-traffic sites where navigation structure changes infrequently. It breaks down for personalized content, frequently updated sites, and low-traffic domains. The lack of documented versioning, staleness detection, and integrity validation means you need additional validation layers for production use.