For a while my way of checking a layout was to render it, screenshot it, and look. If nothing jumped out, it was fine. This works right up until the thing wrong with the layout is a few pixels of overlap that your eye reads as "two elements that happen to be close together".
The match centre in my World Cup tracker is dense: a live pitch, stat panels, a commentary feed, a scrolling event spine, all fighting for one screen. One build looked fine in a screenshot. It was not fine. The event spine was sitting 121 pixels on top of the commentary feed. On screen the feed just looked a little short, because the spine was transparent where it crossed the feed, so nothing obviously collided. The DOM knew. My eyes did not.
That was the build where I stopped trusting screenshots and started measuring.
What measuring means
Instead of looking at a picture, I ask the browser for the bounding box of every element I care about: its top, left, width and height in real rendered pixels. Then I check the boxes against each other with arithmetic. Does this box's top land below the previous box's bottom, or does it cross into it? Does any box run past its container's right edge? Two rectangles either overlap or they do not, and that is a comparison a script does perfectly and an eye does badly.
The same build had a second bug the screenshot hid. A team-name banner lived in a box 100 to 108 pixels tall, but its coloured content wanted 113. So a strip of colour bled 6 pixels out of its panel onto the dashboard behind it. Six pixels. You do not see six pixels, you feel that something is faintly off and cannot say why. The measurement said it plainly: content 113, container 108, bleed 6.
The bugs measuring caught
Once I was measuring, the layer of small wrongness under a "looks fine" screenshot turned out to be thick.
A radial bracket that read as balanced was actually rendering 626 pixels wide inside a 1920 pixel canvas, marooned in the middle, its team labels shrunk to 7 and 10 pixels to fit a ring that was too small. On a standings table the column headers were aligned to one edge and their values to the other, so the points column read as empty even though the numbers were right there, pushed away from their label. On a phone at 390 pixels wide, two analytics values, 8.9 and 8.0, sat with no gap and rendered as the string 8.98.0.
None of those are things I would have caught reliably by eye, and I know that because I did not catch them by eye. They came out of comparing boxes.
The traps in measuring
Measuring has its own ways to lie, and it took a few wrong readings to learn them.
Naive rectangles false-positive on scrolled content. An element scrolled out of view still reports a box, so two things that never visually coexist can look like they overlap. The fix is to be clip aware and only count an overlap inside the region actually on screen. SVG text is worse, because a text node's reported box carries roughly two pixels of font padding above and below the real glyphs, so a tiny overlap between two SVG labels is usually that padding and not a collision. Once you know the ruler has a two pixel burr, you stop filing two pixel overlaps as bugs.
Where the bugs hide, and the rule I keep
The bugs cluster in two places: the shortest viewports and the widest ones. Low height is where a one-screen layout runs out of room and elements start stacking into each other. Maximum width is where fluid clamp() fonts hit their upper bound and a heading that fit everywhere else finally wraps. A laptop at a comfortable size shows you none of this.
So the rule I hold every check to now is boring and specific: measure, do not eyeball, and always include a 1920 wide pass and a 2560 wide pass, for geometry and for composition. The wide monitor is not an edge case I get to skip because I do not own the biggest screen my visitors do. A screenshot tells you a layout is roughly right. A ruler tells you whether it is actually right, and the gap between those two is where the embarrassing bugs live.