Parsing Web Pages: Sending the Whole Thing to an LLM Gets Expensive — I Measured What Moving It Local Saved

2026年8月19日

When I started pulling specific facts out of large web pages, I simply handed the whole page body to an LLM and let it get on with it. It works, but the tokens per page balloon, and the cost starts to bite as the number of pages grows. So I stopped feeding entire pages to the LLM: fixed values get extracted in code, and only the genuinely ambiguous parts go to a local LLM (ollama) on my own machine. Here is how much the token count for the same job changes, measured on my PC (RTX 3090 + RTX 3060 + ollama).

Measured 22 June 2026, using the tokeniser of the local model gemma4 (26B MoE). The subject was a publicly available technical listing page.

Why handing over the whole page costs so much

What you pay an LLM is roughly proportional to how much text you put in (tokens). Web pages are heavier than they look; the body alone runs to thousands or tens of thousands of tokens. For one page that is nothing, but process dozens or hundreds and the input tokens simply stack up.

The awkward part is that even when what you want is a tiny fraction of the page, like a price or a part number, sending the whole thing means paying for the whole thing. You want a few dozen characters and you pay for a full page.

The idea: code for fixed values, the LLM only where it is ambiguous, a real browser for fetching

Break the job into stages and give each one the cheapest reliable tool. What goes to the LLM is narrowed to the parts that need something like judgement.

For pulling out fixed values, a regular expression or a DOM selector is faster than an LLM and does not miss. The LLM’s turn comes only for things that resist rules: normalising a manufacturer’s inconsistent naming, or picking the right one out of several candidates.

Fetching: use a real browser

Pages whose contents are drawn by JavaScript after load often come back empty from a plain HTTP request. Using a real browser like Playwright, so you can wait for the page to render before taking the body, is the dependable approach. No LLM is involved here. The HTML goes straight to the extraction stage.

Extraction: code for fixed values, the local LLM only for fuzzy matching

From the HTML you have, first take everything that can be taken mechanically. Values with a fixed shape, like prices and part numbers, are well served by regular expressions and DOM selectors. Nothing here consumes a single token.

What is left, the parts that require a decision, go to the local LLM as a short excerpt, and come back as JSON. With ollama it all stays on your machine, so however many requests you make, no metered external bill appears. The smaller you keep the text you send, the faster and lighter the processing.

Measured: whole-page against the hybrid

For the same single page, I measured input tokens three ways. One, hand over the entire page body. Two, a realistic extraction that sends only the relevant tables. Three, an extraction narrowed to the one block actually needed.

Against 13,136 tokens for the whole page, narrowing to the relevant tables gives 3,717 (about a quarter), and cutting to just what is needed gives 567 (about a twenty-third). Where you land depends on how much you can preprocess in code; from what I have read, real-world work often settles around a sixth of a page. Either way, the less text you hand the LLM, the more the cost falls, in a straight line.

How far does local get you, and what to do when it does not

Turning a small excerpt into JSON is well within the reach of a mid-sized local model. Summarising across a long context, or interpreting difficult phrasing, is where a local model starts dropping things. Sending only those heavy decisions to a larger cloud model, and keeping the high-volume simple work local, is the realistic dividing line.

If the local side is not accurate enough, the fixes are: step up a model size, revise how the excerpt is built so the necessary clues are in it, or constrain the output with a JSON schema.

Where else this applies: price watching, stock, catalogues, gathering material

This split is not specific to product information. Keeping an eye on prices and stock levels, tidying a catalogue, collecting material for an article: anything that means “turning a lot of semi-structured data into a fixed shape" fits almost unchanged. Code for fixed values, the LLM only where it is ambiguous, is the same skeleton throughout.

What you need to run this: the machine underneath

Running a local LLM comfortably takes a reasonable GPU, or a machine with wide memory bandwidth.

As an Amazon Associate we earn from qualifying purchases.

Once your own environment is in place, the high-volume work moves off the meter and external billing narrows to the decisions that actually need it. Start by measuring the token difference between whole-page and extraction on one small page: the effect shows up immediately.