How to Reduce Applitools Eyes Visual Test Steps and Costs
Reduce redundant Eyes checkpoints without losing important visual coverage. Learn how match levels, regions, usage, and plan terms affect review effort and cost.
To reduce Applitools Eyes visual test steps, audit calls to eyes.check() and keep the checkpoints that verify distinct application states or meaningful visual risks. Consolidate duplicate checks only when the resulting screenshot still covers the visual outcome you need. To reduce review effort, classify recurring diffs and use the narrowest suitable match level or region. Whether fewer checkpoints lower your bill depends on your account’s usage and contract; check those before estimating savings.
An Eyes checkpoint is a visual validation at an application state: the SDK captures a screenshot and compares it with a baseline. It is distinct from ordinary UI actions such as clicks or typing. Applitools’ overview of visual UI testing describes this model.
1. Inventory checkpoints before changing tests
Find each eyes.check() call, or its equivalent in your SDK, and record the state it captures, the risk it covers, and whether another check already verifies the same appearance.
| Keep the checkpoint when… | Review it when… |
|---|---|
| It captures a distinct state, such as a materially different screen or interaction outcome. | It snapshots the same unchanged state as a nearby checkpoint. |
| It protects an important visual risk that is not covered elsewhere. | A broader screenshot already verifies the same visual outcome. |
| It checks a transition whose final appearance matters. | It adds no distinct visual assertion and no important transition disappears if it is removed. |
This audit is a practical method based on the checkpoint model and Applitools’ guidance to use visual checks for appearance while retaining textual assertions where needed. It is not a universal reduction formula. See the Playwright integration best practices.
2. Consolidate duplicate coverage carefully
- Map every checkpoint to its screen state and the regression risk it protects.
- Mark snapshots of an unchanged state and checks whose visual assertion is already covered by a broader capture.
- For each candidate removal, confirm that a meaningful state, transition, or risk does not disappear.
- After consolidating, compare key-state coverage and escaped visual defects alongside checkpoint volume and diff-review time.
Do not remove a checkpoint just because it is close in the test script to another one. Two nearby checks can represent different states. Conversely, multiple checks can sometimes be unnecessary if one screenshot still verifies the appearance the team needs.
3. Keep visual and functional assertions in their lanes
Use visual checks for appearance. Keep direct textual or functional assertions for dynamic data and behavior that need exact logic checks. The Playwright documentation recommends using eyes.check() for appearance assertions and textual assertions only when necessary; its statement about reducing test code by 80% concerns test code, not checkpoint count or subscription cost.
For dynamic values, localization, or environment differences, select an intentional comparison behavior or a tightly bounded region. Do not weaken the whole page to quiet a small volatile area.
4. Choose the narrowest match level that fits
| Setting | Use it for | Tradeoff |
|---|---|---|
| Strict | Mostly static content on a given browser and operating system; it is the recommended default in the documented settings. | Visual changes remain visible for review. |
| Layout | Checking relative structure when content or styling varies, including some localization or cross-environment cases. | It can miss defects in content or styling that the test does not intend to validate. |
| Ignore Colors | When color-only changes are expected and are not the concern of that check. | Color defects in the checked area can be overlooked. |
| Exact | Pixel-to-pixel comparison when that behavior is specifically required. | It is not recommended for ordinary verification in the cited settings guidance. |
Applitools’ visual settings documentation explains the match levels. A looser comparison can hide defects, so choose based on the failure mode you want to detect.
5. Handle known volatile areas with regions
- Dynamic region: use for predictable content variation that should not cause a mismatch.
- Floating region: use when an element may move within bounded limits.
- Ignore region: suppress visual differences inside a defined area.
Keep regions limited to known volatile content. The important layout and content around them should remain under meaningful scrutiny. See the Applitools dashboard documentation for region behavior.
6. Measure whether the changes helped
Record a baseline before editing the suite, then compare after the change:
- Checkpoint volume over the same test period.
- Time spent reviewing changed diffs.
- Coverage of the key application states identified in the audit.
- Escaped visual defects.
- Account usage against the allowance in your order form.
No universal savings percentage follows from removing a given number of checks. The impact depends on how your account is metered, the workload, and its commercial terms.
7. Check how your account is billed
Applitools’ subscription agreement distinguishes Pages from Checkpoints. It defines a Page as a unique Checkpoint regardless of execution count or browser/device, while each visual validation execution counts as a Checkpoint. It also says separate order forms may have different terms. Therefore, removing redundant executions may affect checkpoint usage, but the invoice impact depends on your contract and actual usage. Review the subscription agreement and ask your account administrator or representative about your order form.
The public Platform Pricing page, accessed in 2026, lists Starter at $667 per month paid annually, with either 100,000 component checkpoints or 1,000 page checkpoints. It gives Professional starting points of 150 active pages or 1,500 components and Enterprise starting points of 350 active pages or 1,500 components. The higher tiers describe unlimited executions, and pricing is customizable. These are public starting figures, not an account-specific quote; recheck the page and your order form before making a spending decision.
Or skip the browser setup
If you need a clean screenshot of a live page without setting up a browser capture flow, ScreenshotNeo is a website screenshot API and MCP server. It is a capture tool, not a replacement for Eyes baseline comparison or a visual regression suite.
cURL:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpPython:
import requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
timeout=90,
)
open("shot.webp", "wb").write(r.content)Node.js:
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);See the ScreenshotNeo API documentation for request options. Cookie banners, popups, and chat widgets are removed before the shot; each step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and the response identifies the page verdict and billing status. Its MCP server offers take_screenshot, get_page_info, and capture_pdf for AI agents. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Sign up for 1,000 free screenshots a month, with no card required.
Troubleshooting
Checkpoint volume did not fall after removing a check
Confirm the SDK call was removed from the executions you are measuring and compare equivalent time windows. A Page allowance and a Checkpoint execution allowance are different measures, and contract terms vary. Check the account usage and order form.
Diff reviews are still noisy
Classify the diffs first: dynamic content, color-only changes, bounded movement, or actual layout/content defects. Then apply the corresponding match level or a narrowly scoped region. Avoid making the entire test less sensitive to fix one volatile area.
A looser match stopped catching a defect
Restore a stricter comparison for the affected assertion or reduce the region where relaxed handling applies. Match settings change what differences the test can detect.
A consolidated checkpoint missed a regression
Restore a checkpoint for the missing state or transition. Consolidation is appropriate only when the retained screenshot still verifies the visual outcome and risk that matter.
The public plan figure does not match the invoice
Use the account’s own order form and usage data. Public plan examples do not expose negotiated terms, and the agreement notes that separate order forms can differ.
FAQ
How do I reduce the number of Applitools Eyes steps?
Audit calls to eyes.check(), map each to a distinct state or risk, and remove or consolidate only duplicate coverage that does not protect a meaningful transition.
Does reducing Eyes checkpoints lower my Applitools bill?
It may reduce checkpoint usage, but the amount depends on your metering, workload, and contract. Confirm the effect using account usage and your order form.
Should I use Layout matching everywhere to reduce review work?
No. Choose a match level based on what the check must catch. Layout comparison can be useful for selected dynamic or cross-environment cases, but applying it indiscriminately can hide content or styling defects.
Does the documented 80% figure mean 80% lower costs?
No. The Playwright best-practices statement is about reducing test code, not subscription costs or checkpoint volume.
