How this website uses C++ and WebAssembly

What happens when you open a page?

1. A Cloudflare Worker receives the HTTPS request. Its TypeScript adapter passes bounded fields such as the method, path and origin to the C++ engine.
2. The engine selects a route, renders the reviewed HTML and returns response policy decisions. Public content and metadata are embedded at build time.
3. The adapter constructs the HTTP response. Cloudflare asset delivery, cryptography and database operations stay in the platform adapter.
4. The browser renders ordinary HTML and CSS. Small scripts support functions such as calm mode and the pilot-interest form; they are not a client application framework.

The WebAssembly module has no imported runtime functions. This describes the module boundary, not the whole website: the surrounding adapter still performs the external work.

What did we measure?

On 9 September 2026 we rebuilt website version 2.5.0 with Clang 18.1.3 and LLD 18.1.3. All 83 source hashes in the build receipt matched revision d05161ab2c897d4adebccc4fb367441ad99c5bc7. These are that baseline's sizes; later content updates produce different artifacts.

The gzip column uses local level-9 compression. It does not report actual network transfer sizes or include HTML, images or additional infrastructure resources. The server artifacts are not browser downloads.

The module declares 2 MiB of initial linear memory and a 4 MiB maximum. Its memory remained 2 MiB after 8,400 measured page requests. These figures describe WebAssembly linear memory, not total Worker memory or a security qualification.

Read the complete baseline measurements and limitations

How the local request measurement works

We used Node.js 24.19.0 on Linux x64 to instantiate the compiled module with no imports. For each of the homepage, applications, Trace and contact routes, the script performed 100 warmups and seven batches of 300 sequential GET requests. It checked successful status and complete HTML while retaining the raw batch timings.

The median of the batch means ranged from 0.0633 to 0.0875 milliseconds per request. Each timed loop included input encoding, memory reset, routing, rendering, output decoding, header construction and assertions. It excluded the network, TLS, Cloudflare scheduling and service calls, the full HTTP adapter, concurrency and browser rendering.

These are local engine observations. They are not individual-request p50 or p95 values, production cold-start measurements or mobile loading times. Shared-host timings vary; this experiment does not show that C++ is faster than another implementation.

Repeatable build checks

With access to the selected build, check the byte size and SHA-256 of each artifact, inspect WebAssembly.Module.imports(module), and compare the build receipt's source hashes with the chosen revision before timing requests. Keep the compiler, runtime, warmup count, batch sizes, raw results and exclusions together. The baseline download records those details; the source repository retains the measurement script.

What this approach does and does not solve

• Reviewed content stays in the server response. Readers and crawlers can access the article body and links without executing a client application.
• Content edits require a rebuild. Embedding pages makes deployment self-contained, but this is less convenient than a content management system for frequent editorial work.
• The platform adapter remains necessary. Choosing C++ does not remove database, authentication, network or operational responsibilities.
• Layout still needs browser testing. A rendering language cannot prevent CSS grid errors, small touch targets or mobile text clipping.
• Measured evidence has a scope. Build size and local timings cannot establish real-user Core Web Vitals, search rankings or AI citations.

For another example of separating a requirement from measured behavior, watch the captioned C++ review exercise. Its transcript, original source and recorded output show exactly what was tested.