YouTube embeds are heavy and it’s fixable

Original Article ↗ Hacker News Discussion ↗

YouTube’s standard embed code can add around 1.3 MB of JavaScript per video, slowing page loads and multiplying bandwidth use, especially when multiple embeds appear on a page. Commenters explore lighter alternatives such as “lite” embeds, click‑to‑load thumbnails, and even user scripts or self-hosted HTML5 video, weighing trade‑offs in performance, user experience, privacy, and tracking. Many argue that Google’s incentives favor heavy, engagement‑optimised players, so site owners and users increasingly adopt their own technical workarounds rather than waiting for YouTube to improve.

Overall concerns about YouTube embeds

  • Standard YouTube iframes are ~1.3 MB each, and multiple embeds scale linearly because resources aren’t effectively shared between instances.
  • A “lite” web component can reduce this to roughly thumbnail size (~100–150 KB) plus a small JS wrapper, with most of the weight being the image.
  • Cross-site resource caching is now partitioned in major browsers to prevent tracking, so shared caching across different domains largely no longer works.

Proposed technical workarounds

  • “Click-to-load” patterns: show a thumbnail (or simple placeholder) that swaps in the real iframe on click, reducing initial page weight and tracking.
  • Users share uBlock Origin rules, user scripts, and MutationObserver-based scripts to replace iframes with links or thumbnails and only load players on demand.
  • Some forum platforms proxy thumbnails and only load YouTube on click, both for performance and privacy.
  • Content Security Policy can be used to allow only core YouTube/video domains and implicitly block many ad/tracking resources.

Debate on engagement vs performance

  • There’s a claim that lighter official embeds reduced engagement; many find this counterintuitive and suspect missing features or UI differences matter more than raw weight.
  • Some argue YouTube optimizes for click-to-playback latency and global watch time, not host-site performance.
  • Others counter that any delay after an explicit click is acceptable, especially when most visitors never play the video at all.

UX, privacy, and ecosystem critiques

  • Many dislike embedded players: poor mobile UX, distractions, missing watch-later / “open on YouTube” affordances in lite variants, or double-click-to-play issues.
  • Several prefer static images linking to YouTube, external players (e.g., via yt-dlp), or outright replacing embeds with plain links.
  • There is concern about unnecessary tracking: even thumbnails from YouTube can leak user IPs unless proxied.

Alternatives and broader bloat

  • Some advocate self-hosting video with the HTML5 <video> tag; others point out the operational burden: encoding multiple resolutions, adaptive streaming, DRM, and bandwidth/CDN costs.
  • Similar complaints apply to other heavy embeds (GitHub Gist, SoundCloud).
  • A few note that the energy cost of extra megabytes is small per user, but at YouTube’s scale even small inefficiencies can add up.