How to waste bandwidth, battery power, and annoy sysadmins

Original Article ↗ Hacker News Discussion ↗

Firefox iOS favicon bug and impact

  • Firefox on iOS is reported to fetch favicons excessively (multiple times per tab, and again on tab open/close or tab switcher updates).
  • For some sites, this produced thousands of favicon/feed requests per second, sometimes triggering bans, HTTP 503s, or perceived DoS-like load, especially with WordPress and slow/uncached 404 handling.
  • On iOS the rendering engine is WebKit, but favicon-fetching logic is in Firefox’s own Swift code, not the engine; linked GitHub issues discuss this.
  • Some users note they do not see the issue; others speculate it may depend on version, number of tabs, or site setup.

Favicons, paths, and standards

  • Debate over “path-specific” favicons:
    • Pro: convenient per-folder/per-tool branding; “drop an icon in a folder and it just works.”
    • Con: browsers probing /favicon.ico on every path, including non-HTML resources, is wasteful.
  • Alternatives discussed: explicit <link rel="icon" …> tags, HTTP Link headers, page-specific icons, and better caching.
  • Some argue the implicit favicon lookup is legacy and redundant when explicit links exist.

Caching, 404s, and CDNs

  • One side: favicon requests are tiny and often 404; servers or CDNs can cache them and the overall impact is minor.
  • Other side: repeated 404s and miscoded requests waste bandwidth, battery, and server CPU, especially on metered or high-latency links and small, uncached sites.
  • RFCs say 404s are cacheable by default, but many setups don’t cache them; microcaching (even a few seconds) is suggested.
  • Discussion stresses that both client fixes and better server/CDN configs should be pursued, not treated as either/or.

iOS vs Android browsers and UX

  • On iOS, all browsers use WebKit but can differ in networking, tab management, favicons, extensions, and sync.
  • On Android, browsers can ship their own engines; Firefox is praised for uBlock Origin and privacy, but criticized by others as slow, buggy, or degraded over time (tab handling, bookmarks vs Pocket, about:config access).
  • Subjective performance reports vary widely, with hardware and JS-heavy sites cited as important factors.

Meta-discussion and workarounds

  • Some consider the article exaggerated or unconstructive; others defend targeted criticism as necessary.
  • Suggestions include disabling favicon requests, caching 404s, using WordPress caches/CDNs, and securing other expensive endpoints (e.g., password reset forms).