Ghosts in the Browser: The Legacy Device Support Quietly Draining Your Conversion Rate

Somewhere in your codebase — or your agency's codebase, if you're not hands-on with the technical side — there's probably a comment that reads something like /* IE11 fix */. Maybe a polyfill. Maybe a CSS hack involving filter: progid. Maybe a JavaScript conditional that checks for features that every browser shipped standard about four years ago.

That code is costing you money. Not dramatically. Not in a way that shows up on a single report. But consistently, invisibly, every day.

Who's Actually Visiting Your Website?

Let's start with the data, because this is where most conversations go wrong. Decisions about browser support are often made based on assumptions — "some of our clients use older machines" or "we can't risk losing anyone" — rather than actual analytics.

Pull up your Google Analytics (or equivalent) and look at your browser breakdown for the last 12 months. In the overwhelming majority of UK business websites, you'll find Chrome variants accounting for somewhere between 55% and 70% of sessions. Safari — predominantly mobile — typically sits between 20% and 30%. Firefox takes a few percent. Edge, the modern Chromium-based version, accounts for most of the rest.

Internet Explorer? In most datasets for UK business sites, it's below 0.5%. Often below 0.1%. In some cases, the sessions that do appear as IE11 are actually bots, crawlers, or legacy monitoring tools — not real human visitors at all.

You may be carrying significant technical overhead to serve an audience that essentially doesn't exist.

What Legacy Support Actually Costs in Development Terms

This isn't just a philosophical argument about code tidiness. The practical impact of maintaining legacy browser support affects your development process in concrete ways.

CSS Grid and modern layout techniques require workarounds or complete alternative implementations for IE11. Modern JavaScript features — arrow functions, template literals, async/await — need transpilation via Babel or similar tools, adding build complexity and often bloating output file sizes. Certain image formats like WebP, which deliver significant performance benefits, need fallbacks. CSS custom properties (variables) don't work in IE11 at all.

Each of these workarounds adds time to development, adds complexity to maintenance, and often adds bytes to what gets delivered to every visitor — including the 99.7% using modern browsers who don't need any of it.

The Performance Connection

Here's where it becomes a conversion problem rather than just a technical nuisance. Core Web Vitals — Google's framework for measuring real-world page performance — are directly affected by JavaScript bundle size, render-blocking resources, and CSS complexity. All three tend to worsen when you're building to support environments that require polyfills and transpiled code.

A site that's carrying IE11 support baggage will typically have a larger main JavaScript bundle than one that's been allowed to use modern APIs natively. That larger bundle takes longer to parse, longer to execute, and pushes your Largest Contentful Paint and Total Blocking Time in the wrong direction.

In practical terms, that means slower pages. And slower pages convert worse. The relationship between page load time and conversion rate is well-documented — for e-commerce, each additional second of load time can reduce conversions by anywhere from 4% to 20%, depending on your audience and sector.

What Modern Browsers Actually Support

The good news is that the gap between what you can safely use and what you might be avoiding has never been smaller. As of 2025, the following are supported across all major browsers used by UK audiences without polyfills or workarounds:

• CSS Grid and Flexbox (fully)
• CSS Custom Properties
• WebP and AVIF image formats
• ES2020+ JavaScript features natively
• Intersection Observer API
• CSS Container Queries
• Native lazy loading for images

Dropping IE11 as a support target — which Microsoft itself stopped supporting in 2022 — unlocks access to all of these without compromise. The result is cleaner code, smaller bundles, faster pages, and development teams that aren't spending time on workarounds that serve a phantom audience.

The Practical Audit Process

If you want to actually tackle this rather than just nod along, here's where to start.

First, pull your real browser data. Don't rely on gut feeling or industry averages — your specific audience may genuinely skew older if you serve particular sectors. A site primarily used by local government procurement teams might look different from one serving tech-forward startups.

Second, look at what your current build process is doing. If you're using Babel, check the targets configuration. If you're loading polyfills unconditionally, check whether they're actually needed by anyone visiting the site. Tools like Bundlephobia and Webpack Bundle Analyser can make the overhead visible.

Third, define a support policy and document it. "We support the last two major versions of Chrome, Firefox, Safari, and Edge" is a reasonable, defensible policy for most UK business websites in 2025. It's also a policy that frees your development team to use modern tools without hesitation.

Letting Go of the Ghost

There's a psychological element to this that's worth acknowledging. Dropping support for anything feels like a risk, even when the data suggests the risk is effectively zero. Nobody wants to be the person who decided to stop supporting something and then found out a major client was using it.

But the cost of that caution is real and ongoing. Every sprint that includes IE11 workarounds is a sprint where modern techniques got deprioritised. Every polyfill is weight your real users are carrying unnecessarily.

Your website's ghosts aren't haunting your visitors. They're haunting your development capacity — and your conversion rate is the one paying the price.