The Sashfold 100

The Sashfold 100

Every night Sashfold renders a hundred pages of the live web and publishes every picture, retouching nothing — twice: the Windows build's render at sashfold.com/sashfold100 and the Linux build's beside it, each linking the other.

The corpus

tests/sashfold100/corpus.txt — a hundred pages drawn from the Tranco list of the most visited domains, each row carrying its site's rank there, in twelve categories:

Category	Rows
Wikipedia's "Web browser" article in nine languages	9 (two right-to-left, shown greyed)
Documentation	12
News fronts and sections	12
Government	8
Blogs and their engines	8
Link aggregators	4
The standards themselves	6
The plain web (text-only editions, craigslist, textfiles, Gutenberg, arXiv, the world clock, OpenBSD, LWN)	10
Pictures	8
The badssl.com report card	7 (five bad certificates that must be refused, and plain HTTP)
The ten most visited sites, as they are	10
Projects (Sashfold's own repository among them)	6

What is published

For every row: the picture (cut at 2400 px, with a thumbnail), the status, the time from request to pixels, the page's height, its stylesheets, pictures and fonts with their failures, the connections used, whether a bad certificate was refused — and what the page's stylesheets ask for that Sashfold does not do yet, counted across the hundred. That table, ranked by pages asking and by declarations, is the order the engine work goes in. A page's scripts run for three seconds of virtual time before the picture is taken; a page that still arrives blank is shown blank.

Where the seconds go

Beside the pictures, the dashboard carries a table of where the time in each row went: name lookup, connect, the TLS handshake, the wait for a first byte, the rest of the body, and the engine's own style, layout and paint — each step's median page and its share of the hundred's sum, with the ten slowest pages named. The same numbers are written as census.tsv next to index.html, and tools/perf-census.sh <out> [--top N] [--by <column>] ranks them from the command line. On one machine on 2026-09-16, 87 of the hundred loaded: a median of 2961 ms to pixels, 2154 ms of it network (71%) and 1592 ms of that the wait for a first byte alone (50.5% of everything), with TLS handshakes at 238 ms; the engine's own median was 459 ms. The dashboard's own figures come from the runners and move as the corpus and the engine do.

How it runs

• .github/workflows/pages.yml renders the corpus on a Windows runner and on a Linux runner every night at 04:17 UTC, on every push to main, and on request, then deploys the site with both sets of pictures. The Windows build's HTTPS goes through the platform's secure channel, the Linux build's through the engine's own TLS client, so a page that one loads and the other does not shows as such. Nothing rendered is committed.
• bash tools/sashfold100.sh <sashfold> <out> [--corpus <file>] [--jobs N] [--timeout S] [--only <substring>] [--at <site-dir>] [--rendered-on <text>] [--twin <label> <href>] renders it anywhere: one page per process under a time limit, rows taken round-robin across the categories so no host sees a burst, then sashfold100 (built from tools/sashfold100.cpp) writes index.html and sashfold100.json into <out>. The last three options tell the dashboard where under the site it will be published (its links follow from that), which build drew it, and where the other build's copy is.
• The dashboard page renders in Sashfold itself.

Reading it

The runner's IP meets more bot walls than a home machine does (some sites answer 401 or 403 to it); sites that are script-only arrive as "200, no text". The heading carries the time of the newest render, and the page and its JSON their own, all on Arizona twelve-hour time (UTC-7 the year round), so a comparison knows how fresh the pictures are.