Website rebuild performance against legacy

The rebuilt website is competitive on a dynamic player page at low load, but it does not yet match the legacy site's serving capacity. The largest gaps appear on public pages that legacy can return as compact, reusable HTML while the rebuild generates a larger, private response for every request.

Across 91,909 requests to five matched pages, the two sites returned 85,064 complete HTML documents. Legacy completed 73,426; the rebuild completed 11,638. Despite that difference, the rebuild transmitted 7.90 GB, compared with legacy's 6.62 GB, because each rebuilt document is substantially larger.

Executive results

Public-page throughput

The widest gap is on routes that can be prepared once and reused. Legacy serves /100-club at roughly 1,000 requests per second from 128 through 2,048 connections. The rebuild plateaus around 70 requests per second.

At 2,048 connections, legacy completes every /100-club request with a 2.16 s median. The rebuild completes 2,035 of 2,048 with a 30.83 s median. Both processes remain available after the run; the difference is queue length, not a crash.

/player-stats has the same shape:

The zero at 2,048 is deliberate: all rebuilt requests crossed the 30-second timeout, so counting completed timeout errors as throughput would manufacture a success from failed work. Legacy completed all 6,144 responses at that level with a 2.78 s median.

Dynamic pages are closer

The player detail page is the rebuild's strongest result. At one connection it returns in 22.4 ms median, compared with 26.5 ms for legacy. It sustains 52.0 requests per second without failures at 32 connections, against 70.3 for legacy.

This is an important distinction. The rebuild is not uniformly slow, and the Go API behind it is not the general bottleneck. The low-load player result shows that its server-side data path can be faster. The larger regression starts when the application has to serialize and queue many full App Router documents.

The response is carrying more work

Every request asked for uncompressed HTML so the comparison measures the bytes each application generates before a proxy or browser compresses them.

The byte result rules out a simple runtime comparison. The rebuild is doing more work per response: it renders the HTML shell and serializes React Server Component data for hydration. On the player detail page, that extra work still produces a lower low-load median. On the public content pages, it combines with request-time rendering and becomes the dominant cost.

Cache behavior compounds the origin result

Header probes after warm-up returned the same policy on all five routes:

The benchmark connects directly to each application container, so no CDN or reverse-proxy cache answered these requests. Legacy's public header therefore does not explain its origin throughput advantage. It does mean that a cache in front of the two sites can reuse legacy documents for five minutes while it must forward every rebuilt request to the application.

The source shows why some rebuilt routes become request-time documents. The 100 Club route reads the signed-in reader's watchlist through getPrivateApi inside the same server component that fetches the public board; that helper reads cookies and disables caching. Public layouts also resolve locale from a cookie and pass the selected catalogue into client providers. Personal data is valid, but placing it in the full document path makes the public shell private.

Saturation and failures

The high levels distinguish a deep queue from a dead process. Neither site stopped responding, and both were healthy after the run.

Legacy's home page records 41 timeouts at 512 connections, then times out 2,048 queued requests at the final level. The rebuild reaches the same condition at 512, so its 2,048 level is skipped. On the other four routes, legacy completes every request through 2,048 connections. The rebuild completes most player detail requests at that level, but fully times out on Player Stats and Fixture.

Memory after load

Container memory was sampled before the run, immediately after it, and after the servers had cooled without receiving benchmark traffic. These are snapshots, not a continuous peak measurement.

The rebuild releases most of the immediate surge, but it settles about 805 MiB above its starting point. This run is too short to call that a leak. It is enough to make retained memory a measured capacity concern and to justify a heap profile during the next pass.

Test design

The comparison ran on 2026-08-29 with the following controls:

The fixed player and fixture ensure both applications render the same subjects. The response bodies are not byte-identical because the products do not ship the same document architecture; payload size is therefore a measured result, not a controlled constant.

What the report does not measure

• It measures the initial HTML document, not JavaScript, CSS, images, hydration, interaction latency, or Core Web Vitals in a browser.
• Identity encoding exposes server serialization cost. Real clients negotiate compression, which reduces transfer size but adds compression work somewhere in the delivery path.
• Client and servers share one host. At high concurrency, the load generator competes with the target for CPU and memory bandwidth.
• Six-second levels establish throughput and saturation. They do not establish long-term garbage-collection behavior or a memory leak.
• The legacy public cache policy may be too broad for personalized pages. The report identifies its capacity effect; it does not recommend caching private user data.

Recommended order of work

1. Separate public and private rendering. Render cacheable board and entity documents independently from watchlists, sessions, locale preferences, and other reader-specific islands.
2. Restore public cache semantics. Keep authenticated fragments private, but allow shared page shells and public API reads to be reused by the application and edge cache.
3. Set an HTML/RSC payload budget. Start with the 100 Club and Player Stats routes, where the rebuild emits 6.3× and 7.1× the legacy bytes.
4. Profile retained memory. Capture a heap snapshot after the 512-connection level and compare it with the cooled 1.16 GiB state.
5. Rerun the same matrix. The checked-in harness and raw CSV make caching, payload, latency, and failure changes directly comparable with this baseline.

Client conclusion

The rebuild has a competitive dynamic data path: its player detail page is faster than legacy at one connection, and it remains within the same order of magnitude under normal concurrency. The current delivery architecture gives up that advantage by generating private documents that are several times larger.

The next performance milestone is therefore specific and measurable: make public responses reusable, reduce serialized document size, and bring the two public-page plateaus above the current 70 and 49 requests per second. Those changes target the bottleneck this run actually found rather than adding servers around it.