How to Test Indian Mobile Network Layouts with Playwright Screenshots

Use Playwright device presets or explicit browser context settings to capture repeatable mobile screenshots at the viewport sizes and browser projects that matter to your product. Then validate high-value flows on actual Android devices when possible. Playwright’s offline mode is useful for checking offline failure states; it does not establish Indian carrier speed, latency, coverage, or radio behavior.

There is no defensible universal “Indian mobile test matrix” in the sources available for this guide. Choose devices, browsers, and network profiles from your own India-specific audience and support data, and document the reason for each choice.

1. Choose a test matrix from your audience

Start with the product decisions the screenshots need to support. A focused matrix is easier to maintain and gives clearer visual comparisons than testing every possible combination.

List pages and UI states: include the initial page, navigation menu, forms, validation errors, loading and empty states, and any network-dependent content that changes layout.
Identify supported browsers and engines: select the browser projects that your product supports and that your analytics or bug history shows are relevant. Record the versions you run.
Select viewports and orientation: use observed screen dimensions and important responsive breakpoints. Include landscape only when your users or flows make it relevant.
Set device scale factor: choose values that reflect your coverage needs and keep them consistent between baseline and candidate screenshots.
Explain each selection: tie a device or viewport to first-party analytics, support reports, or a specific product obligation. A Playwright preset is a convenient browser configuration, not evidence that the device represents India.

Do not infer a national device, browser, carrier, or network profile from a generic device preset. If you quote external market or telecom data, cite its original publisher, geography, and year. The research available for this article does not establish a current Indian handset or browser shortlist, carrier performance figure, or standard network test profile.

2. Set up Playwright for repeatable mobile screenshots

Playwright’s emulation settings let you use device descriptors or override context properties such as viewport, device scale factor, user agent, screen size, and touch behavior. Keep these settings and the point at which you capture the page stable across runs. See the official Playwright emulation guide.

The following example uses Playwright Test and a named project. Install the test runner and its browser binaries with the official setup instructions for your environment, then save the configuration and test as shown.

// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  projects: [
    {
      name: 'mobile-chromium',
      use: {
        ...devices['Pixel 7'],
        // Override these with dimensions selected from your own audience data.
        viewport: { width: 390, height: 844 },
        deviceScaleFactor: 1,
        locale: 'en-IN',
        timezoneId: 'Asia/Kolkata',
        colorScheme: 'light',
      },
    },
  ],
});

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

test('mobile landing page layout', async ({ page }) => {
  await page.goto('https://example.com', { waitUntil: 'networkidle' });
  await expect(page.getByRole('main')).toBeVisible();
  await page.screenshot({
    path: 'artifacts/mobile-landing.png',
    fullPage: true,
  });
});

Replace https://example.com with a page you are authorized to test. For a real project, prefer an explicit readiness condition for the UI you are capturing over assuming that all pages become visually stable at the same network-idle point. Network activity such as analytics or long polling can make a generic idle condition unsuitable.

For a single script without the test runner, use Playwright’s browser and context APIs directly:

// mobile-shot.mjs
import { chromium, devices } from 'playwright';

const browser = await chromium.launch();
const context = await browser.newContext({
  ...devices['Pixel 7'],
  viewport: { width: 390, height: 844 },
  deviceScaleFactor: 1,
  locale: 'en-IN',
  timezoneId: 'Asia/Kolkata',
  colorScheme: 'light',
});
const page = await context.newPage();
await page.goto('https://example.com', { waitUntil: 'networkidle' });
await page.screenshot({ path: 'mobile.png', fullPage: true });
await browser.close();

Use a real page and adjust its readiness check before relying on the screenshot in a build pipeline. If you want the test to fail when the page is not ready, assert the relevant heading, landmark, or application state before taking the shot.

3. Configure context settings that affect the layout

Choose only settings that can change a user-visible result. Every additional combination adds runtime and review work.

