How Favicon Formats and File Size Affect Your Site’s Load Time

Favicons sit at the bottom of every developer’s performance checklist. They’re small. They seem harmless. But ignore them long enough and you’ll find uncached favicon requests piling up across page loads, adding weight to a resource waterfall you thought was under control. The format you choose matters more than most developers realise, and the difference between a badly configured favicon and an optimised one shows up in your network tab every single time.

The Hidden Request That Bypasses Your Performance Audit

Open your browser’s network panel on any page. Scroll toward the end of the waterfall. There it is: a request for /favicon.ico. Browsers fire this request automatically, even when you never declared a favicon in your HTML. It is baked into browser behaviour and has been for decades.

That single extra request might seem trivial. But it is not just one request. Every new visitor who lands on your site before the favicon is cached triggers a fresh network round trip. On a high-traffic page, those requests accumulate fast. If the server responds with a 404 because no favicon file exists at the root, that failed request still costs time. The browser waits, the server responds, and the response occupies a slot in your waterfall.

What makes this worse is that the default browser behaviour targets /favicon.ico specifically. That is an ICO file. And ICO files, unless you are deliberate about them, tend to be considerably larger than they need to be.

ICO, PNG, and SVG: What Each Format Actually Costs You

The three formats you are most likely to encounter each behave differently in terms of file size, browser support, and compression efficiency. Understanding the tradeoffs helps you make a deliberate choice rather than defaulting to whatever your favicon generator happened to produce.

ICO files are containers, not images. They bundle multiple image resolutions into one file, which sounds efficient but often is not. A naively generated ICO file can embed 16×16, 32×32, and 48×48 pixel versions of your icon all at once. That multi-resolution bundle pushes the file size up considerably compared to a single-size alternative. You can strip an ICO down to just one resolution, but many developers never bother. The result is a 50KB favicon masquerading as a trivial asset.

PNG favicons are cleaner. A single 32×32 PNG with proper compression can arrive well under 2KB. Browsers since Internet Explorer 11 have supported PNG favicons when declared with a <link> tag. The catch is that you must declare it explicitly. Without that link tag, older browsers fall back to requesting /favicon.ico anyway. A PNG alone will not prevent that default request unless you also serve a lean ICO file at the root path.

SVG favicons are the most modern option. An SVG is vector-based, meaning it scales to any resolution without quality loss. For simple, geometric logos, an SVG favicon can be smaller than any equivalent PNG. SVGs also support CSS media queries, which means you can swap the favicon colour for dark mode automatically. The tradeoff is browser support: Firefox and Chrome handle SVG favicons well, but Safari adoption has lagged. Relying on SVG alone leaves some users with a broken icon.

A thorough breakdown of how each format compares across browsers and rendering environments is covered in this favicon formats reference, worth bookmarking before you plan any icon audit.

Format Comparison: File Size, Support, and Caching

Caching Behaviour and Why It Outweighs Format Alone

Format is half the story. Caching is the other half. Browsers do cache favicons, but the duration depends entirely on the HTTP headers your server sends with the response. Without a proper Cache-Control header attached to your favicon file, browsers may re-request the icon on every new session or after very short intervals.

A well-configured favicon should carry a long cache lifetime. A header like Cache-Control: max-age=31536000, immutable tells the browser to hold onto the file for a full year without revalidating it. Pair that with a versioned filename or query string whenever you update your logo, and you get the best of both outcomes: fast repeat visits with no risk of displaying a stale icon.

The practical impact scales quickly. On a site with 50,000 daily visitors, poor caching generates tens of thousands of favicon requests hitting your server every day. Strong caching compresses most of those into a single first-visit request per user. That is a straightforward bandwidth and latency win you can ship in an afternoon, with no risk to anything else on the page.

One more point worth noting: favicons are requested early in the browser’s resource loading process. The browser parses the HTML, sees the favicon link tag, or assumes /favicon.ico, and queues that request alongside other early resources. If your favicon is slow to arrive, it does not block rendering directly, but it does occupy a network connection slot during a period when your page needs those connections for render-critical assets like CSS and fonts.

What Browsers Actually Request and When

Browsers do not always request just one favicon per page load. Depending on which link tags you have declared in your HTML, a single visit can trigger multiple separate icon requests. Here are the ones developers commonly overlook:

• /favicon.ico at the root: Requested automatically by default, even with no link tag present. Serving this file, even as a minimal single-resolution ICO, prevents a wasted 404 response on every first visit.
• apple-touch-icon.png: iOS and iPadOS request this file when a user adds your site to their home screen. The expected size is typically 180×180 pixels. Missing this file generates another 404.
• Web app manifest icons: Progressive Web Apps declare icon paths inside a web manifest file. Browsers fetch these icons on manifest load, adding more requests to the total count.

Each of those is a separate HTTP request with its own round trip, its own cache entry, and its own file size contribution to overall page weight. If you have only thought about the root ICO, you may be leaving several unoptimised icon requests firing on every visit without knowing it. Auditing all icon-related requests in your network panel takes about five minutes and regularly surfaces surprises.

Connecting Favicon Performance to Core Web Vitals

Favicon requests do not directly affect Largest Contentful Paint or Cumulative Layout Shift scores. But they connect to the broader picture of Core Web Vitals in two specific ways that matter to performance-focused developers.

First, every network request competes for bandwidth and available connection slots. On slower connections or mobile networks, a sluggish favicon response can delay the fetching of render-critical CSS or JavaScript. The effect is subtle on fast connections but measurable under constrained conditions, which is exactly when performance improvements matter most to real users.

Second, overall page weight and Time to First Byte are metrics that performance auditors review holistically alongside Core Web Vitals. A 60KB multi-resolution ICO file is extra payload that every first-time visitor must download, even though it sits outside the critical rendering path. When you are working to reduce every kilobyte from your asset bundle, leaving a bloated favicon untouched is an inconsistency in your approach.

What Your Next Performance Audit Should Check for Favicons

Putting this into practice does not require a full site overhaul. A focused favicon audit covers a handful of targeted items and pays back the time invested within a single session. Here is what to check:

• Confirm that /favicon.ico exists at the root and returns a 200 status, not a 404.
• Check the ICO file size in your network panel. Strip it to a single 32×32 resolution if the file bundles multiple sizes you do not need for browser tabs.
• Declare a compressed PNG favicon in your HTML <head> for modern browsers, alongside the root ICO for universal fallback.
• Verify that all favicon files are served with long-duration Cache-Control headers, and version the filenames whenever the icon changes.
• Check for unintentional icon requests such as apple-touch-icon and manifest icons. Confirm those files exist, are correctly sized, and are optimised for file size.

Running this checklist against even a mature production site usually surfaces at least one issue. The fixes are low-risk and non-breaking, which puts favicon optimisation among the safest performance improvements available in your toolkit.

The Performance Line Item That Belongs on Every Audit

No single favicon request will drag your page to a halt. But that is the wrong frame for thinking about load performance. Performance is the accumulated result of dozens of small decisions, and the favicon is one that almost every developer pushes to the back of the queue indefinitely.

Getting it right takes less than an hour. Serve a lean ICO at the root. Declare a compressed PNG for modern browsers. Set a long cache lifetime with immutable headers. Add the touch icon and manifest icons if your site uses them. Then move on, knowing that every returning visitor receives a cached favicon and spends zero extra milliseconds waiting for it to arrive.

The file size reduction from a well-optimised favicon is modest in isolation. The principle behind it is not. Treating every resource, however small, as something worth auditing is exactly the habit that separates a genuinely fast site from one that only looks fast on a strong connection.