A New Blog Post Triggered Our Visual Alert: Masking Dynamic Areas

We added a blog article to our site and triggered our own visual monitoring alert. The page was available. The new content was intentional. The screenshot had changed enough for the monitor to flag it.

The comparison was doing its job. Our configuration was asking the wrong question: it treated an editorial update as something we wanted to investigate after a deployment.

Our first instinct was to raise the visual-change threshold. Instead, we added a way to exclude specific dynamic areas. That helped, but it also exposed an important limitation: masking a feed does not stop that feed from pushing the rest of the page down.

Here is how we approached the problem in DeployWatchers, and how to decide between a mask, a different capture area and a new baseline.

A changed screenshot is evidence, not a diagnosis

A visual comparison can tell you that pixels changed. It cannot tell you whether a new article, a missing button or a broken stylesheet caused the difference.

Those changes deserve different responses:

• A new blog card is usually an expected content update.
• A checkout button disappearing is a change worth investigating.
• A different cookie banner may reflect consent state rather than a release.
• A web font failing to load can change text wrapping throughout the page.

In our case, the article block was expected to change independently of application releases. Including every headline and thumbnail in every comparison added noise to a check intended to catch unexpected visual regressions.

That does not make every alert caused by new content a false alarm. A longer headline can genuinely break a card. The question is which parts of that behavior the comparison should cover.

Why raising the percentage is a blunt fix

A higher threshold can suppress expected changes. It can also suppress a smaller regression somewhere more important.

Consider an illustrative example, not measurements from our incident: a new set of article thumbnails changes 2% of a screenshot, while a missing navigation control changes 0.3%. Raising the threshold above 2% might quiet both.

Percentages also depend on the comparison area. A small change can look insignificant across a long page but substantial within one section.

DeployWatchers evaluates the larger of the whole-image percentage and the worst section percentage, using sections up to 900 pixels tall. This helps prevent unchanged content on a long page from diluting a localized change. It also means you should inspect the section score before assuming an alert is inconsistent with the overall score.

Use the percentage as a sensitivity setting after deciding what belongs in the comparison. It is not a substitute for choosing that scope.

Mark the content that is expected to change

We added a dedicated attribute to the article grid:

<section aria-labelledby="latest-articles-title">
  <h2 id="latest-articles-title">Latest articles</h2>

  <div class="article-grid" data-visual-ignore>
    <!-- Article cards rendered by the application -->
  </div>
</section>

The attribute has no special browser behavior. It is simply a stable hook that communicates our intent. In DeployWatchers, we then add this selector in website settings under Ignore dynamic areas (CSS selectors):

[data-visual-ignore]

Adding the attribute alone does not activate the exclusion. The selector must be configured for the monitored website.

A dedicated attribute is easier to maintain than a selector built from presentation classes. If the grid changes from three columns to four, the monitoring rule should not silently stop matching because a CSS utility changed.

Scope the hook narrowly. In this example, the heading stays outside the mask. We still want to notice if that heading disappears or moves unexpectedly.

A mask preserves layout; it does not remove the element

During capture, DeployWatchers covers matching elements with an opaque pale-indigo area. The underlying elements remain in the document and keep their dimensions.

That distinction matters:

Change	What masking can do
Headline or thumbnail changes inside an unchanged card grid	Hide the content difference inside the masked area
Article grid becomes taller	The mask becomes taller; the comparison can still detect it
A new row pushes the next section downward	The surrounding layout change remains visible
A button outside the article grid disappears	The mask does not hide that regression

Do not replace masking with display: none just to make screenshots match. Removing the block changes the layout you are trying to observe. You could end up comparing a simplified page that visitors never see.

Playwright also provides screenshot masking, with a configurable mask color. That is a useful general technique; the behavior and safeguards described here are specific to our implementation. See the Playwright screenshot assertion reference ↗ (opens in a new tab).

If the feed grows, choose what you actually want to cover

Suppose the homepage shows three recent articles. Publishing another article replaces one card, but the grid keeps the same size. A mask is a good fit if you do not need to review the contents of those cards.