Setting	What it can help check	How to use it well
Device preset	A bundle of device-like browser context values	Use it as a convenient starting point, then override properties when your target dimensions or density differ.
Viewport and screen size	Responsive breakpoints, wrapping, clipping, and viewport-sensitive behavior	Record the exact dimensions. Test orientation changes as separate cases when they matter.
Device scale factor	Raster density and pixel output	Keep it fixed for visual comparisons; do not mistake a different raster scale for a CSS layout regression.
User agent and touch	Sites that branch on browser identity or touch capability	Use values appropriate to the browser project. These overrides do not turn a desktop browser into the full hardware and software environment of a phone.
Locale and timezone	Localized labels, date or time rendering, and locale-specific flows	Set a locale such as `en-IN` and `Asia/Kolkata` for relevant cases; add other locales only when users need them.
Color scheme	Light and dark theme layout differences	Capture separate states if the interface supports both and the layout or contrast changes.
Offline	Offline fallback, error, or cached-content behavior	Use a separate state test. Offline mode is not a simulated slow mobile carrier connection.

Playwright’s emulation guide documents these browser context options and device overrides. Keep your baseline and candidate runs on the same Playwright version, browser project, viewport, scale factor, locale, timezone, color scheme, and UI checkpoint so the comparison remains meaningful.

4. Capture screenshots at stable UI checkpoints

A screenshot is useful when it represents a known application state. Navigate, wait for a meaningful element, and capture after the interface reaches the state under review. For example:

await page.goto('https://example.com/products', { waitUntil: 'domcontentloaded' });
await page.getByRole('heading', { name: 'Products' }).waitFor();
await page.screenshot({
  path: 'artifacts/products-mobile.png',
  fullPage: true,
});

For an interactive state, drive the same action before each capture:

await page.getByRole('button', { name: 'Open menu' }).click();
await expect(page.getByRole('navigation')).toBeVisible();
await page.screenshot({ path: 'artifacts/menu-open.png', fullPage: true });

Full-page captures are useful for content flow and page-height changes. Viewport-only captures are better for fixed headers, overlays, and what a person initially sees. Choose the mode that matches the question and use it consistently.

Review visual differences rather than treating every changed pixel as a defect. Dynamic content, timestamps, rotating banners, fonts, animation, and third-party widgets can create noise. Stabilize or exclude such content only when doing so preserves the behavior you intend to test.

5. Add real Android checks where they matter

Emulation makes a broad, repeatable matrix practical. A physical Android phone can catch behavior tied to actual hardware, browser builds, operating-system integration, or touch input. Use actual target devices for selected critical flows when your audience data or bug history justifies it.

Playwright’s Android API documentation describes connecting to an Android device and taking screenshots, but marks Android automation as experimental. Confirm current requirements and support details in the Android API documentation before adopting it in a release workflow. Do not treat one connected handset as representative of all Android hardware, Indian users, or Indian carriers.

Make a physical-device run deliberate: name the handset and browser version, record the tested flow, and capture the same user-visible checkpoint as the emulated run. If your project needs a particular carrier or radio condition, define and validate that separately; a connected phone alone does not prove which network conditions the test exercised.

6. Test offline behavior separately from network quality

Playwright offline emulation checks browser behavior when regular network-stack requests cannot complete. The Playwright repository documentation describes this scope for navigations, fetch, XMLHttpRequest, and WebSockets. See the Playwright emulation source.

Offline is useful for answering questions such as: Does the app show a useful error? Does a previously cached view remain usable? Can the user retry? It does not simulate a slow 4G or 5G connection, latency, bandwidth limits, packet loss, coverage, or radio handoffs. The reviewed sources do not establish a particular Indian carrier profile or a standard set of values for such a test.

If you need constrained-network testing, define the target conditions from a valid source or from your own measurements, then use a separately validated network-conditioning setup. State the profile, geography, date, and measurement method in your test documentation. Do not label an arbitrary throttling preset “Indian mobile network” without evidence.

7. Build a practical capture workflow

