Geist and the first Layout: testing font warmup and homepage cards

1. Count Geist warmup itself, not just the cheaper Layout afterwards

On October 23 we tested the homepage in Chrome 153.0.8010.36 with actual CPU ×4 throttling. Separate cold-profile series checked early font preparation and complete loads over a local HTTPS/HTTP2 relay with fixed published HTML, original startup JavaScript and unchanged font files. The full-load tests used a 412×823 viewport, DPR 1.75, 562.5 ms network latency and 1474.56/675 Kibit/s download/upload throughput. Arm order rotated; analytics collectors were suppressed equally, scripts retained. These are direct Chrome/CDP laboratory measurements, not new Google PageSpeed reports or real-user data. A smaller following Layout alone does not prove a faster first screen: the warmup's own elapsed time must remain in the comparison.

First, a separate mechanism test used static homepage HTML without startup scripts. Identical font-face rules were moved into the head; original Sans Latin/Cyrillic and Mono files were delivered early, CSS was released after 2 seconds, and the root was hidden identically until 2.5 seconds to prevent an early unstyled Layout. This artificial window is only a control, not a proposed loading strategy. We measured 17 font/style combinations with a short sample, or measured and drew 44 text blocks to a detached canvas and read its bitmap to include drawing cost. measureText also processes the sample text; it is not a pure font-metrics lookup.

Warmup reduced the following Layout from 389 to 192 or 104 ms, but the combined work increased from 391 to 485 or 606 ms. The final column is the median of each run's sum, not the sum of separately rounded medians. Every following Layout still contained 150 objects and 35 shaping calls. This isolates a warm-state effect, not one specific cache. An idle window could overlap warmup with network waiting, so these sums are work durations, not predicted production LCP.

In the full-load series, startup JavaScript remained intact and neither CSS nor rendering was gated. The three experimental variants shared early Sans font-face declarations and load calls for the two already-preloaded subsets; only their Canvas work differed. Warmup began after the first substantial Layout in all 10 warmup loads, after H1 paint in nine and after LCP in seven. The roughly 2.9-second medians do not demonstrate a stable benefit or statistical equivalence. The no-Canvas early-load control was especially variable; its 8.004 and 9.748-second results are retained, not attributed to the absence of Canvas. Two Page.navigate timeouts were retried and excluded as nonnumeric failures; the successful retries appear in the five-run samples. An aborted Lighthouse attempt is not mixed into this CDP series.

Waiting only for Cyrillic at the heading's weight and size, without Latin, did not create an early opportunity either: all six warmups began after the first Layout. The short sample now took about 8 ms and three Cyrillic-only fragments about 85 ms, but this was after the page had already used the font. Two short-sample loads exceeded 3.8 seconds; three samples do not establish that this API caused the delay. These tests do not justify adding the tested warmup or waiting for document.fonts.ready to the site's startup.

2. Check whether deferred homepage cards stay off the LCP path

The same HTTP/2 and CPU ×4 setup compared 20 cold loads, five per CSS variant, keeping homepage HTML, scripts, font bytes and preload order fixed. We tried content-visibility: auto on the three library cards with an estimated intrinsic block size of 400 px on mobile and 240 px on wide screens. The first card already begins at about 608 px in the 823 px viewport, so it must remain visible. Two controls separated ordinary layout/style/paint containment from permanently excluding the lower two cards' rendering. Auto can start rendering nearby offscreen content before scrolling; it is not a promise to skip everything below the viewport edge.

All durations are medians; the first substantial Layout covers different work: usually 150 objects in the baseline, versus 67–97 with auto. In one matched pair, the baseline used a 760 ms first pass. Auto split the work into 126, 245 and 361 ms passes before H1 paint; together they performed the same 35 shaping calls. The first H1 paint was 2761 versus 2780 ms, with LCP at 2872 versus 2860 ms. Auto's earlier FCP in that run was only the small EN link, not the headline. State notifications eventually reported skipped:false for all three cards in every auto load; those asynchronous notifications alone cannot identify the contents of a particular early Layout.

The median LCP improvement of 104 ms when cards 2 and 3 were forcibly excluded is only diagnostic context, not a strict upper bound or a working lazy-rendering implementation: their contents stayed invisible and unavailable for normal interaction on scroll. The tested auto variant did work functionally: baseline and auto matched in RU/EN at widths 360, 412 and 1280 px; the libraries anchor settled within 0.4 px, scroll height stayed stable, all three examples opened and focused correctly, and no horizontal overflow or JavaScript errors occurred. CLS was zero in all 20 timing runs. These results do not justify adding card containment for LCP on the current short homepage; the lower algorithm sections remain a separate, previously measured case.