How to waste bandwidth, battery power, and annoy sysadmins

Original Article ↗ Hacker News Discussion ↗

A bug in Firefox for iOS is causing the browser to repeatedly request favicons and feeds, sometimes thousands of times, overloading small sites with redundant traffic and exposing weaknesses in how 404s and other errors are cached. Commenters debate whether such bandwidth waste is trivial or symptomatic of a broader culture of sloppy client behavior that pushes costs onto servers and users on limited connections, and they explore workarounds like CDNs, better cache headers, and blocking bot-like traffic. The thread also branches into broader critiques and defenses of Firefox on mobile, touching on iOS’s WebKit engine mandate, Android performance, ad blocking, and Mozilla’s product decisions.

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).