The web browser landscape has consolidated dramatically. Where there were once a dozen rendering engines with meaningful market share, there are now three: Blink (Chrome, Edge, Opera, Brave), WebKit (Safari), and Gecko (Firefox). Blink alone powers over 65% of global web traffic.
This consolidation is often celebrated as progress—fewer engines means fewer compatibility targets, which means cheaper development. But this framing confuses standardization with uniformity, and it carries risks that become visible only at scale.
Conflating standard and implementation. A web standard describes behavior. A browser engine implements that behavior. These are not the same thing. When developers test exclusively against Blink, they are testing against Blink's interpretation of the standard—not the standard itself. Subtle differences in CSS rendering, JavaScript timing, and API behavior can and do diverge between engines. A system that works perfectly in Chrome may exhibit layout shifts in Safari or race conditions in Firefox.
The risk for regulated applications. Government digital services, whether procured through TED in the EU or through SAM.gov in the United States, typically mandate accessibility and cross-browser compatibility. A tender that specifies WCAG 2.1 AA compliance and support for "major browsers" is not asking for Chrome-only development. Yet in practice, many delivered systems are tested against a single engine.
We have audited web applications where Chrome-only assumptions were baked into the architecture: CSS Grid features not supported in older WebKit, JavaScript APIs that Gecko implements differently, and touch event handling that works on Blink's model but fails on Safari's. Fixing these issues after delivery is far more expensive than designing for diversity from the start.
Practical recommendations. Test against all three engine families from the beginning—not as a final QA step, but as part of the development cycle. Use feature detection rather than browser detection. Prefer progressive enhancement over polyfill-everything approaches. And when procuring web development services, specify browser diversity requirements explicitly in the tender, not as an afterthought.
Biodiversity in browsers, like biodiversity in ecosystems, provides resilience. The web is healthier when it has multiple viable rendering engines. The teams building for that web are more effective when they respect that diversity rather than optimize for a single implementation.