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.