Direct answer: Across 25 analysable homepages, time to first byte (TTFB) has a median of 215ms (P25 122, P75 293, max 2,342), and HTML size a median of 68.7KB (P25 24.8, P75 168.5, max 457.6). The correlation between them is -0.16, essentially none. Single request, single location, captured across two days — not CrUX, and not a ranking.
This is the background data for acceptance clause 8. The clause only asks to "record TTFB and HTML size, and never call it CrUX"; this round uses the anonymised data already published in round 4 to answer two questions: what the distribution looks like, and whether "bigger page = slower first byte" holds.
Method: second-pass statistics, no new requests
Data comes from the ttfb_ms, html_kb, h1_count and jsonld fields of docs/research/2026-11-equipment-robots-scan.csv; the 25 rows with http_status=200 are included. No site was revisited.
TTFB is the time from sending a request to receiving the response headers; size is the HTML response body, excluding images, CSS, JS and fonts. Capture spans 2026-10-31 and 11-01 (5 and 20 rows), not a single concurrent moment — the main reason this cannot rank sites.
| Metric | Min | P25 | Median | P75 | Max | Mean |
|---|---|---|---|---|---|---|
| TTFB (ms) | 81 | 122 | 215 | 293 | 2,342 | 340.2 |
| HTML (KB) | 1.3 | 24.8 | 68.7 | 168.5 | 457.6 | 114.4 |
n=25. A single outlier lifts the mean: TTFB mean 340.2 exceeds P75 293, so the median and quartiles are used below.
Distribution: half within 200ms, one above a second
| TTFB | Sites | HTML size | Sites |
|---|---|---|---|
| ≤200ms | 12 | ≤50KB | 11 |
| 201–500ms | 9 | 51–100KB | 4 |
| 501–1000ms | 3 | 101–200KB | 6 |
| >1000ms | 1 | >200KB | 4 |
TTFB concentrates below 500ms (21/25) with one 2,342ms outlier; HTML size is more spread out, from a 1.3KB minimal page to 457.6KB, with four above 200KB. The size P75 (168.5KB) is 2.5× the median (68.7KB): most sites are not heavy, a few are very heavy.
Size versus first byte: almost no linear relation
Pearson's r across 25 points is -0.16. Two extremes say more than the coefficient: the heaviest page (457.6KB) had a 118ms TTFB, while the slowest (2,342ms) shipped only 23.5KB of HTML.
That matches the mechanism: TTFB depends on DNS, connection setup, server processing and the first packet; HTML size affects download, parsing and rendering. Treating "big page" as the cause of "slow first byte" fixes the wrong thing — swapping servers when you should compress images, or the reverse.
Structural signals split by size
| Group (split at 68.7KB) | Sites | Exactly one H1 | Has JSON-LD |
|---|---|---|---|
| Heavy (>68.7KB) | 12 | 6 | 4 |
| Light (≤68.7KB) | 13 | 2 | 1 |
The heavy group scores higher on H1 and JSON-LD, but this is a post-hoc split with 12 and 13 sites. It does not support "heavier pages are better structured". A more likely explanation is that larger sites carry more features and more complete templates, and therefore more markup — or it is coincidence. Keep it as a hypothesis for a larger sample, not a conclusion.
Five actionable conclusions
- Record, do not rank. The clause wants a reproducible record: time, UA, measurement point and compression, together.
- One TTFB sample is not a verdict. Take at least three and use the median, and state the network and time; one jitter can flip the call.
- Do not infer first byte from size. Correlation here is -0.16; measure and fix them separately.
- Size needs composition. Only HTML was counted; images, JS and fonts are excluded, so HTML size is not page weight.
- Never call it CrUX. Real-user percentiles need CrUX or RUM; a single-point measurement is a proxy.
Limits
- Single request, single point: affected by DNS, TLS, path and momentary load.
- Two capture days: 5 rows on 10-31 and 20 on 11-01, with different conditions.
- HTML only: no images, CSS, JS or fonts; not a first-screen experience measure.
- Non-random sample: one list, one city, 25 sites; a pilot, not the industry.
- No causality: size, TTFB and structure may share third factors.
- Not a score: conditions are not controlled; it shows what to record.
Data and recalculation
Source data: equipment-website-robots-scan-2026.csv (30 rows, including ttfb_ms, html_kb, h1_count, jsonld); the repository keeps docs/research/2026-11-equipment-robots-scan.csv.
Statistics script: scripts/performance_summary.py (quartiles, buckets, Pearson); tests: scripts/test_performance_summary.py (14 tests, no network). Run:
python -m unittest scripts.test_performance_summary
Related: the 30-site robots scan (same data), the 24-site four-layer review and the 12 acceptance clauses (item 8).
Sources and definitions
- TTFB definition and measurement caveats: web.dev — Time to First Byte.
- Core Web Vitals and CrUX: web.dev — Web Vitals.
- Capture: 2026-10-31 and 2026-11-01, UA
LingyiResearchBot/1.0, one homepage request per site.