When I started this experiment, the core question was simple:
Because content inside
<template>is inert, can I page HTML into templates and add/remove it from the DOM to improve performance while still making it available for bots and content scrapers?
The answer is yes, but with important caveats.
The Four Approaches
I built four tests around the same dataset of 100,000 items and compared how they behave when rendering a very large list of rich rows.
Each demo represents a different tradeoff between startup cost, live DOM size, implementation complexity, content visibility, and crawler/scraper behavior.
1. No Virtualization
Demo: No Virtualization
This is the baseline worst case: all rows are shipped in the initial HTML and remain live in the DOM.
Pros
- Simplest implementation
- All content is immediately available in the document
- Best fit for raw HTML inspection, non-JS scraping, and source-based AI analysis
- Most reliable for SEO and indexing
Cons
- Worst startup cost
- Largest live DOM
- Highest memory pressure
- Worst scrolling/layout/style recalculation behavior
- Scales poorly as rows become richer
Takeaway
This is the best option for maximum content visibility, but the worst for browser performance at large scale.
2. Paged Templates
Demo: Paged Templates
This version ships all rows in the initial HTML, but stores most of them inside <template> elements so they stay inert until mounted.
Pros
- Reduces live DOM pressure
- Keeps markup HTML-first
- Lets you page content into the DOM only when needed
- In our simple AI parsing test, it exposed content as well as normal HTML
Cons
- Large initial HTML still has to be downloaded and parsed
- Inert content is not free: it still contributes to document size
- Startup cost remains high if the whole dataset ships up front
- SEO behavior is still less predictable than normal rendered HTML because
<template>content is inert and not normally rendered page content.
Takeaway
Template virtualization is viable, but it improves runtime DOM cost more than startup cost. In this test, AI parsing behaved much better than expected because the static source still contained the inert template content.
3. JS Virtualization
Demo: JS Virtualization
This version keeps the data in JavaScript and reuses a small pool of row nodes while scrolling.
Pros
- Best startup behavior in the tests
- Small initial HTML document
- Low live DOM size
- Efficient scrolling because a fixed pool of nodes is recycled
- Usually the strongest choice for app-style UI performance
Cons
- Requires more client-side logic
- Content is not fully present in the initial HTML
- Weakest option for non-JS scraping and source-based analysis
- Less reliable for SEO unless paired with SSR, prerendering, or crawlable paginated routes
Takeaway
If the goal is browser UI performance, this is usually the strongest default. If the goal is content discoverability, it is usually the weakest.
4. Lazy Paged Templates
Demo: Lazy Paged Templates
This version keeps the template model, but creates template pages after the initial page loads instead of shipping them all up front.
Pros
- Keeps the benefits of template-backed paging
- Avoids the worst startup cost of a giant template-filled HTML document
- Improves responsiveness by spreading work over time
- Better template-based compromise than shipping every template up front
Cons
- More complex than static templates
- Still eventually creates lots of inert markup if you keep building pages
- Still JS-driven
- SEO/scraping visibility is weaker than static HTML because much of the content appears after initial load
Takeaway
This is the most interesting template-based approach I tested. It keeps the inert template idea while avoiding the biggest flaw of the static template version, but it is still less reliable than plain HTML for indexing and scraping.
Performance vs SEO vs scraping vs AI analysis
Here is the practical ranking from this experiment:
| Approach | Browser performance | SEO / indexing | Basic scraping | Source-based AI analysis |
|---|---|---|---|---|
| No Virtualization | Worst | Best | Best | Best |
| Paged Templates | Better than full live DOM, but still heavy at startup | Mixed-to-good | Good | Good |
| JS Virtualization | Best | Weakest | Weakest | Weakest |
| Lazy Paged Templates | Better startup than static templates | Mixed-to-weak | Weak | Weak |
What this means
- If your priority is browser performance, JS Virtualization usually wins.
- If your priority is SEO, indexing, content scraping, or AI systems that inspect raw page source, No Virtualization is the strongest choice.
- If you want some HTML-first benefits while reducing active DOM size, Paged Templates can be surprisingly effective for AI parsing and basic scraping because the static response still contains the template content.
- If you want the template model without paying the full startup cost immediately, Lazy Paged Templates are a better direction than shipping every template up front.
AI parsing
I ran a simple AI discoverability test against each example.
I asked the AI (claude code and copilot) how many times it could find the name "Avery Adams" on the page. The correct answer is 391.
| Example | Correctly counted names |
|---|---|
| No Virtualization | ✅ |
| Paged Templates | ✅ |
| JS Virtualization | ❌ |
| Lazy Paged Templates | ❌ |
This result was notable because AI systems often use tools like curl to inspect a page's static response. In this case, the AI did not appear to ignore content inside <template> tags. That made Paged Templates much more discoverable to source-based AI analysis than a pure JS-rendered approach.
The lazy template version did not fare as well, because much of its content is created after the initial response rather than being present in the original HTML source.
What this suggests
- No Virtualization remains the clearest and most reliable option for AI parsing.
- Paged Templates may be more AI-discoverable than many people expect, as long as the template content is present in the static HTML.
- JS Virtualization is a poor fit when you want AI systems to understand the full content from the initial page source.
- Lazy Paged Templates improve startup performance, but that same laziness reduces what source-based tools can see.
Conclusion
Template virtualization could be a viable approach to improve performance and still make content available for static analysis, but it may not be the best tool for it.
- No Virtualization: best for visibility, worst for scale
- Paged Templates: better runtime DOM behavior, still expensive upfront, but stronger for AI parsing than expected
- JS Virtualization: best overall UI performance
- Lazy Paged Templates: best template-based startup compromise, but weaker for source-visible discovery
Top comments (0)