Performance audit — 2026-09-16/17#

Starting point: HEAD 808262d ("Load pastes.js and dashboard.js on demand…"), branch seadragon, clean worktree. Everything below was measured, not estimated; where a number could not be measured it says so.

How it was measured#

Profiles: desktop 1366×900 unthrottled; phone 412×900, 4× CPU, 1.6 Mbps/150 ms; phone-cpu 412×900, 4× CPU, network unthrottled.

Caveats that matter:

• Production numbers go through Cloudflare (Brotli). The local A/B runs against a local Node server
  that does not compress, so local transfer sizes are raw bytes; use the relative change.
• Local A/B used the old build (808262d, port 4189, a detached worktree) and the new build (port 4188)
  on the same machine and data; the machine is a shared workstation, so main-thread timings are noisy.
  Only differences that held across repeated runs are claimed.
• Headless Chrome composites in software; frame rates are not reported.
• The new build has not been deployed, so there are no production "after" numbers yet.

Baseline — production, https://openvibe.live/, 3 cold runs (median)#

Results — local A/B, home page, old build vs new build#

Desktop, 7 interleaved runs each#

Phone CPU profile, 9 interleaved runs each (final build, self-hosted icons)#

What did not improve: layout on the home page is dominated by the page's own content (hero, collage, rails) and stayed flat; long-task totals are within noise.

What changed, and why it moved these numbers#

Server#

Deploy#

Measurement 2026-09-26: after the release-client work (roadmap WS-T task 2)#

Shared 1.17 to 1.20 changed release-watch.js, which every page loads after first paint. It gained release notifications (one EventSource), session beats every 5 minutes, the prompted count and client generations, and stayed under its 5 KB brotli budget (4.94 KB). Production https://openvibe.live/, desktop 1366×900 unthrottled, node scripts/perf/measure-page.js https://openvibe.live/ --runs 3 --settle 8000, two runs of three, medians:

The release client adds one request (the EventSource, which excludes itself from idle-network checks) and no measurable paint or blocking cost. The size budgets in npm test (scripts/perf/check-budgets.js) still pass.

Measurement 2026-10-12: the first-paint stylesheet#

A phone-profile sweep of every OpenVibe home page (4x CPU, ~1.6 Mbit/s) put openvibe.live last: first paint 4.9–5.3 s. Every route blocked on all of style.css (468 KB raw, ~97 KB brotli as served), while CDP rule coverage over the public routes (home, content, VODs, clips, moments, arena, chat, search, a channel, a VOD, a clip, pastes) at 412 and 1366 px used 436 of its selectors, 17–18 % of the file.

• scripts/perf/critical-css.js writes those selectors to public/css/critical-selectors.json; server/web/critical-css.js
  builds the subset from the style.css on disk (rules naming a listed selector, :root/html/body/*, each inside
  its @media/@supports/@container, and only the @keyframes they use): 84 KB raw, ~15 KB brotli.
• On those routes the shell links /css/style.core.css?v=… (generated, content-hashed, served before the /css static
  mount) as the blocking stylesheet, and the full style.css right after it with media="print" flipped on load, plus a
  <noscript> copy. Both sit where style.css sat, before the feature stylesheets, so once the full file has arrived the
  cascade is exactly the old one (the subset's rules come earlier and are repeated unchanged). Other routes (dashboard,
  settings, broadcast, admin, …) keep style.css blocking.
• A/B on production pages through a local same-origin proxy (brotli, phone profile): first paint home 2.48 → 1.47 s,
  channel 2.51 → 1.46 s, VOD 2.24 → 1.48 s (LCP 3.8 → 1.5 s); LCP and CLS elsewhere unchanged; the settled pages are
  pixel-identical apart from animations and timestamps.
• Re-run node scripts/perf/critical-css.js after changing a public page's look: a rule it does not list still arrives
  with the full file, just after the first paint. test/critical-css.test.js fails when more than a tenth of the listed
  selectors are no longer in style.css.

Measurement 2026-10-12: layout shift on direct visits#

With the first paint earlier, what moved afterwards showed: on a phone a direct visit to a channel scored CLS 1.31, a clip 0.99, a VOD 0.43 and the home page 0.13 (Chrome's "good" line is 0.1). Each had the same shape: the shell painted placeholder markup, then the data, and then several parts that load on their own, each pushing the page down.

• The right page from the start. The shell marked home active, so a channel visit painted the home page until the
  router swapped. renderRoute now moves active to the route's own section (activePage in server/web/assets.js),
  and app.js starts currentPage from it, so its first showPage() is not a change and does not fade the page in again.
• Channel (_channelReady in app-channel.js): until the data (ch-data) the header's placeholder words
  ("Channel", "0 followers") are outlines; until the first render and, offline, the "Most watched" block and the discover
  board (ch-ready, at most 2.5 s after the data) the tabs are out of the layout and the page keeps a full viewport, so
  the footer never shows and climbs back down.
• VOD and clip (until 2026-10, then OpenVibe.Video's pages; _mediaReady in the removed app-media.js): the same outlines; the AI timeline, the
  activity strip, the source card, the clips and the comments appear together. .vod-player-container keeps a 16:9 box
  (max-height: 70vh, like the video) before the video knows its size; a taller video still grows it.
• Home hero: the countdown line ships as   instead of hidden; the "shipped" line is no longer hidden
  (shipped.js collapsed it, then refilled it) and keeps its 33 px while empty; the stats board's reserved heights now
  include the "Show all" button (256 / 204 / 120 px, phone / tablet / wide).
• The cosmetics modal and the messenger panel are built by scripts whose stylesheets load without blocking; until those
  land the shell's inline style keeps them closed and the messenger toggle in its corner.

Same A/B harness (phone profile, worst of two runs): channel 1.31 → 0.012, clip 0.99 → 0.025, VOD 0.43 → 0.004, home 0.127 → 0.011; at 1366 px channel 0.09 → 0.015, VOD 0.19 → 0.001, home 0.06 → 0.01. First paint unchanged. test/first-paint-stability.test.js holds the pieces in place.

Measurement 2026-10-17: largest paints, the channel page's blocking time, real users#

Phone CPU profile (4× CPU, network unthrottled), production, median of 3:

Server side (host, warm): /api/streams/channel/:username 120–150 → 95–120 ms (clipper names and AI overviews in one query each instead of one per row, #213); /api/vods/:id and /api/clips/:id now run their six lookups in parallel (23–40 ms, #214). Other OpenVibe sites' homes and inner pages: FCP/LCP 0.5–0.9 s, TBT under 210 ms, no overflow at 320 px.

The throttled-network --phone profile still shows the home's first paint at 3.3 s (six render-blocking stylesheets share the 1.6 Mbps link with ~30 deferred scripts). Real-user data (#217) is the arbiter now: compare live_rum_p75{page="home",device="phone"} before restructuring the stylesheets.

Budgets#

npm run perf:budget (scripts/perf/check-budgets.js) fails if the home page's raw HTML, eagerly loaded JS or render-blocking CSS grow past the limits recorded there.

This page is rendered from docs/performance-audit.md in the OpenVibe.Live repository. Found a mistake? Edit it there.