Make the public video feed progressively enhanced #1

Merged
waylon merged 1 commit from feat/progressive-feed-mobile-performance into main 2026-10-13 12:34:14 -05:00
Owner

Summary

  • Server-render the newest published video on /, including its poster, native controls, title, author, source link, and ordinary previous/next links. Render a useful empty state when there are no published videos.
  • Render the /boring catalog on the server and hide controls that need JavaScript until enhancement is active.
  • Hydrate the existing feed markup, deduplicate feed records, retain native controls until custom controls are ready, and preserve permalink/history behavior.
  • Prioritize the initial poster and make next-video metadata loading adaptive to buffered playback and connection conditions. Skip speculative preload on Save-Data and slow-2g connections.

Validation

  • just format && just check — passed (58 tests, Ruff, ty, render smoke).
  • Real Chromium with script execution disabled: homepage native video playback, ordinary navigation/source links, /boring server-rendered cards, and mobile width without horizontal overflow.
  • Real Chromium with JavaScript enabled: server markup bootstrap, muted autoplay/custom controls, feed append without duplicate IDs, and video permalink bootstrap.
  • Slow 3G browser experiment: active video began buffering promptly; next-video metadata loaded adaptively and the next item became playable after swipe.
  • Five local mobile Lighthouse runs (same local setup): median values are listed below. These are lab results, not field data.
Metric Supplied report Local median (5 runs)
Performance 96 86
FCP 1.2s 1.215s
LCP 2.1s 2.345s
Speed Index 3.8s 1.675s
TBT 130ms 481ms
CLS 0.001 0.018
Initial transfer 3,462 KiB 296,716 bytes (about 290 KiB)
Media requests Two transfers about 2,320 KiB and 990 KiB 2 requests, 45,862 bytes combined

The supplied report and local CLI runs do not share a verified Lighthouse version, browser, network/cache setup, or server environment, so score and timing comparisons are directional rather than an apples-to-apples benchmark. The very low transferred media bytes reflect the short Lighthouse observation window and should not be read as full-video sizes. Score, TBT, and CLS remain areas for measured follow-up; this change prioritizes meaningful server content and bandwidth efficiency.

Tradeoffs and follow-up

No encoder settings or render pipeline changed, so this adds no video generation CPU cost. On supported connections, the next video may start a small metadata request to improve swipe startup; Save-Data and slow-2g avoid it, and 2g/3g wait for a smaller active buffer before starting. No existing library videos were re-encoded.

A separate follow-up could measure a small critical CSS path and defer creator-studio styles, then trace the Lighthouse main-thread tasks under a production-matched setup. Any encoder change should be separately benchmarked for size, encode time, visual quality, and caption clarity.

Manual browser checklist

  1. Disable JavaScript and load /: confirm poster, native play controls, title/author, source link, previous/next links, and no horizontal overflow.
  2. With JavaScript disabled, open /boring, select a card, and navigate between videos.
  3. Enable JavaScript on /: confirm muted autoplay policy, play/pause and mute controls, vertical swipe, infinite scroll without duplicates, and browser back/forward.
  4. Open a direct /video/{id} link; then simulate a feed request failure and confirm the server-rendered item remains usable.

Release

Merged as f3c7de99d4193cd55858307e64df501adb102584 (PR #1). Published registry.wayl.one/brainrot:f3c7de9-20261013173433. Updated the homelab GitOps chart in commit 2736636d3c00ef9d22b44775571889bb58705702; Argo reports Synced/Healthy, the deployment has 1/1 ready replica, and the public homepage returned the server-rendered video with native controls and catalog link. This repository has no CI workflow; just format && just check is the completed local gate.

## Summary - Server-render the newest published video on `/`, including its poster, native controls, title, author, source link, and ordinary previous/next links. Render a useful empty state when there are no published videos. - Render the `/boring` catalog on the server and hide controls that need JavaScript until enhancement is active. - Hydrate the existing feed markup, deduplicate feed records, retain native controls until custom controls are ready, and preserve permalink/history behavior. - Prioritize the initial poster and make next-video metadata loading adaptive to buffered playback and connection conditions. Skip speculative preload on Save-Data and slow-2g connections. ## Validation - `just format && just check` — passed (58 tests, Ruff, ty, render smoke). - Real Chromium with script execution disabled: homepage native video playback, ordinary navigation/source links, `/boring` server-rendered cards, and mobile width without horizontal overflow. - Real Chromium with JavaScript enabled: server markup bootstrap, muted autoplay/custom controls, feed append without duplicate IDs, and video permalink bootstrap. - Slow 3G browser experiment: active video began buffering promptly; next-video metadata loaded adaptively and the next item became playable after swipe. - Five local mobile Lighthouse runs (same local setup): median values are listed below. These are lab results, not field data. | Metric | Supplied report | Local median (5 runs) | |---|---:|---:| | Performance | 96 | 86 | | FCP | 1.2s | 1.215s | | LCP | 2.1s | 2.345s | | Speed Index | 3.8s | 1.675s | | TBT | 130ms | 481ms | | CLS | 0.001 | 0.018 | | Initial transfer | 3,462 KiB | 296,716 bytes (about 290 KiB) | | Media requests | Two transfers about 2,320 KiB and 990 KiB | 2 requests, 45,862 bytes combined | The supplied report and local CLI runs do not share a verified Lighthouse version, browser, network/cache setup, or server environment, so score and timing comparisons are directional rather than an apples-to-apples benchmark. The very low transferred media bytes reflect the short Lighthouse observation window and should not be read as full-video sizes. Score, TBT, and CLS remain areas for measured follow-up; this change prioritizes meaningful server content and bandwidth efficiency. ## Tradeoffs and follow-up No encoder settings or render pipeline changed, so this adds no video generation CPU cost. On supported connections, the next video may start a small metadata request to improve swipe startup; Save-Data and slow-2g avoid it, and 2g/3g wait for a smaller active buffer before starting. No existing library videos were re-encoded. A separate follow-up could measure a small critical CSS path and defer creator-studio styles, then trace the Lighthouse main-thread tasks under a production-matched setup. Any encoder change should be separately benchmarked for size, encode time, visual quality, and caption clarity. ## Manual browser checklist 1. Disable JavaScript and load `/`: confirm poster, native play controls, title/author, source link, previous/next links, and no horizontal overflow. 2. With JavaScript disabled, open `/boring`, select a card, and navigate between videos. 3. Enable JavaScript on `/`: confirm muted autoplay policy, play/pause and mute controls, vertical swipe, infinite scroll without duplicates, and browser back/forward. 4. Open a direct `/video/{id}` link; then simulate a feed request failure and confirm the server-rendered item remains usable. ## Release Merged as `f3c7de99d4193cd55858307e64df501adb102584` (PR #1). Published `registry.wayl.one/brainrot:f3c7de9-20261013173433`. Updated the homelab GitOps chart in commit `2736636d3c00ef9d22b44775571889bb58705702`; Argo reports Synced/Healthy, the deployment has 1/1 ready replica, and the public homepage returned the server-rendered video with native controls and catalog link. This repository has no CI workflow; `just format && just check` is the completed local gate.
feat: server render the public video feed
Some checks failed
quality / checks (push) Failing after 35s
quality / checks (pull_request) Failing after 30s
280df9fad1
waylon merged commit f3c7de99d4 into main 2026-10-13 12:34:14 -05:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
waylon/brainrot.waylonwalker.com!1
No description provided.