Log
Append-only history. Each entry: ## [YYYY-MM-DD] <op> | <title> where <op> is
ingest, query, or lint. Query with grep "^## \[" log.md | tail -5.
[2026-05-29] split | created from research-wiki cluster D
Spun out of the research-wiki as its own wiki (web performance was off that wiki’s knowledge-management thesis). Migrated 1 source / 1 page: landing-page-14kb. Re-homed index/log/synthesis; removed cluster-D / “intentional orphan” framing from the page. Original ingest 2026-05-29 (see research-wiki log history).
[2026-05-29] lint | health check (1 source, 1 page)
Clean: single page, reachable from synthesis, no broken links. Nothing to fix. Recommendation: this is a one-source wiki — its thesis is a provocation, not a finding. Needs ≥2 more web-performance sources (e.g. HTTP Archive data, a counter-argument on when JS is justified) to become a real wiki; otherwise fine to leave dormant.
[2026-05-29] lint | health check (1 source, 1 page)
Clean: single page reachable from synthesis, no broken links. Unchanged since last lint. Recommendation stands: still a one-source wiki — needs >=2 more web-perf sources to be a real wiki, or leave dormant. No fixes needed.
[2026-05-30] query | report — how Core Web Vitals affect SEO
Answered a request to report on Core Web Vitals’ SEO impact; filed the result here as core-web-vitals-seo (Report) + anchored a core-web-vitals concept page (DefinedTerm). Grounded in Google Search Central + DebugBear/Vercel/RUMvision. Findings: CWV are a confirmed but minor ranking factor (page-experience signal) — field data (CrUX) only, tie-breaker / penalty-avoidance, plateaus at “good”; larger SEO value is indirect via UX. Wove into synthesis: this is the SEO mechanism behind page-weight minimalism (bytes help only via real-user CWV, capped at “good”), and recorded the cross-wiki page-weight vs. architecture contradiction with static-site-wiki (reconciled as necessary-but-not-sufficient). This moves the wiki past the one-source mark the prior lints flagged.
[2026-05-31] ingest | Squint — light-weight ClojureScript dialect
Routed in by the hub router (runner-up: none; static-site-wiki considered but Squint is a
compile-to-JS language, not an SSG/framework). URL-only source (GitHub repo), so the page
carries url: not sources:. Created squint (SoftwareSourceCode, source:true) and a
new bundle-size concept page (DefinedTerm). Key claim: Squint emits lightweight JS by
compiling to native JS data structures instead of ClojureScript’s immutable-collection
runtime, trading Clojure semantics for small bundles + interop; targets CloudFlare workers,
node scripts, GitHub actions. Wove into synthesis a two-layer minimization frame
(hand-authoring vs. compiler/tooling) and noted this is the wiki’s first interactive/app
source vs. its prior static-page focus. Caveat: README claims, not independently benchmarked.
[2026-05-31] lint | health check (3 sources, 5 pages)
Part of a hub-wide lint, run just after the squint ingest. Clean: no orphans, no broken links, full raw coverage; new bundle-size concept is well-linked into squint, landing-page-14kb, and core-web-vitals. Past the one-source flag the early lints raised (now 3 sources + a filed report). Findings: (1) squint‘s small-bundle claims are README-sourced, not benchmarked — a measured bundle-size comparison (Squint vs. plain JS vs. full ClojureScript) is the highest-value next source; (2) the page-weight vs. architecture tension with static-site-wiki remains the central unresolved question and wants a neutral tie-breaker; (3) core-web-vitals duplicated with static-site-wiki — keep consistent. No fixes applied.
[2026-06-01] ingest | Squint — re-seen, refreshed in place
Same GitHub repo (squint-cljs/squint) re-sent via Telegram; already held as squint from
2026-05-31, so refreshed the existing page rather than duplicating (re-seen rule). Added three
details from a fresh fetch: the sibling project cherry (same compile-to-JS approach but
keeps ClojureScript’s persistent collections — the two bracket the bundle-size/semantics
trade), keywords compile to plain strings, and the explicit shallow-copy update
semantics (vs. immutable persistent structures). Bumped updated to 2026-06-01. No synthesis
change — the two-layer minimization frame still holds; cherry just sharpens the trade-off axis.
[2026-06-09] ingest | +3 neutral/authoritative sources — HTTP Archive Web Almanac + performance budgets (daily spoke-expansion loop)
Autonomous daily loop picked this spoke (least-recently-grown: last ingest 2026-06-01, tied with llm-inference-wiki but webperf had fewer pages — 5 vs 7). Added the neutral field-data baseline the 2026-05-29 lint had explicitly asked for (“needs HTTP Archive data”). Three sources, all in-domain and authoritative:
- web-almanac-page-weight-2024 (Report, source, url) — HTTP Archive median page 2,652 KB desktop / 2,311 KB mobile, still growing; breakdown (images 1,054 / JS 613, most-requested / fonts 131 / CSS 78 / HTML 18 KB); only ~70% use text compression; 90th-pctile mobile TBT 5,786 ms. Corroborates landing-page-14kb‘s “~2,600 KB” foil (independent confirmation, not a contradiction).
- web-almanac-third-parties-2024 (Report, source, url) — answers the open question on third-party vs first-party bloat: 92% of pages load third parties (top-1k median 66), mostly scripts (30.5%), Google owns 5 of top-10 domains, median inclusion-chain depth 3.4.
- performance-budgets-101 (TechArticle, source, url) — web.dev primer: quantity/milestone/
rule budgets, <170 KB compressed critical-path default, Lighthouse-CI/bundlesize enforcement.
New concept pages: page-weight (founding concept, finally its own page), third-party-resources,
performance-budget, and a shared web-almanac anchor (Periodical). Updated bundle-size
(613 KB / first-vs-third-party note + budget lever) and core-web-vitals (TBT/compression data +
enforcement link). Folded into synthesis: baseline moved hypothesis→finding; thesis split into a
first-party layer (hand-authoring/bundles/budgets) and a third-party layer (governance);
three nested byte targets (14 KB first-RTT < 170 KB critical-path < 2,652 KB median); third-party
open question marked partly-answered; new open question on why optimization is under-adopted.
Strengthened the cross-wiki page-weight-vs-architecture contradiction with the Almanac’s own
compression/TBT delivery data. No
raw/touched (all url-only). webperf-wiki 5 → 12 pages.
[2026-06-09] ingest | +2 Lighthouse (tool) + AVIF (image lever) — all-spokes cron test
lighthouse (SoftwareApplication, src — Google’s open-source audit tool; LCP/TBT/CLS, 0–100; lab data with the lab-vs-field caveat) and avif (DefinedTerm, src — modern royalty-free image format beating JPEG/WebP on the largest page-weight component). Folded the diagnose-vs-judge and format-choice levers into synthesis. url-only. 12 → 14 pages.
[2026-06-10] ingest | INP + Brotli — all-spokes pass (responsiveness + delivery)
Two new concept/source pages. inp (DefinedTerm, source, web.dev) — Interaction to Next Paint, the newest Core Web Vital, replaced FID March 2024: measures responsiveness across all interactions (good ≤200ms / poor >500ms; phases input-delay→processing→presentation). Sharpens the JS critique (JS as felt main-thread cost, not just load weight) and reframes bundle-size cuts as INP wins; partial answer to the “14 KB floor for interactive apps?” open question (constraint shifts to main-thread execution). Field/CrUX metric → reinforces the lighthouse lab-vs-field caveat. brotli (DefinedTerm, source, MDN/RFC 7932) — Google’s lossless text codec; beats gzip on HTML/CSS/JS (built-in web dictionary; best for cacheable assets, gzip for dynamic). Directly answers the standing “why is compression under-adopted?” open question (~70% text-compression adoption per web-almanac-page-weight-2024) and stakes the delivery side of the page-weight-vs-architecture tension. Folded into synthesis (new 2026-06-10 section) + index. No contradictions — both deepen existing threads. 14 → 16 pages.
[2026-06-12] ingest | Chrome UX Report (CrUX) — developer.chrome.com
All-spokes daily expansion. Added crux (@type Dataset) — the field-data source the wiki repeatedly invoked but never paged. CrUX = real-user Core Web Vitals (LCP/INP/CLS) at p75 / 28-day, the field side of the lab-vs-field split (lighthouse = lab) and Google Search’s actual page-experience signal (core-web-vitals-seo). Captured collection/eligibility (opt-in Chrome, publicly-discoverable
- statistically-significant pages → popular-page sampling bias) and access surfaces (CrUX API, BigQuery, PSI, Search Console). Wired to core-web-vitals (backlink added) / inp / lighthouse / web-almanac; synthesis note “the field-data substrate finally has a page” (end-to-end chain: author bytes → delivery/execution → CrUX → ranking); index gains a Dataset group. 1 new page. Authoritative (Google primary docs). No contradictions.
[2026-06-16] ingest | web-performance (umbrella node) — kind-coverage gap
Added the missing domain umbrella web-performance (DefinedTerm, kind:domain) — flagged by the entity-gaps kind-coverage audit (8 kinded concepts, no domain node). Organizes the byte layers (page-weight/bundle-size/third-party-resources/brotli/avif), the measurement chain (core-web-vitals/inp/lighthouse/crux), and performance-budget under “necessary but not sufficient”; links synthesis. No new sources (synthesis node). +1 page.
[2026-06-18] ingest | GoogleChrome/web-vitals (JS library) — hub-routed
Hub-routed Telegram drop (github.com/GoogleChrome/web-vitals; T1, first-party Chrome repo). Clear
match to the measurement chain; runner-up search-marketing-wiki (CWV is a ranking signal) declined — the
dominant substance is a perf-measurement library, and the SEO angle is already paged here via
core-web-vitals-seo. New page web-vitals (SoftwareApplication, url-only): ~2 KB brotli’d RUM
library, onLCP/onINP/onCLS/onFCP/onTTFB callbacks + thresholds, optional web-vitals/attribution build
(~1.5 KB) for field root-cause, Apache-2.0. Gap closed: it’s the field-instrumentation layer the
wiki assumed but never paged — first-party RUM that matches how Chrome reports to crux/PSI and covers
the long-tail/pre-launch pages CrUX’s popularity threshold omits. Folded into synthesis (Lab vs.
field — added the instrument + the “diagnose in the field” softening of the lab/field split); cross-linked
core-web-vitals and crux. Google Chrome team noted as plain mention per house style (consistent
with crux/lighthouse, no Org node). No contradiction. +1 page.
[2026-06-18] ingest | DefinedTerm enrichment pass (subagent)
Thinnest-first deepening of DefinedTerm pages with new sourced facts. Fetched 4 authoritative
sources (all T1) and created summaries: web-dev-compress-images-avif (web.dev AVIF encoder
guide), mdn-image-types (MDN image-format reference), web-dev-vitals (web.dev Web Vitals
overview), web-dev-third-party-js (web.dev loading third-party JS).
Enriched: avif — added the “>50% vs JPEG” / “50% vs 30% vs WebP” figures, the
beyond-JPEG features (alpha transparency, animation, HDR, film-grain), the no-progressive-render
caveat, and the libaom encode-cost tradeoff (compress-once-serve-many, like brotli).
core-web-vitals — added the p75 rule citation and a Supporting (diagnostic) metrics section
(TTFB/FCP as upstream LCP diagnostics). third-party-resources — added a mitigation section
(async/defer, preconnect, lazy-load, avoid document.write) reading third-party cost through
inp/main-thread. Related added/extended on the above plus web-performance,
bundle-size, page-weight, performance-budget; all updated: 2026-06-18. index.md
updated with the 4 new source pages. No contradictions; no new open questions. +4 pages.
[2026-07-17] ingest | When it makes sense to block the main thread (Smashing Magazine, hub-routed, Telegram)
Ingested Victor Ayomipo’s Smashing Magazine piece arguing the “never block the main thread”
rule should be “never block it for too long.” The spoke’s first source squarely on the execution axis
the synthesis kept pointing at (inp/TBT) without a concept page. New pages: source summary
when-to-block-main-thread (TechArticle, T2, url-only); concept main-thread (16.6ms frame budget /
50ms long-task line; the “executing less” half of web-performance); mechanism web-worker
(shared-nothing → postMessage Structured Clone O(n) copy; transferable objects = zero-copy handoff, ~43×
on 32MB); publisher smashing-magazine (Organization); author victor-ayomipo (Person). Updated
inp (input-delay = busy main thread; +Related links). Synthesis: added the execution-axis paragraph
- the contrarian CPU-bound→offload / data-bound→keep-on-main-thread wrinkle (“less work” now has a
placement dimension, echoing the delivery-side “equal bytes, different executed cost” lesson); new open
question on the offload/keep crossover + chunking (
scheduler.yield). avoid-ai-writing applied. +5 pages, 2 updated. T2 — reputable front-end publication, concrete Chrome benchmarks, engineering argument not a standard.
[2026-08-12] ingest | The Almanac moved on: 2025 page weight (quality cycle)
Found by re-verifying a stale page, not by looking for a source. web-almanac-page-weight-2024 came due under the 60-day freshness window; checking it showed the year selector now offers 2025, published 15 January 2026 from the July 2025 crawl. The spoke’s founding number had been an edition behind for seven months.
web-almanac-page-weight-2025 (T1, Richard Barret and Jamie Indigo; reviewer Dave Smart). Median home page +7.8% year over year — mobile +8.4%, desktop +7.3%, mobile inner pages +9.5% — with the authors reporting the growth accelerating since October 2024. Decade series: median mobile home page 845 KB in July 2015 to about 2.4 MB in July 2025, +202.8%, against +110.2% on desktop. Median mobile composition: images 911 KB, JavaScript 632 KB, fonts 122 KB, CSS 77 KB, HTML 22 KB. Video is the fastest riser at +28% in one year (246 → 315 KB). At the 90th percentile: 1.9 MB of mobile JavaScript, 6.3 MB of images, 1.0 MB of it unused.
A T1 source disagreeing with itself, recorded not resolved. The chapter gives the median mobile home page as 2,362 KB in the decade comparison, as 2.6 MB in the year-over-year sentence, and as 2.56 MB in a third place. 2,362 KB is not the same quantity as 2.56 MB under any unit convention, and the chapter does not say why they differ. Both readings are on the page; page-weight and synthesis now quote the median as a range (~2.4–2.6 MB mobile / ~2.7–2.9 MB desktop) and lean on the growth rate.
What it does to the thesis. The 14 KB provocation’s foil is confirmed by a second independent edition rather than one. The sharper point is the timing: weight grew through a period when core-web-vitals were an established ranking input and inp had already replaced FID, so growth-edge 2 (“why is basic optimization under-adopted”) can no longer be answered with a missing incentive. Written into synthesis and folded into that edge.
Freshness: 8 past window → 2. Five regraded stable — brotli (an MDN glossary definition),
inp (a published metric definition), performance-budgets-101 (dated guidance) and both 2024
Almanac chapters (dated report editions). web-almanac re-verified against the live site and kept
volatile, with the edition list recorded (2025, 2024, 2022, 2021, 2020, 2019 — there is no 2023
edition, which matters when reading a “year over year” figure from the 2024 chapter, since its
comparison year is 2022). crux and lighthouse remain volatile and past window: both track live
products and are owed a real re-read. Carried, not hidden.
[2026-08-12] lint | The volatile queue re-read: Lighthouse has a fifth category, and it is not for humans
Two pages past the 60-day window, both re-fetched from their url:. Both moved, and one of them
matters well beyond this spoke.
lighthouse audits five categories, not four. Performance, Accessibility, Best Practices, SEO —
and Agentic browsing: “a set of deterministic audits” evaluating “how well your site is
constructed for machine interaction.” It checks WebMCP tool registration (declarative and imperative),
WebMCP schema validity, forms missing declarative WebMCP, accessibility-tree quality for machine
navigation, interactive-element naming, role and relationship validity, llms.txt discoverability, and
layout stability via CLS. It does not score 0–100 like the other four; it reports a fraction, which the
docs attribute to agentic web standards still being unsettled.
This was an ingest error, not drift. The category’s documentation is dated 2026-05-05, a month
before this page’s 2026-06-09 ingest. The volatile flag caught a mistake made at ingest rather than
a change in the world, which is the more useful thing for it to have caught and worth remembering the
next time the queue looks like bookkeeping.
Two consequences recorded. CLS is now load-bearing in two arguments — visual stability for a human
reader, and visual stability so a machine can act on the right element — the same measurement serving
two audiences, with no source here on whether the thresholds should match. And the tool this spoke
treats as its performance instrument is now also an AI-readiness instrument, which puts
lighthouse on a seam with ../search-marketing-wiki’s llms-txt and
generative-engine-optimization. Both linked cross-wiki rather than duplicated.
WebMCP is not paged anywhere in this corpus (grepped all spokes). Recorded as a gap. A category description on a tool’s docs page is not enough to define a protocol from, and writing one anyway is what the quality gate forbids. Also added to the page: the Node module as a run surface, and the retired metrics list (Time to Interactive, First Meaningful Paint, First CPU Idle), which is what to check a metric against when it turns up in an older article.
crux gained the eligibility mechanics it had been paraphrasing. “Publicly discoverable” is
concrete — HTTP 200 after redirects, no X-Robots-Tag: noindex, no <meta name="robots" content="noindex">. “Sufficiently popular” is not: “a minimum number of visitors”, threshold
undisclosed. A user contributes only if all three hold — usage-statistic reporting enabled, history
synced, no sync passphrase — and Chrome “does not publish data about the proportions of users that
meet these criteria.”
The Chrome-only caveat got much sharper. The docs name the exclusions: Chrome on iOS, Android WebView, and other Chromium browsers, with Microsoft Edge given as the example. So the field data behind a Google ranking signal omits every iPhone user of Google’s own browser, every in-app browser view on Android, and the second-largest desktop Chromium browser — on top of an undisclosed opt-in rate. The page now states the conclusion plainly: nobody outside Google can size the gap between CrUX and the population it stands in for, which is the strongest argument this wiki has for first-party RUM.
Two access surfaces were missing and are now listed — the CrUX History API and CrUX Vis. One was listed and should not be: Search Console’s Core Web Vitals report is not named on the current overview. And the 75th percentile / 28-day rolling window figures appear on neither cited page; they come from the wider Web Vitals methodology, and the page now says so rather than implying the CrUX docs state them.
Net: 2 pages re-read, both substantially corrected, 0 new pages. Volatile queue now 0 past window.