PERFORMANCE / SELF-MEASURED

This site, measured by its own tooling.

Core Web Vitals, bundle budgets and interaction latency for every route — the same numbers that gate a release here, published including the regressions. These are lab measurements from one machine under simulated throttling, not field data from real visitors; the method section says exactly what that does and does not tell you.

MEASURED
28 Jul 2026
COMMIT
3d147a4+
PROFILE
4× CPU · Slow 4G
SNAPSHOTS
3

Headline metrics

LCP
1284ms
9/9 routes good
good ≤ 2500ms▲ 24msworst: /
CLS
0.025
9/9 routes good
good ≤ 0.1▲ 0worst: /
INP
216ms
7/8 routes good
good ≤ 200ms▲ 16msworst: lang
TBT
96ms
9/9 routes good
good ≤ 200ms▲ 46msworst: /blog

Each headline is the WORST route, not an average — a visitor lands on one page, and a fast average cannot rescue the slow page they landed on. Sparklines track that worst value across snapshots.

01

Per-route measurements

scroll for the full table →

Core Web Vitals and transfer size per route, measured on the production build.
ROUTELCPCLSTBTJSTRANSFERBUDGET USED
/12840.02576395498 / 52096%
/demo/skills-orbit———543645 / 68095%
/demo/solarsystem3js———643745 / 80093%
/music9800.02347307409 / 44093%
/project9240.0009322424 / 46092%
/resource8960.0001321423 / 46092%
/frontend8920.0002299402 / 44091%
/frontend/layout-thrashing———299402 / 44091%
/perfTHIS PAGE9160.0000299401 / 44091%
/tools/image-edit———297399 / 44091%
/blog10520.00096332434 / 48090%
/models8960.0000293395 / 44090%
/changelog———291394 / 44089%
/terminal———273375 / 42089%
/tools9280.0007290393 / 44089%
/tools/typing———308410 / 46089%
/lab———290392 / 44089%

9 of 17 routes carry vitals — the throttled run covers the routes a visitor is most likely to land on, while transfer size is measured for all of them. A dash means that tool did not cover that route.

02

Interaction latency

scroll for the full table →

Scripted interaction scenarios and their latency, split into three phases.
SCENARIOINPp50PHASE BREAKDOWN
Language toggle216104
Theme toggle9688
Artist switch8840
Header dropdown7232
Command palette — open and type4832
Blog search typing4016
Planner controls4016
Typing trainer keystrokes2416
input delayprocessingpresentation
03

Snapshots

  1. 28 Jul 20263d147a4+Public performance dashboard — /perf ships and measures itselfworst LCP 1284 ms▲ 24
  2. 28 Jul 20263d147a4+Core Web Vitals pass — first paint, icons, fontsworst LCP 1260 ms▼ 6592
  3. 28 Jul 20263d147a4Baseline — before the Core Web Vitals passworst LCP 7852 ms
04

Method

TOOLING

Three commands, all in this repo. pnpm vitals drives a real production build in a real browser and reads LCP, FCP, CLS and TBT off the PerformanceObserver. pnpm size sums the encoded bytes a cold, prefetch-blocked first load actually pulls. pnpm inp scripts real interactions and reads the Event Timing API. pnpm perf:snapshot condenses whichever ran into the committed history this page renders.

PROFILE

Vitals and interaction runs use Lighthouse's mobile profile — 4× CPU slowdown, Slow 4G, a 412×823 viewport — because on an unthrottled desktop over localhost nearly everything reports as instant and no defect is visible. Each route gets a fresh browser context so nothing is served from cache. Reported values are the median of several runs.

LAB, NOT FIELD

Everything here is synthetic: one machine, a simulated network, scripted interactions. It is reproducible and it catches regressions before they ship, which field data cannot do. It is not a claim about what any particular visitor experienced — real devices, real networks and real interaction patterns all differ.

WHY PUBLISH IT

A budget you only look at when you remember to is not a budget. These numbers already gate work in this repo, so publishing them costs nothing extra and makes a regression awkward to ignore. The history keeps the bad snapshots too — a dashboard that only shows improvements is marketing.