Cross-Browser & Viewport Matrices

## The arithmetic, and why it is the whole point Axes of a visual matrix compose multiplicatively. With three engines, four widths, two colour schemes and two device-pixel-ratio settings, one page has 3 x 4 x 2 x 2 = 48 renderings, and 40 pages produce 1,920 baseline images. Adding a fifth width does not add 40 images, it adds 480. This is the single most useful thing to say in the interview, because a candidate who reasons additively will always propose a matrix nobody can operate. ```javascript const axes = { engines: 3, widths: 4, schemes: 2, dpr: 2 }; const perPage = Object.values(axes).reduce((a, b) => a * b, 1); // 48 const total = perPage * 40; // 1920 ``` ## The four real costs **CI wall-clock and machine-minutes.** Every configuration is an actual page load, render and capture — there is no way to derive the Firefox image from the Chromium one. At two seconds per capture, 1,920 images is over an hour of pure capture time before any setup, and it lands on every pull request if the suite is a required check. **Flake surface.** Any element that is not perfectly deterministic now fails in 48 places instead of one. A single unstable region turns one investigation into a wall of red, and the noise-to-signal ratio of the whole suite drops. **Review throughput — the binding constraint.** Visual testing differs from unit testing in that a failure is not automatically a bug: someone must look at the diff and decide whether it was intended. When a designer legitimately changes the header, every baseline containing the header goes red at once. If the header appears on all 40 pages, that is 1,920 images in the approval queue for one intentional change. Humans do not review 1,920 images; they click approve-all. That is the failure mode that makes a large matrix actively worse than a small one — it converts a detector into a rubber stamp, and a real regression rides through in the batch. **Baseline churn and ownership.** Baselines are versioned artifacts. Multiply them and you multiply merge conflicts on baseline updates, the size of the repository or object store, the time to regenerate after an infrastructure change, and the number of images that quietly go stale because nobody owns that configuration. ## Yield is not equal across axes Because the axes cost the same multiplicatively, the only sane way to choose is by how many real defects each one has historically caught. - **Viewport width** is usually the highest-yield axis: layout branches genuinely differ, and the bugs are structural. - **Colour scheme** is often high-yield in practice, because dark-mode values are hand-maintained per token; a hardcoded colour or a missing dark value produces an unreadable component that no width or engine axis would reveal. - **Browser engine** yields real but rarer defects, and only for genuinely distinct engines — two brands sharing an engine produce near-duplicate images. - **Device pixel ratio** is usually the weakest. It mostly affects which asset a responsive image source set picks and how sub-pixel rendering resolves; it rarely changes layout, and it is a common source of diff noise rather than diff signal. ## Shaping the matrix instead of taking its product The matrix does not have to be a full Cartesian product, and mature suites are not. Two techniques do most of the work. First, **tiering**: run the full matrix over a small set of representative screens or components chosen because between them they exercise every layout branch, and run a single reference configuration over everything else. Second, **axis pinning**: pick one configuration as canonical and vary only one axis away from it at a time, so cost grows with the sum of axis sizes rather than their product — 3 + 4 + 2 + 2 configurations instead of 48. You lose interaction coverage (dark mode at the narrow width in WebKit specifically), which is a real but usually small class of defects. ## What a strong answer sounds like Do the multiplication out loud, name human review as the binding constraint rather than storage, and then say what you would actually cut and why. "I would keep width and colour scheme at full breadth on a tiered set of pages, keep one baseline per distinct engine, and drop the device-pixel-ratio axis unless we have shipped a bug it would have caught" is the answer an interviewer is listening for.