Parsing a large spreadsheet without freezing the page

Streaming reads for honest progress, worker-thread parsing, and prebuilt indexes — how this tool stays responsive.

Streaming the download

Fetching a file and awaiting the whole response gives you no progress information, so a progress bar built that way is a lie. Reading response.body as a stream and counting bytes against the content-length header produces a real percentage, which is what the status line reports.

Because the file arrives in chunks, the chunks then have to be assembled into a single buffer before the parser can see it — a copy worth the cost for accurate progress.

Parsing off the main thread

Parsing tens of thousands of spreadsheet rows takes long enough to drop frames and block input. Handing the buffer to a Web Worker moves that work to another thread; the page stays fully interactive while it runs. Transferring the buffer rather than copying it means the handoff itself costs nothing.

Indexing at parse time

Filtering by region could scan every row on each request. Building a map from region name to row offsets while the rows are already being walked turns that into a lookup, at the cost of one pass that was happening anyway.

Caching for the session

Once parsed, the result is held in memory for the session, so moving between the two generators does not re-download or re-parse anything. Nothing is written to disk and nothing persists after the tab closes.

Failing over

The primary source is object storage with a second provider behind it. If the first request throws, the fetch is retried against the fallback and the status line names which one answered — useful when diagnosing whether stale data is the tool's fault or the pipeline's.