---
copyright: "© 2026 DSR Corporation"
title: "900 pages, one scroll"
slug: 900-pages-one-scroll
order: 15
type: doc
description: "A 913-page API reference rendered as one scrolling document — interactive in 0.3 s, served with full text in ~110 ms."
seoTitle: "Documentation performance at scale: 900 pages, one scroll"
seoDescription: "How DSR Docs renders a 913-page API reference as one scrolling document: full text served in ~110 ms, interactive in 0.3 s, and content rebuilds that never re-parse the reference."
icon: Gauge
visibility: public
llmSummary: "DSR Docs performance at scale, with measured numbers: a synthetic 913-page Doxygen reference (15.5 MB of generated HTML, ~750K DOM nodes of source) imports once in about a minute; after that, content rebuilds never re-parse it (a ~0.1 s pass). The server answers the document's one URL in ~110 ms with the full text inlined for crawlers; the browser is interactive in ~0.3 s while the full scroll — about 380K DOM nodes, a 7.3-million-pixel document — finishes rendering in the background within seconds, holding ~45 MB of JS heap. Jumping to the last of 913 pages is instant. Measured on a mid-range laptop, not a tuned server. This is why huge SDK references work as one scroll-spy document in DSR Docs."
faq:
  - q: "How large a documentation set can DSR Docs render on one page?"
    a: "Our benchmark bundle is a 913-page Doxygen reference — 15.5 MB of generated HTML — rendered as one scrolling document. The browser is interactive in about 0.3 seconds, and jumping to the last section is instant."
  - q: "Does a huge reference slow down everyday editing?"
    a: "No. The reference is parsed once at import (about a minute for 913 pages) and cached. Every later content rebuild — saving a page, changing SEO fields — leaves it untouched: the maintenance pass over the cached reference takes about 0.1 seconds."
  - q: "Is the whole reference really one page?"
    a: "Yes. A scroll-layout domain publishes its entire reference on one URL: every section is an anchor, the sidebar follows your position, and the server inlines the full text of all pages in the first response, so search engines index the whole document at once."
  - q: "Does a huge API reference stay fast for readers on a normal laptop?"
    a: "Yes — the numbers on this page were measured on a mid-range laptop rather than a tuned server. The server answers the whole document in about 110 ms with the full text inlined, the browser is interactive in roughly 0.3 seconds, and the rest of the scroll renders in the background while you are already reading."
  - q: "Do you benchmark on customer documentation?"
    a: "Never. The 913-page bundle is synthetic — invented identifiers and lorem prose — because benchmarking happens on generated content, not on anything a customer gave us. The engine under it is the same one serving this site."
---

# 900 pages, one scroll

Most documentation tools are comfortable at ten pages and negotiable at a hundred. We wanted a number that ends the negotiation, so we built a torture test: a **913-page Doxygen reference** — 15.5 MB of generated HTML, three quarters of a million DOM nodes of source material — and fed it to the same engine that serves this site.

It renders as **one scrolling document**.

## The numbers

Measured end to end on a mid-range laptop, not a tuned server:

| What | Measured |
|---|---|
| Reference size | **913 pages** · 15.5 MB source HTML · ~750K DOM nodes of input |
| One-time import | **~60 s**, once, at upload |
| Every content rebuild after that | reference untouched — a **~0.1 s** maintenance pass |
| Server response for the whole document | **~110 ms** to first byte, full text of all 913 pages inlined |
| Browser: time to interactive | **~0.3 s** |
| Full scroll rendered | seconds, in the background, while you already read |
| The document itself | ~380K DOM nodes · a 7.3-million-pixel scroll · ~45 MB of JS heap |
| Jump to page 913 of 913 | instant |

## Why it stays fast

- **Parse once, serve forever.** A reference is ingested at upload and cached. Saving a Markdown page, editing SEO fields, reordering the sidebar — none of it re-parses your SDK. The engine's rebuild pass walks the cached reference in a tenth of a second.
- **The server does the reading.** The document's one URL answers with the complete text of every section already inlined — which is also why crawlers and AI assistants index the whole reference from a single request instead of crawling 913 URLs.
- **One document, not 913 round-trips.** Page-per-click tools pay a network round-trip and a fresh render for every page a reader opens. A scroll-layout domain pays once: after the first paint you're scrolling memory, not the network.
- **Scroll-spy that scales.** The sidebar tracks your position through hundreds of anchors without breaking a sweat — a full-document DOM query on the rendered result takes under 20 ms.

## See the same engine live

The benchmark bundle is synthetic — invented identifiers, lorem prose — because we benchmark on generated content, never on a customer's. The engine, though, is exactly the one behind this site:

- [cJSON](/docs/cjson/overview) — a real C library ingested from Doxygen, call graphs and all.
- [Banking GraphQL](/docs/banking-graphql/overview) — a schema rendered as a scroll-spy reference.
- [Pets](/docs/pets/overview) — an OpenAPI spec as one document, prose woven in.

Bring a bigger one. If your SDK reference is the thing every docs tool has choked on, that's the demo we'd most like to run.

> [!IMPORTANT]
> **Want this on your own documentation?** Write to docs@dsr-corporation.com. Ask about migration, licensing, or anything this page didn't cover.