Choose high-value pages and states. Start with responsive layouts and critical flows, including empty, loading, and error states where relevant.
Build a small named matrix. Give each browser, viewport, orientation, and scale-factor combination a name and a reason based on your own product evidence.
Set stable context values. Keep the Playwright version, device configuration, locale, timezone, color scheme, and browser project fixed for comparisons.
Wait for the same UI checkpoint. Assert the same content or state before capturing each baseline and candidate.
Compare and triage. Inspect differences, separate expected content changes from layout regressions, and investigate clipping, overflow, unreadable controls, and broken responsive behavior.
Run selected physical checks. Use actual Android devices for flows where hardware or browser behavior carries meaningful risk; record precisely what was tested.
Keep network tests distinct. Add offline checks for failure handling. Use an independently validated setup for latency, bandwidth, packet loss, or carrier-specific claims.

8. Performance, reliability, and cost

Screenshot cost is mostly engineering time and CI capacity: each added browser, viewport, state, and page multiplies navigation, rendering, artifact storage, and review work. Begin with the matrix that covers your audience and product obligations, then expand when analytics, support reports, or defects show a gap.

For reliable comparisons, pin the relevant browser and test configuration in your project, avoid capturing during animation or transient loading, and assert a meaningful readiness condition. Keep artifacts for failed or changed captures long enough to diagnose them, while controlling storage by retaining only the runs your review process needs.

Full-page screenshots can consume more memory and take longer than viewport captures on long pages. Use full-page output where page flow matters, and viewport captures for fixed or above-the-fold behavior. A physical-device run is more operationally involved than a browser-context screenshot, so reserve it for flows whose evidence is worth the setup.

9. Troubleshooting

Symptom	Likely cause	Fix
Screenshot dimensions or layout differ between runs	Viewport, device scale factor, browser version, or context settings changed	Log and fix the full context configuration; compare matching browser projects and versions.
Screenshot is blank or captures a loading state	The page was captured before the relevant UI became ready, or navigation failed	Wait for a page-specific element or state and assert it is visible before capture. Check navigation errors.
Test hangs while waiting for network idle	Persistent requests, analytics, WebSockets, or polling keep the network active	Wait for a meaningful UI condition instead of global network idleness when appropriate.
Menu or dialog is missing	The test did not perform the action, used a mismatched accessible name, or captured before the transition completed	Use a role-based locator, click the control, and assert the resulting state before taking the screenshot.
Text wraps differently from the real phone	Emulation does not reproduce every font, OS, browser, or hardware detail; fonts may also have loaded late	Check font loading and browser configuration, then verify important issues on the actual target device.
“Offline” test does not resemble slow mobile data	Offline means requests cannot complete; it is not latency or bandwidth throttling	Test offline fallback separately and use a validated network-conditioning setup for defined constrained-network conditions.
Device preset is described as representative of India	A preset only supplies device-like context values; it does not establish market share	Choose profiles from first-party audience or support data and cite current external evidence for any broader claim.
Android automation cannot attach to a device	Device setup, debugging access, browser requirements, or experimental API support may differ	Review current Playwright Android requirements and verify the setup on the actual device before relying on it in CI.

Or skip the browser setup

If you need a clean website screenshot without maintaining browser automation, ScreenshotNeo provides a screenshot API and MCP server. One GET request returns an image or PDF; the API does not emulate an India-specific handset or carrier profile, so keep Playwright or real-device checks for those requirements.

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

See the ScreenshotNeo API documentation for request options. ScreenshotNeo accepts cookie and consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers identify the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.

FAQ

Does a Playwright mobile preset represent an Indian phone market segment?

No. It configures browser context values for emulation. Use your own India-specific audience evidence to decide which devices and viewports to test.

Can I use Playwright screenshots as proof that a page works on every Android phone?

No. Emulation is repeatable coverage, and a physical-device run validates only the device and flow you actually tested.

Does an offline screenshot test check a weak mobile signal?

No. It checks offline behavior. Weak signal, latency, bandwidth, packet loss, and carrier conditions need separately defined and validated network tests.

Should every locale, theme, and viewport be tested together?

Only when the combination represents a user-visible case you need to support. Add combinations based on product evidence rather than multiplying settings without a reason.

Sources

Playwright: Emulation
Playwright Android API documentation mirror (verify current experimental status and requirements before use)
Microsoft Playwright repository: emulation documentation source
TRAI: Network Testing Before Launch of Commercial Services (the referenced page identifies the publication; this article makes no claim about its detailed recommendations)