In a visual regression suite for a responsive page, why does a single baseline screenshot captured at 1440px width miss real regressions, and what does adding one narrow viewport buy you?
answer
- one screenshot, one rendering
- the CSS has branches
- the narrow branch never rendered
- widest layout is the least constrained
- overflow shows up at 320 first
basics
~20 sA responsive page is several layouts, and a 1440px baseline only ever renders the widest one. A narrow viewport captures the stacked branch — collapsed navigation, wrapped grids, elements hidden or shown by width — which the desktop screenshot never puts on screen at all.
solid answer
~40 sA screenshot records exactly one rendering: one width, one height, one browser. A responsive page, though, is written as several layout branches selected by width — media queries, flex wrapping, grid auto-placement — and only the branch that is live at 1440px ends up in that image. Every rule that applies below the first breakpoint is untested, so a navigation drawer that overlaps its content, a card grid that leaves an orphan column, or a fixed-width table that causes horizontal overflow can all ship green. Adding one narrow viewport, typically near the narrowest width you support, exercises the tightest constraint on the layout — the place where text wraps, truncates or overflows first. It roughly doubles the baseline count, which is why two widths is the honest starting point rather than ten.
go deeper
Be ready to say plainly that a screenshot captures one width only, and that responsive CSS renders a different layout below a breakpoint that the desktop baseline never shows.
Explain which branches are selected implicitly rather than by media query — flex wrapping, grid auto-placement, text truncation — and why the narrowest supported width has the highest yield of any second configuration.
Show that you weigh the second viewport against its recurring cost: every added width doubles the images a human approves on the next intentional redesign, so justify it by the defect class it catches.
Frame viewport count as a budget decision shared across teams: fix the supported widths once at the design-system level so every suite captures the same set, and make adding one require evidence of a bug it would have caught.
## What a viewport baseline actually records A visual regression test renders a page or component, takes a screenshot, and compares that image to a stored baseline. The important thing about the artifact is how narrow it is: it is a record of one rendering under one set of conditions — one viewport width, one viewport height, one browser engine, one colour scheme. Anything the page could have looked like under other conditions is not in the file, and therefore cannot be diffed. Visual coverage is not "the page is covered"; it is "this configuration of the page is covered". ## A responsive page is several layouts, not one Responsive CSS is a set of alternative layouts selected at render time. Some of the selection is explicit: ```css .nav-links { display: flex; } @media (max-width: 639px) { .nav-links { display: none; } .nav-toggle { display: block; } } ``` At 1440px the first branch is live and the second one never executes, so no screenshot in the suite has ever contained `.nav-toggle`. Other selection is implicit and even easier to forget: flex items wrap only when the line runs out of room, `grid-template-columns: repeat(auto-fill, minmax(240px, 1fr))` produces a different column count at every width, long words break only when the container is tight, and `position: sticky` elements interact with content differently once the page is taller than it is wide. None of those branches are opt-in; they simply do not happen at 1440px. ## What the narrow viewport actually catches The defect classes that only appear at small widths are consistent across products: - Navigation that collapses into a menu or drawer and then overlaps, mis-aligns, or fails to cover the content behind it. - Multi-column grids that reflow to one column and leave an orphaned last item, or that keep a minimum column width and force horizontal overflow. - Text that fits comfortably in a wide button or table cell and truncates, wraps to two lines, or spills at a narrow one — the single most common visual regression in a component library. - A fixed-width element (a table, an embedded iframe, an image without `max-width: 100%`) that makes the whole document scroll sideways. - Elements that are `display: none` in one branch and visible in another, where only one of the two states was ever reviewed. Because these are structural rather than cosmetic, they are also the regressions users notice most, which is why the narrow viewport usually has the highest defect yield of any second configuration you can add. ## Choosing the second width The useful second width is not a device name but a constraint. The narrowest width you claim to support — commonly somewhere in the 320px to 375px range — is the tightest box the layout must survive, so it is where overflow and truncation surface first. Choosing widths that relate to the breakpoints your design system already declares is what turns a second screenshot into deliberate coverage rather than a lucky sample. ## Viewport height and full-page capture Width gets the attention, but the capture height matters too. If the tool screenshots only the visible viewport, the height decides what is above the fold and how sticky or fixed elements compose with the content underneath. If it captures the full page by scrolling and stitching, the image includes content that a viewport-sized shot would miss, and it also changes the behaviour of anything that reacts to scrolling or to being scrolled into view. Fix both dimensions explicitly rather than letting a default decide, because a height change moves every pixel below it and produces a diff that has nothing to do with your code. ## What a second viewport does not buy It does not give you browser coverage — the same engine renders both widths, so an engine-specific difference is invisible in both images. It does not give you theme coverage. And it is not free: each viewport multiplies the number of baselines, the CI time, and above all the number of images a human has to approve the next time someone intentionally changes the header. That trade is the reason the matrix is chosen deliberately rather than expanded by reflex.
- If you could only afford one extra viewport, would you add a narrower one or a wider one?Narrower, in almost every case. Small widths are where the layout is most constrained, so wrapping, truncation and overflow bugs appear there first, and they are the ones users hit. A wider viewport usually renders the same branch as your desktop baseline with more whitespace, so its defect yield is low — unless the layout has no max-width and genuinely keeps stretching.
- Does capturing at a narrow viewport width give you the same coverage as testing on a real phone?No. A narrow viewport reproduces the layout branch, not the device: touch input, the mobile browser's dynamic toolbar changing the visible height, platform form-control rendering and real device pixel ratios are all absent. It is the cheap 80% — it catches layout regressions, not platform ones — and knowing which of the two a bug belongs to is the point of splitting the matrix by axis.
saying these in an interview costs you the question
- Assumes a desktop baseline covers mobile because the CSS is shared
- Says browser zoom is equivalent to capturing a second viewport
- Adds one viewport per device model rather than per layout branch
- Treats mobile-first authoring as proof the small layout works
- Leaves viewport height to the tool default and then blames flakiness