Synthesis

The evolving thesis. Current best understanding of this wiki’s topic, updated on every ingest.

Current thesis

This wiki covers web performance and page-weight minimalism. The founding provocation, landing-page-14kb, makes the case that a complete, accessible, production-grade landing page fits in 14 KB (one TCP slow-start window, <50 ms render) against a ~2,600 KB median web page — by dropping JS entirely, using system fonts, and inlining SVG. The implied thesis: most web bloat is optional, and the usable floor is far lower than common practice.

The baseline is now measured, and it corroborates the provocation. page-weight is no longer a single advocacy claim: the web-almanac (HTTP Archive, neutral field data) puts the median page at 2,652 KB desktop / 2,311 KB mobile (web-almanac-page-weight-2024) — independently confirming the “2,600 KB” figure the 14 KB piece used as its foil, and showing it is still growing (+7% YoY; ~357% over a decade for mobile). Composition: images ≈1,054 KB, JS ≈613 KB and now the most-requested file type, fonts ≈131 KB, CSS ≈78 KB, HTML ≈18 KB. So bloat is real, optional, and JS-led — exactly where bundle-size and squint aim.

Why minimize at all? The SEO/business case is now partly mapped. The report core-web-vitals-seo traces how performance touches search: Google’s core-web-vitals (LCP/INP/CLS, measured on real users via CrUX) are a confirmed but minor ranking factor — a quality baseline and tie-breaker that avoids a penalty rather than driving visibility (a 2025 study of 107k pages found only r ≈ −0.12…−0.18 between LCP and search presence). The larger payoff is indirect (lower bounce, more engagement/conversions). So byte minimalism helps SEO only insofar as it improves real-user Core Web Vitals, and even then the direct ranking benefit is capped at “good.” Minimalism is better justified by UX/cost/resilience than by raw rankings. The responsiveness vital, inp (Interaction to Next Paint), replaced FID in March 2024 and sharpens the JS critique: it scores all interactions (good ≤200 ms / poor

500 ms) by input delay → processing → presentation, so JS is not only load weight but where the main thread is felt. For interactive apps the binding constraint shifts from transfer bytes to main-thread execution — a partial answer to whether the 14 KB floor matters beyond static pages: for apps the lever moves from bytes to execution.

Lab vs. field — what actually gets measured. Two tools anchor the chain. lighthouse is a single synthetic load (lab data); crux (Chrome UX Report) is the p75 / 28-day distribution of real Chrome users — and only CrUX feeds Search. A great lab score is not a good field score, which is the measurement-side of the page-weight-vs-architecture tension: because CrUX scores executed experience, equal-byte pages can post different CrUX numbers (delivery codec, main-thread cost). CrUX carries its own caveat the crawl-based web-almanac lacks — eligibility needs publicly discoverable pages with significant Chrome traffic, so it is the best public field signal, not a census. Net the chain is end-to-end: author bytes → delivery/execution → CrUX field metrics → ranking. Diagnose with Lighthouse, judge with CrUX.

Three layers of minimization are now in view. landing-page-14kb minimizes by hand-authoring less (a static-page lever); squint minimizes by changing the compiler so a high-level source language emits small JS (a tooling/language lever); and a delivery layer minimizes the bytes you ship regardless of what you authored. On that delivery layer, brotli (RFC 7932, Google) beats gzip on text for free and directly answers the standing “why is basic optimization under-adopted?” question — the Almanac finds only ~70% of pages use any text compression, so the same authored bytes transfer at very different sizes depending on codec. avif is the image analog and the single highest-leverage saving, since images (~1,054 KB) are the largest slice of the median page; modern royalty-free formats beat JPEG/WebP at ~93% browser support. So author-side levers reduce bytes you write; delivery-side levers reduce bytes you ship them as. Generalizing across the author/tooling layers, bundle-size is the JS-app-era successor to page weight, and its levers are: ship less code you wrote, ship less runtime, and emit tree-shakeable modules. Squint is also the first source to address interactive/app code rather than static pages, and it begins to engage the open question of whether the tight byte floor survives beyond static landing pages — by tooling toward it rather than hand-authoring.

From feat to discipline: budgets and two byte layers. Minimalism need not be a one-off heroic page — performance-budget (performance-budgets-101) turns “ship fewer bytes” into a CI gate (Lighthouse CI / bundlesize). It also reveals three nested byte targets: the 14 KB first-RTT floor (landing-page-14kb), web.dev’s 170 KB compressed critical-path budget over 3G, and the 2,652 KB median reality. These aren’t in conflict — they’re the same idea at different scopes (first packet → critical path → whole page).

The thesis splits into a first-party and a third-party layer. Hand-authoring less (landing-page-14kb), smaller bundles (bundle-size/squint), and budgets all govern first-party bytes. But web-almanac-third-parties-2024 shows 92% of pages load third parties (popular sites a median of 66), mostly scripts (30.5%), with Google owning 5 of the top-10 domains and a median inclusion-chain depth of 3.4 — much third-party weight is indirect, never chosen by the author. So third-party-resources are a separate, governance/consent problem that first-party minimalism can’t reach; a budget can cap their count but enforcement is organizational, not just a build flag.

