Your Site Works in Chrome. Congrats, You've Alienated 15% of Users
Source: Dev.to
Let me guess your testing workflow
- Write code in VS Code
- Open Chrome DevTools
- Check if it works
- Ship it
You just broke Firefox.
And Safari. And probably some Chromium‑based browsers with stricter privacy settings.
“Chrome has 65% market share!” you say.
Cool. So you’re okay with 35% of users having a broken experience? That’s ~1.5 billion people.
The Current State of Browser Testing
I recently ran an informal poll on Twitter:
“How many browsers do you test in before deploying?”
Results (783 votes):
- Chrome only: 47%
- Chrome + Firefox: 28%
- Chrome + Firefox + Safari: 19%
- All major browsers: 6%
Nearly half of developers ship code that’s only tested in Chrome.
“But Chrome is the Standard”
No. Chrome is dominant, not standard.
The standard is the W3C specification and WHATWG living standards.
Chrome just happens to have:
- ✅ The biggest engineering team (Google)
- ✅ The most aggressive feature shipping
- ✅ The loudest developer relations
But “most popular” ≠ “most correct.”
Example: The -webkit- Prefix Era
/* CSS */
.box {
-webkit-border-radius: 10px;
-moz-border-radius: 10px;
border-radius: 10px;
}
Why? Because WebKit (Safari/Chrome) shipped features before they were standardized. Developers tested only in Chrome/Safari, so everyone else had to fake being WebKit to avoid breakage. Mozilla literally added -webkit- prefix support because many sites broke in Firefox. This is what happens when one engine dominates.
Why Firefox Gets Ignored (And Why That’s Dangerous)
Reason #1: Developers Use Chrome
The vicious cycle
- Developers use Chrome for personal browsing
- Developers test only in Chrome
- Sites break in Firefox
- Users switch to Chrome
- Market share drops
- Developers justify ignoring Firefox
Firefox usage among developers is ~10 %, but among general users it’s ~3 %.
Translation: We’re testing in the browser we use, not the browsers our users use.
Reason #2: Chrome DevTools Are Better
Chrome DevTools are more polished, thanks to a large engineering team.
Chrome has:
- Better performance profiler
- Built‑in Lighthouse
- More extensions
Firefox has:
- Superior CSS Grid inspector (seriously, it’s amazing)
- Container queries debugging
- Privacy‑focused network tools
Google has 100+ engineers on DevTools; Mozilla has ~20.
Reason #3: “If it works in Chrome, it works everywhere”
False. Real bugs that only happen in Firefox:
Bug #1: flex-basis: 0 Rendering
/* CSS */
.container {
display: flex;
}
.item {
flex: 1 1 0; /* Works in Chrome */
flex: 1 1 0%; /* Required in Firefox */
}
Chrome accepts 0 without a unit; Firefox requires 0% per spec. Firefox is correct.
Bug #2: Date Input Parsing
// JavaScript
new Date('2025-01-15'); // Works everywhere
new Date('1/15/2025'); // Chrome: OK
// Firefox: Invalid Date
// Safari: OK
Firefox follows the spec strictly; Chrome “helps” by guessing formats.
Bug #3: fetch() with keepalive
// JavaScript
fetch('/api/log', {
method: 'POST',
keepalive: true, // Chrome: always works
// Firefox: only works for POST/GET
body: JSON.stringify(data)
});
Firefox had a bug where keepalive didn’t work with certain HTTP methods, costing hours of debugging.
The Real Cost of Ignoring Firefox
1. Excluding Privacy‑Conscious Users
Firefox users tend to be:
- More tech‑savvy
- More privacy‑conscious
- More likely to use ad blockers
They’re more valuable for B2B SaaS and developer tools.
Case study: At LogWard:
- Chrome: 62%
- Firefox: 21%
- Safari: 14%
- Edge: 3%
Firefox users convert to paid plans at 1.8× the rate of Chrome users.
2. Reinforcing a Monopoly
If Firefox disappears, the browser landscape collapses to Blink‑based browsers:
- Chrome (Google)
- Edge (Microsoft)
- Opera (Chinese)
- Brave (Privacy)
- Vivaldi (Power users)
All share the same engine. When Internet Explorer held 95 % market share, innovation died for five years. We risk the same fate with Chrome.
3. Missing Real Bugs
// JavaScript
const data = await fetch('/api/data').then(r => r.json());
// Works in Chrome
console.log(data?.items?.[0]?.name);
// Breaks in Firefox 85 (optional chaining bug)
A bug in optional chaining caused a blank page for 30 % of users on older Firefox versions. It was caught only because a single user filed a report.
“But I Use Modern JavaScript, Babel Handles This”
Babel transpiles syntax but does not polyfill browser APIs.
Example: structuredClone()
// JavaScript
const cloned = structuredClone(originalObject);
Support
- Chrome 98+: ✅
- Firefox 94+: ✅
- Safari 15.4+: ✅
Without core-js or another polyfill, this API will break in older Firefox versions.
The Safari Problem Is Worse
Testing Safari is hard for Windows/Linux developers:
- Requires a Mac ($1,000+) or a paid service like BrowserStack ($39/mo) or a complex setup with GitHub Codespaces.
Safari holds ~20 % market share (mostly iOS). iOS forces all browsers to use WebKit, so Chrome on iOS is just Safari with a Chrome skin. Ignoring Safari means ignoring:
- All iPhones
- All iPads
- Most Macs
How to Actually Test Cross‑Browser (Without Going Insane)
Step 1: Install Firefox Developer Edition
Download:
Why the Developer Edition?
- Faster release cycle
- Built‑in dev tools
- Container tabs (isolate contexts)
Time cost: ~5 minutes.
Step 2: Set Up a Testing Checklist
Before every deploy:
- [ ] Test in Chrome (your dev browser)
- [ ] Test in Firefox (catch spec violations)
- [ ] Test in Safari (if you have a Mac)
- [ ] Test in Chrome on mobile (responsive)
Time cost: 5–10 minutes per deploy.
Step 3: Use Feature Detection, Not Browser Detection
Bad:
if (navigator.userAgent.includes('Firefox')) {
// Firefox‑specific code
}
Good:
if ('structuredClone' in window) {
const cloned = structuredClone(obj);
} else {
const cloned = JSON.parse(JSON.stringify(obj));
}
Step 4: Use Autoprefixer and PostCSS
npm install autoprefixer postcss
Autoprefixer adds vendor prefixes automatically:
/* You write */
.box {
display: grid;
}
/* It outputs */
.box {
display: -ms-grid;
display: grid;
}