Loki vs Playwright for Screenshot Testing Indian Ecommerce Sites

Short answer: Choose Loki when the visual states you need to protect are represented as Storybook stories. Choose Playwright Test when the screenshot must follow real storefront navigation or interactions, such as opening a product, changing delivery details, adding to cart, and reaching checkout. This is a scope-based recommendation, not a measured winner.

For an Indian ecommerce site, first ask which locales, delivery-area rules, prices, address states, payment options, and browser/device targets the product actually supports. The tool documentation does not define an India-wide test matrix, and neither tool certifies checkout or payment correctness. Use representative, controlled test data for the states that apply to your storefront.

1. What each tool is designed to test

Loki: Storybook-centered visual regression

Loki runs visual regression tests for Storybook stories. Its overview lists Chrome in Docker (recommended), local Chrome, iOS simulator, and Android emulator as targets. The project describes reproducibility across operating systems as a goal; treat that as a project aim rather than proof that every environment renders identically. See the Loki overview.

The natural unit is a component or composed UI state already captured as a story: for example, a product card with an out-of-stock badge, a delivery selector in an error state, or a cart summary with a discount. This works well when your Storybook stories cover the appearance you care about without needing a live storefront journey.

Playwright: screenshots inside browser tests

Playwright Test provides expect(page).toHaveScreenshot() for page screenshots and supports locator screenshots for a particular element. The first run creates a reference image; later runs compare against it. A screenshot assertion can follow page navigation, clicks, form entry, or other browser actions, so it fits visual checks tied to an actual route or journey. See Playwright visual comparisons.

2. Comparison at a glance

Decision	Loki	Playwright Test
Natural test unit	Storybook story or component state	Page or element after browser actions
Reference workflow	Create references, test, inspect diffs, approve intended changes; references can be checked into the repository	First screenshot assertion creates a reference; later runs compare, and snapshots can be updated with the runner
Environment guidance	Docker Chrome is recommended; listed targets also include local Chrome and iOS/Android simulators	Keep baseline creation and comparison in a consistent environment
Journey coverage	Best when stories represent the states sufficiently	Can capture after navigation and interaction through routes
What the docs do not establish	Relative speed, cost, or reliability for your store	Relative speed, cost, or reliability for your store

3. Decide based on your storefront

List the visual states that matter. Include product listing/detail, cart, address or delivery selection, payment selection, and outcome states only if they exist in your product and can be safely represented.
Mark which states are well represented in Storybook. If the component stories are the main contract and do not depend on route navigation, Loki is a direct fit.
Mark which checks require a real journey. If the point is verifying the rendered result after actual routing, query parameters, or user interaction, Playwright is the direct fit.
Choose required targets from your audience and support policy. Do not assume a generic browser, language, or device matrix is an Indian standard. Ask the product team for the supported combinations.
Assign baseline ownership. Decide who reviews diffs, approves intentional design changes, and updates references. Baseline maintenance is part of either workflow.
Run a small representative suite in CI. Record its runtime and review burden in your own environment before expanding coverage; the cited docs provide no cross-tool performance or cost comparison.

Using both can make sense when the scopes differ: Loki for a broad component catalogue and Playwright for a smaller set of end-to-end storefront states. This is an implementation option inferred from the tools’ documented test surfaces, not a claim that the combination is faster or more reliable.

4. Loki setup and runnable workflow

Loki’s getting-started guide documents Node.js 16 or newer. GraphicsMagick is optional for its gm diffing engine; Docker is needed for the Docker Chrome target. Follow the current Loki setup guide for the commands matching your Storybook version and project package manager.

Install and configure Loki for the Storybook version in your project.
Start Storybook in the documented web setup flow.
Create reference images with loki update.
Run loki test to compare current captures to references.
Review the current screenshots and visual diffs, then update references only for intended visual changes.

# Build or start Storybook as your project requires, then create references
npx loki update

# Run visual comparisons
npx loki test

# In CI, require committed references so a missing baseline fails
npx loki test --requireReference

Check references into the repository or use Git LFS if appropriate for the repository’s binary-file policy. The Loki CI guide describes testing a built Storybook and using --requireReference so CI fails when references are absent; see Loki CI. Review the current guide for the exact build and server arguments in your setup.

5. Playwright setup and runnable screenshot tests

Install Playwright Test and the browser binaries for your project using the official installation guide. The example below assumes a test server is already running at http://127.0.0.1:3000 and that the project has a deterministic test product route. The route and selectors are illustrative; replace them with your storefront’s stable test fixtures.

// tests/product-visual.spec.ts
import { test, expect } from '@playwright/test';

test('product page visual state', async ({ page }) => {
  await page.goto('http://127.0.0.1:3000/products/test-item');
  await expect(page.getByRole('heading', { name: 'Test item' })).toBeVisible();
  await expect(page).toHaveScreenshot('product-page.png', {
    fullPage: true,
    animations: 'disabled',
  });
});

test('cart after adding a test product', async ({ page }) => {
  await page.goto('http://127.0.0.1:3000/products/test-item');
  await page.getByRole('button', { name: 'Add to cart' }).click();
  await page.goto('http://127.0.0.1:3000/cart');
  await expect(page.getByRole('heading', { name: 'Your cart' })).toBeVisible();
  await expect(page).toHaveScreenshot('cart-with-test-item.png', {
    fullPage: true,
    animations: 'disabled',
  });
});