Sources now include a provocation (landing-page-14kb), a synthesized report, a tooling exemplar (squint, README claims), neutral HTTP Archive field data (web-almanac chapters), and vendor guidance (performance-budgets-101). The neutral data has moved the page-weight baseline from hypothesis to established finding; the floor itself remains a hypothesis to test.

Open questions

• Does the 14 KB floor hold for interactive apps, or only static landing pages? (squint is a tooling-side bet that small bundles are reachable for app code — but how small, measured, vs. a plain-JS or full-ClojureScript baseline?)
• Language/tooling-level minimalism (squint) vs. hand-authoring minimalism (landing-page-14kb): which gives more byte savings per unit of effort, and do they compose?
• How much of typical bloat is analytics / third-party scripts vs. first-party code? Partly answered (web-almanac-third-parties-2024): third parties are on 92% of pages, are mostly scripts, and arrive via deep inclusion chains — a structural slice of page-weight, not a rounding error. Remaining: a clean first-party-vs-third-party byte split (the chapter gives prevalence/requests more than a definitive byte share).
• What is lost (if anything) at this floor — A/B testing, personalization, tracking? (Much of that is the third-party-resources layer — so the cost of the floor is partly the cost of dropping third parties.)
• If Core Web Vitals ranking benefit plateaus at “good,” how low do bytes actually need to go for SEO — i.e. where’s the point of diminishing SEO returns vs. UX returns?
• Why is basic optimization under-adopted? The Almanac finds only ~70% of pages use text compression and minification has fallen since 2022 (web-almanac-page-weight-2024) — is the obstacle tooling defaults, third-party injection, or incentives?

Contradictions

• Page weight vs. architecture (cross-wiki). This wiki’s premise — fewer bytes → faster → better — meets a counter-claim tracked in static-site-wiki: real-world core-web-vitals are driven by architecture and delivery as much as payload size (HTTP Archive field data: bytes correlate with LCP but are not the dominant factor; CLS barely correlates with bytes; Shopify is heaviest yet fast). Reconciliation: bytes are necessary-but-not-sufficient. Minimalism still helps, but is not the whole game. This wiki’s own web-almanac-page-weight-2024 now reinforces the delivery side from the same HTTP Archive corpus: only ~70% of pages use text compression and the 90th-pctile mobile Total Blocking Time is 5,786 ms — i.e. how bytes are compressed and executed swings real-user metrics as much as the byte count, so both lenses read the same field data and agree on “necessary-but-not-sufficient.”

Index

Catalog of every wiki page, grouped by schema.org @type. Read this first when answering a query, then drill into the relevant pages. Updated on every ingest.

BlogPosting (sources)

• landing-page-14kb — shipping a working landing page in 14 KB / web-perf minimalism · source

DefinedTerm

• web-performance — umbrella: load/response speed via shipping less + executing less; the byte layers, the measurement chain, and budgets · domain
• page-weight — total bytes a page downloads; the wiki’s founding concept + measured baseline · concept
• bundle-size — JS-app byte weight; the app-era successor to page weight, and its levers · concept
• third-party-resources — analytics/ads/embeds you use but don’t author; 92% of pages · concept
• performance-budget — enforced byte/timing limits that gate the build; minimalism as discipline · practice
• core-web-vitals — Google’s CrUX field metrics (LCP/INP/CLS); the SEO + perf yardstick · standard
• inp — Interaction to Next Paint; the responsiveness Core Web Vital (replaced FID Mar 2024); ≤200ms good · source · standard
• brotli — RFC 7932 lossless text codec (Google); beats gzip on HTML/CSS/JS; the delivery-side byte lever · source · mechanism
• avif — modern royalty-free image format; beats JPEG/WebP on the biggest page-weight slice · source · mechanism

SoftwareApplication (tools)

• lighthouse — Google’s open-source page-audit tool; lab data (LCP/TBT/CLS), 0–100 scores; lab-vs-field caveat · source

Dataset

• crux — Chrome UX Report; real-user (field) Core Web Vitals at p75/28-day; Google Search’s actual signal; lab-vs-field anchor · source

Periodical

• web-almanac — HTTP Archive’s annual data-driven report; the wiki’s neutral field-data baseline

Report

• core-web-vitals-seo — how Core Web Vitals affect SEO: confirmed but minor ranking factor
• web-almanac-page-weight-2024 — HTTP Archive median page weight + resource breakdown · source
• web-almanac-third-parties-2024 — prevalence/weight of third parties; Google’s dominance · source

TechArticle (sources)

• performance-budgets-101 — web.dev’s primer on performance budgets and their enforcement · source

SoftwareSourceCode (sources)

• squint — light-weight ClojureScript dialect; compiles to small native-JS bundles · source

Synthesis

• synthesis — the evolving thesis (open questions + flagged contradictions)