What optimising for an LLM actually means
A language model consuming your page is not browsing. It issues one HTTP request, receives bytes, converts them to tokens, and spends part of a finite context window on the result. Optimisation is therefore mostly subtraction: sending the same facts in far fewer tokens, with the important ones first.
| Property | Why it decides the outcome | How to check it |
|---|---|---|
| Fetchable | A blocked request cannot be optimised | Request the URL as an agent would |
| Parseable without JS | The fetch runs no JavaScript | Read the raw response, not the DOM |
| Small | Context is finite and shared | Compare bytes with and without negotiation |
| Front-loaded | Truncation and summarisation cut the tail | Find the offset of the first real fact |
What subtraction is worth
On the reference document capture, a services page went from 13,581 bytes to 1,412 and its first fact moved from character 10,152 to line 8. On the commerce capture, a product page went from 91,226 bytes to 1,315 with the first fact moving from character 23,185 to line 4. The facts were identical in both cases; only the packaging changed.
The two are quoted separately on purpose. A product page and a services page carry different amounts of chrome, so there is no honest single number between them, and a vendor quoting one average across all site types is telling you about their sample rather than about yours.
How the subtraction happens
Content negotiation, done at the edge. A request asking for markdown receives markdown assembled from values you already store; browsers and search crawlers receive exactly what they received before.
import { gateway } from '@rebilder/gateway'
export default gateway({
source: { kind: 'document', resolve: myPages },
})