WebP: The WebPage Compression Format

Original Article ↗ Hacker News Discussion ↗

An experimental blog post shows how HTML can be packed into a WebP image and decoded in the browser to outperform gzip, prompting debate over whether such tricks meaningfully improve real‑world page load times. Commenters dig into TCP behavior, latency, and browser optimizations, arguing that small byte savings can be outweighed by extra JavaScript, WebGL requirements, and loss of progressive rendering. The thread broadens into a look at modern web compression—Brotli, Zstandard, WebP, and emerging image formats—alongside concerns about compatibility, accessibility, and the trade‑off between bandwidth savings and client‑side complexity.

Novel use of WebP for HTML compression

  • Many readers find the “HTML inside WebP” trick clever, fun, and reminiscent of demoscene polyglots and self-extracting ZIP/PNG/HTML hacks.
  • Several see it explicitly as an experiment or art project, not something to ship on serious sites.
  • Others note similar prior experiments (e.g., polyglot HTML/ZIP/PNG, using Brotli via fonts) and appreciate the creativity.

Performance, latency, and TCP details

  • Strong pushback on the claim that a ~50 kB saving meaningfully cuts load time on typical connections.
  • Multiple comments stress that latency and TCP congestion windows dominate; for these sizes, fewer bytes often do not reduce round-trips.
  • Decompression and JS execution time, plus blocking of streaming HTML and parallel resource discovery, can offset or outweigh transfer savings.
  • Some note that savings might matter on extremely slow or high-latency links (EDGE, Mars), but not for most users.

Browser compatibility, JS/WebGL, and accessibility

  • The technique breaks on browsers or hardened configs that disable WebGL, canvas, or JS; several report the article cutting off mid-page.
  • Critics argue this violates progressive enhancement and universal accessibility expectations for the web.
  • The author apparently provides a separate no-JS version, but readers still see the main path as fragile.

Alternative compression formats (Brotli, zstd, etc.)

  • Discussion around Brotli vs gzip vs zstd:
    • Brotli offers better compression but slower encoding; good for precompressed static sites.
    • zstd is praised for tooling, portability, and maturity; some want it and Brotli widely supported in browsers.
    • There’s disappointment that Brotli isn’t exposed via browser CompressionStream for general use.

WebP as an image format

  • Some argue WebP is now widely supported across browsers and tools; others still encounter gaps (older Linux viewers, some web apps).
  • One practitioner reports large real-world size savings when switching from JPEG to WebP, with minimal complaints.
  • Others caution that very large WebP vs JPEG savings often come from quality loss, not magical compression.

Fonts, icons, and real-world bloat

  • Several point out the irony of extreme HTML micro-optimizations while shipping large webfonts and icon CSS (hundreds of kB).
  • Broader complaint: many sites waste far more bandwidth on images, fonts, and JS than they save with fine-grained text compression tricks.