# Frontend System Design: Build YouTube Watch Page

Source: https://www.techinterview.org/post/3233475335/frontend-system-design-build-youtube-watch-page/
Updated: 2026-07-12 · techinterview.org

"Design YouTube's watch page" is a senior+ frontend system-design prompt that tests how you decompose a heavy, multi-component page. Player, recommendations, comments, end-screen, mini-player, live chat: each is a non-trivial component, and the page has to feel snappy on a mid-range device. This guide covers what interviewers actually probe.

## Components on the page

- Video player (HLS/DASH, ABR, captions, ads)

- Title, description, channel info, like/share

- Recommendations rail (right side)

- Comments section

- Live chat (if a live stream)

- Chapters / Transcript

- Mini-player on scroll

## Loading priorities

Establish what is critical for the user's first impression:

- Player frame and first frame of video — highest priority

- Title and channel

- Recommendations (so the user has options)

- Comments (below the fold; defer)

- Transcript / chapters (defer until requested)

Critical CSS inlined. Player JS prioritized. Comments and recommendations lazy-loaded after the player is interactive.

## The player

- HLS / DASH adaptive streaming; Shaka Player or HLS.js for non-Safari

- Adaptive bitrate algorithm balances buffer health, bandwidth estimate, and screen size

- Ads are inserted via VAST/SSAI; player handles ad pods without a visible break

- Captions (sidecar VTT, multi-language, auto-generated fallback)

- Picture-in-Picture support via the browser API

- Video element timestamps drive everything else (chapter highlight, transcript scroll)

## Recommendations rail

- Server returns ranked thumbnails + metadata

- Render skeletons immediately; swap as data arrives

- Lazy-load thumbnails with Intersection Observer

- Recommendation rotation as user scrolls or watches longer

## Comments

- Lazy-load when scrolled into view

- Cursor-paginated; "Show more replies" pattern

- Sort: top, newest

- Live updates via WebSocket while watching

- (See the standalone comments-thread frontend interview question for the data model)

## Live chat (live streams only)

- WebSocket to chat server

- Auto-scroll if user is at the bottom; pause if scrolled up

- Throttle render to 30fps under heavy chat load (1000+ msg/sec)

- Virtualize the message list

- Super Chat highlights, moderator messages, etc.

## Mini-player

- Activates when user scrolls past the player

- Or when user navigates to a different page (Polymer-era YouTube popularized this)

- Persists video state across route changes (the video keeps playing)

- Implementation: hoist the video element to a portal that survives unmount/mount of the page component

## State management

- Player state (current time, paused, volume, quality) is global, accessible to chapters, transcript, mini-player

- Auth and user data global

- Page-specific data (comments, recommendations) local to the page

- Pattern: small global store (Redux, Zustand, or Context) for cross-cutting state; React Query for server data

## Routing and back/forward

- SPA navigation between videos, but the player should not unmount on every nav (mini-player pattern)

- URL parameters drive state (timestamp, list, autoplay)

- Browser back returns to the previous video, including its scroll position

## Performance

- Critical metric: time-to-first-frame (the user sees something playing)

- Code-split aggressively; comments and live chat are large bundles

- Pre-fetch the next likely video on hover / focus

- Service Worker caches static assets and the player shell

- Minimize CLS — reserve space for thumbnails and ad slots

## Mobile considerations

- Vertical layout: player → title → metadata → recommendations → comments

- Pinch-to-zoom video in fullscreen

- Battery-aware: lower frame rate on background tabs, pause when truly hidden

- Mobile data warning before high-quality stream

## Accessibility

- Player has full keyboard control (Space, Arrow, F, M, C)

- Captions visible and stylable

- Transcript navigable with assistive tech

- Comments form is a labeled `<form>`

## What separates senior from staff

Senior: decomposes the page and discusses lazy loading. Staff: discusses the mini-player as a state-survival problem (portal hoisting), the player-state-as-global pattern, and the live chat throttling under load. Principal candidates touch on the recommendation telemetry feedback loop and the role of the watch page in YouTube's engagement metrics.

## Frequently Asked Questions

### How do I handle ads without breaking the experience?

Server-side ad insertion (SSAI) gives a single continuous stream; client-side (CSAI) inserts ads at boundaries with brief pauses. Most large platforms use SSAI; CSAI is easier to implement.

### What about the autoplay-next-video flow?

End-screen overlay 5 seconds before video ends; countdown to next; user can cancel. Implementation is mostly UI; the next video is pre-fetched.

### How do I avoid jank when the recommendations rail loads?

Reserve the layout area; use skeleton placeholders that match final dimensions. Avoid loading data after the player has settled if you can request in parallel.