Cross-Browser Support Matrix Workflow
Define the support matrix from analytics reality, automate smoke coverage per tier, and gate new features on the primary tier.
Objective
Right-size cross-browser effort: full automation where users actually are, smoke-level in the tail, and a documented line for what is unsupported.
Environment
- Analytics with browser and OS distribution
- A browser automation grid (Playwright, Sauce, or similar)
- A policy owner for the support statement
Steps
1. Derive tiers from analytics
Group browsers by actual usage: tier one covers the bulk of traffic, tier two the meaningful minority, tier three everything with a published not-supported line.
Expected state: A tier table exists with usage percentages from analytics, not opinion.
2. Automate tier one fully
Run the critical-journey E2E suite across all tier-one browsers on every deploy gate.
Expected state: A tier-one regression blocks deploy in any of its browsers.
3. Smoke the tail
Run a reduced smoke set on tier-two browsers on a nightly cadence, catching gross breakage without paying full suite cost.
Expected state: Tier-two breakage surfaces within a day, not at user reports.
4. Gate new features on tier one only
Define feature parity policy: new features must work on tier one at launch, with tier-two support following explicitly rather than accidentally.
Expected state: The support statement in docs matches the gate policy exactly.
5. Re-tier from data quarterly
Re-evaluate the matrix as usage shifts, promoting or demoting browsers with usage evidence.
Expected state: The matrix tracks current analytics within a quarter.
Expected outcome
A support matrix sized by real usage, with deploy-blocking automation on tier one, nightly smoke on tier two, and a public line below which nothing is promised.
Verification
A tier-one browser regression blocks the deploy pipeline; the published support statement matches the tested reality; quarterly re-tiering happened on schedule.
Support what users have, prove what you claim
Cross-browser effort is unbounded in both directions: testing everywhere is unaffordable, testing nowhere is indefensible. Tiering from analytics, gating on tier one, and publishing the line makes the effort proportional and the claims honest.
matrix from analytics (2026-10):
TIER 1 (deploy gate, full suite):
Chrome/last-2 58%
Safari/last-2 19% (iOS 12% + macOS 7%)
Firefox/last-2 8%
TIER 2 (nightly smoke, 12 scenarios):
Samsung Internet 4%
Edge/last-2 3%
TIER 3 (documented, no automation):
IE11, Opera Mini, Android <8 -> "known issues" page
gate: new features must pass TIER 1 at launch;
TIER 2 support follows within a sprint (explicit)The published line is a product feature
Users on tier-three browsers deserve a clear statement — this may not work — rather than silent breakage and support tickets. The documented line also protects the team from the recurring debate about browsers nobody uses.
Safari is the silent tier-one risk
Usage analytics show mobile Safari at double-digit share while CI often runs Chromium alone. Including tier-one Safari in the deploy gate is usually the single highest-value change this workflow produces, catching date, layout, and storage bugs before iOS users do.