Browser support: stop designing for ghosts

One of the easiest ways to bloat a website is trying to support browsers and devices that are too old to matter.

It sounds sensible at first. Support everything. Exclude nobody. Cover every edge case.

In practice, it often means heavier code, more testing, more bugs, more compromises, and a worse experience for the people who make up most of your audience.

Browser support is not about saying yes to everything. It is about making clear, defensible decisions.

Supporting old browsers has a cost

Every extra browser version you promise to support adds overhead.

That cost shows up in:

• extra CSS fallbacks
• more JavaScript branching
• polyfills and workarounds
• more QA time
• more regression risk
• less freedom to use better platform features

That trade-off is not always worth it.

If 0.3% of your users are on an ancient browser, building the whole front end around them is poor prioritisation. You end up dragging the product backwards for everyone else.

"Supported" needs a definition

Too many projects say they support a browser without defining what that means.

A better model is tiered support.

For example:

• Fully supported: tested, expected to work well
• Functionally supported: core journeys work, experience may be simpler
• Not actively supported: no promise beyond best effort

That is far more honest than pretending every browser gets the same experience.

It also fits how the web should work.

Decide support using evidence

Do not decide browser support based on fear, habit, or one stakeholder mentioning Internet Explorer like it is still haunting the office printer.

Look at:

• your analytics
• your audience
• your critical user journeys
• your budget
• your technical approach

Usage data from sources like Can I Use can help you understand global and regional browser share [2]Source 2 . But your own analytics matter more for your audience.

A public sector service, an internal enterprise tool, and a marketing site should not all have the same support matrix.

Support Browserslist, not browser folklore

This is where Browserslist helps [1]Source 1 .

Browserslist gives you a shared, practical way to define browser targets across tools like Babel, Autoprefixer, PostCSS, ESLint configs, and more.

Instead of vague statements like "support modern browsers", you write a real target list.

For example, version-based:

last 2 Chrome versions
last 2 Firefox versions
last 2 Edge versions
last 2 Safari versions
last 2 iOS versions
last 2 Android versions
not dead

Or usage-based rules:

> 0.5% in GB
not dead
not op_mini all

That is far better than guessing. It also keeps the team aligned. Your CSS tooling, JavaScript transforms, and documentation all point at the same browser policy instead of each part of the stack making different assumptions.

Browserslist is useful, but feature support matters too

Version targeting is only half the story.

Sometimes the better question is not "which browser version is this?" but "does this browser support the thing we need?"

That matters because browser versions do not always tell the whole truth. Support varies by engine, platform, OS version, embedded webview, and enterprise lockdown.

In those cases, feature support is more useful than version support.

Examples include:

• CSS grid or subgrid
• container queries
• :has()
• dialog
• view transitions
• specific JavaScript APIs
• modern image formats
• reduced motion and other user preference media queries

If a feature has good support and a sensible fallback, use it. If it has patchy support and no acceptable fallback, think harder.

That is a better engineering decision than blindly refusing newer features because one old browser might struggle.

Target by feature, not browser, when the feature is the real risk

This is where progressive enhancement and feature detection earn their keep [3]Source 3 [4]Source 4 .

Instead of building for a browser label, build for capability.

Feature detection involves testing whether a browser supports a certain block of code, and running different code depending on whether it does, so the browser can always provide a working experience rather than crashing or erroring [4]Source 4 .

Examples:

• use @supports in CSS [5]Source 5
• check for APIs in JavaScript before using them
• start with solid HTML
• layer enhancements on top
• keep key content and actions working without fragile dependencies

That lets modern browsers get the better experience without blocking older browsers from the core journey.

It also avoids a common trap. Teams often over-support old browser versions when what they really need is a graceful fallback for one or two features.

A support matrix should be small and deliberate

Most sites do not need a bloated browser matrix.

A sensible default is often:

• current evergreen Chrome
• current evergreen Edge
• current evergreen Firefox
• current evergreen Safari
• current iOS Safari
• current Android Chrome

Then define what happens outside that range.

Older browsers do not always need perfect parity. They need access to content and key journeys.

That distinction matters.

Evergreen browsers change the rules

Many mainstream browsers update themselves. That changes the support conversation.

If somebody is on an evergreen browser but several versions behind, there is often a path forward. In those cases, a polite prompt makes sense.

Not a hostile wall. Not a passive-aggressive lecture.

Something simple:

"Your browser is out of date. Updating it should improve security, speed, and reliability."

That is enough.

If the browser is old and updateable, nudge the user forward. Do not drag the entire product backwards to protect an avoidable problem.

What to avoid

A few habits cause trouble fast.

Do not:

• promise support you are not testing
• treat "loads" as the same as "works"
• keep old hacks forever
• hold back the majority for a tiny minority
• make JavaScript a hard dependency for basic content and actions

A practical approach

A sensible browser support policy usually looks like this:

1. Review real analytics.
2. Identify critical journeys.
3. Set a Browserslist target [1]Source 1 .
4. Define support tiers.
5. Build with progressive enhancement [3]Source 3 .
6. Use feature detection where needed [4]Source 4 .
7. Review the policy regularly.

That gives you a support strategy grounded in reality, not superstition.

Summary

Supporting every old browser forever is not thoughtful engineering. It is often avoidance dressed up as caution.

Support should be intentional. Measured. Useful.

Support the browsers your audience uses. Use Browserslist to keep the stack aligned. Think in features where version numbers are too blunt. Build solid fallbacks. Nudge updateable users onto newer browsers when it helps.

That is a cleaner, cheaper, and more responsible way to build for the web.

For more on performance and avoiding bloat, see performance myths: why score chasing fails and Core Web Vitals for business owners. For progressive enhancement in depth, see progressive enhancement and why it still matters. You can also get in touch to discuss your site.