Run the test once to create its expected screenshot, then run it again to compare. Review and deliberately approve changes with Playwright’s snapshot update workflow (commonly npx playwright test --update-snapshots). See the snapshot documentation for snapshot naming, location, and update details.

Page versus locator screenshots

Use toHaveScreenshot() on the page when the full rendered route is the evidence you need. Use it on a locator when a stable component or region matters and surrounding content is noisy. Full-page captures can expose content below the fold, but they can also make long pages more sensitive to dynamic sections and layout changes.

Thresholds and screenshot options

Playwright visual assertions support pixel comparison options, including a maximum-different-pixels threshold. Use thresholds to accommodate small known rendering variation, not to conceal unexplained differences. The assertion captures until two consecutive screenshots match before saving the reference, which helps with some transient rendering changes. It does not make changing data, third-party content, fonts, or the host environment deterministic. Consult the visual comparison options for the current API and configuration.

6. Make ecommerce captures representative and stable

Use controlled data. Pin products, inventory, cart contents, discounts, and delivery availability to fixtures or a safe test environment. Avoid screenshots that depend on production stock or changing campaign content.
Represent only supported locales and states. Ask the team which language, price formatting, delivery-area, address, payment, and success/failure states the storefront supports. Add cases for relevant states rather than assuming every site has them.
Keep checkout safe. Use test-mode integrations or mocked outcomes where available. Visual checks do not validate payment-provider correctness, settlement, or order fulfillment.
Wait for meaningful readiness. Assert that the target heading, product price, cart total, or other stable element is visible before capture. Avoid a fixed delay unless the application has a known timing requirement.
Control motion and asynchronous rendering. Disable or finish animations where possible. Loki identifies asynchronous rerendering and animations as flakiness causes; its guide says looping animation, GIF, SVG animation, and React Native animation can need explicit handling. See Loki flakiness guidance.
Freeze external variation. Stub or isolate recommendations, ads, chat, rotating banners, and third-party widgets when they are not the subject of the test.
Keep the rendering environment consistent. Pin browser and operating-system/container versions in CI, and create and compare baselines in that same environment. Playwright warns that host OS, browser version, settings, hardware, power source, and headless mode can affect rendering.

7. Or skip the browser setup

If the task is to capture a URL as an image or PDF rather than maintain an in-repository visual regression suite, ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

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)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie banners are accepted and removed before capture; more than 60 known consent platforms, newsletter popups, and chat widgets can be removed, and each step can be turned off.
Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed. Responses report page verdict and billing status in headers.
An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.
The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

Create a free ScreenshotNeo account for 1,000 screenshots a month with no card.

8. Performance, reliability, and cost

The cited documentation does not establish a runtime, reliability, or total-cost winner between Loki and Playwright for a particular ecommerce site. Measure your own CI suite with its real Storybook size, browser targets, data setup, and diff-review process. A broader journey suite may cover more route behavior but also requires maintaining test setup and fixtures; a story suite’s usefulness depends on how well stories represent the states that matter. These are practical tradeoffs, not published benchmarks.

For either tool, budget for reference storage, CI browser execution, failed-run triage, and intentional baseline review. Loki’s guide recommends checking references into the repository and mentions Git LFS as an option. Playwright’s snapshots also need controlled creation and updates. Keep CI and local environment alignment tight to reduce avoidable diffs.

9. Troubleshooting

Symptom	Likely cause	Fix
Loki reports missing references in CI	Reference images were not generated or committed for the tested stories	Generate and review baselines in the expected environment, commit them or manage them in Git LFS, and keep `--requireReference` enabled in CI.
Loki screenshots vary between runs	Async rerenders, animation, changing data, or external content	Stabilize fixtures and wait for a settled state. Disable or explicitly handle looping CSS, GIF, SVG, or platform-specific animation.
Playwright shows diffs on a machine with no code change	Browser or host rendering environment differs	Use the same browser version and CI image for baseline generation and comparison. Check headless mode, fonts, and environment settings.
Playwright captures an incomplete page	The assertion runs before the relevant UI state is ready, or lazy content has not rendered	Wait for a semantic locator or app-ready condition, then capture; scroll or exercise the behavior needed to load deferred content.
Snapshot changes are too noisy	Dynamic prices, timestamps, rotating content, personalization, or third-party widgets are uncontrolled	Use fixed test data, freeze or mask only known volatile regions using supported assertion options, and isolate third-party content.
A threshold hides a real design regression	The allowed pixel difference is too permissive	Reduce the threshold and investigate the diff. Thresholds should accommodate understood rendering variance, not unknown UI changes.
CI fails because a baseline update was unexpected	A dependency, browser, font, or intentional design change altered rendering	Review the current image and diff, identify the source, then update references only after confirming the change is intended.

10. FAQ

Can Loki test a complete checkout journey?

Loki’s documented focus is Storybook visual regression. If the check depends on navigating the actual storefront flow, Playwright’s browser-test structure is the more direct fit.

Does Playwright replace Storybook visual testing?

It can take screenshots in browser tests, but whether that is a good replacement depends on how you represent component states and how you want to maintain and review baselines.

Which tool is better for Indian ecommerce?

Neither is universally better. Choose by test surface and by your own supported locales, delivery states, browser targets, and checkout requirements; the available tool documentation does not define those market requirements.

Do visual snapshots prove that checkout works?

No. They compare rendered appearance. Validate business rules, payment behavior, and order outcomes with appropriate functional and integration tests as well.

Can a team use both?

Yes, if each covers a distinct scope and the team can maintain the separate baselines and review workflows.