Now suppose the homepage lists every published article. Publishing another one adds a row. Even with the feed masked, the page gets taller and the footer moves. A pixel comparison can legitimately report that difference.

There are three reasonable options:

1. Keep a bounded homepage feed. Show a fixed number of recent articles and link to the archive. This can make the page more predictable, although long headlines and image sizing still need attention.
2. Compare only the first screen. Use this when the hero and navigation are your priority and the changing feed is below them. Accept that regressions below the capture area will not be checked.
3. Keep full-page coverage and review structural changes. If the feed's height and its effect on surrounding sections matter, an alert may be useful even when the content update was intentional.

Do not give a feed a fixed height solely to silence a monitor if that would clip content or damage the mobile layout. The site's behavior comes first; the comparison should reflect the coverage you need.

For a broader discussion of capture scope, see our guide to visual monitoring baselines and full-page comparisons.

Changing exclusions requires a new baseline

An unmasked reference image and a masked current image are not comparable under the same rules. The newly painted mask would itself look like a large change.

In DeployWatchers, changing the configured selector list requires a fresh capture and explicit baseline approval. The same applies when removing an exclusion. Reordering the same selectors does not change the effective configuration.

A practical sequence is:

1. Review the existing difference and confirm which content is expected to vary.
2. Add a narrowly scoped selector in website settings.
3. Run another visual check.
4. Inspect the new screenshot and verify that the mask covers the intended area.
5. Approve that screenshot as the new baseline only after checking the visible layout.

Until a compatible baseline is approved, the check is inconclusive. Changing the setting does not itself open or resolve an incident.

Changing only the percentage threshold is different: it changes the evaluation rule without changing the captured image, so it does not require a replacement baseline.

Test that the monitor still catches a real problem

A quiet comparison is not enough. An overly broad exclusion can produce reassuring results while hiding the exact regression you wanted to detect.

We checked the masking behavior with local Chromium fixtures and no external requests. The tests cover these distinctions:

• Dynamic content inside a masked region can change without producing a difference when its geometry stays the same.
• A change outside that region remains detectable.
• Height changes remain detectable even when the affected content is masked.
• Invalid selectors do not produce an approvable screenshot.
• A selector with no matches is reported rather than treated as proof that the intended block was excluded.

For your own page, try an intentional content update and a deliberate layout regression in staging. For example, change an article title, then separately remove a navigation control. The first should behave according to your chosen exclusion; the second should remain visible to the comparison.

Keep capture conditions consistent as well. Browser and operating-system differences can affect rendering, as the Playwright visual comparison guide ↗ (opens in a new tab) explains. A mask does not fix a font-loading failure or an inconsistent viewport.

Keep the exclusions small and reviewable

Avoid selectors such as main, body or a shared .container. They can hide most of the page, including navigation, forms and purchase controls.

Other practical limits matter too:

• Cookie banners: masking does not dismiss them. A banner can still cover content or change page geometry. Use a deliberate consent state in your own test environment.
• Optional elements: a zero-match selector may be normal when a banner is absent. If a permanent article grid stops matching, investigate the selector.
• Embedded content: DeployWatchers resolves these selectors in the main document. It does not directly select descendants inside iframes or shadow roots; masking their container also hides the visual behavior of that whole container.
• Invalid CSS: correct the selector rather than approving around a failed capture.

Treat exclusions as part of the monitoring configuration you review after a redesign, not as a one-time way to silence alerts.

The lesson from our article update

We did not need the monitor to decide whether a new blog post was good or bad. We needed to distinguish content that changes routinely from layout that should remain stable.

For our article block, a dedicated selector made that distinction explicit. The useful boundary was not “ignore all changes smaller than a bigger percentage.” It was “exclude these changing card contents, while continuing to observe the surrounding page.”

If you use DeployWatchers, open the website's visual monitoring settings, configure the dynamic-area selectors and review a fresh baseline. Visual monitoring is available on Pro and Agency. Keep important controls outside your masks, and check at least one deliberate regression before trusting a quieter result.