Playwright Mobile Testing 2026: Emulation, Devices & Real-World Guide

Q: How do I emulate an iPhone in Playwright?

Import the devices object from @playwright/test and reference the device by name, such as devices['iPhone 15']. Pass it as the use property in a project inside playwright.config.ts, or spread it into browser.newContext(). This sets the viewport, user agent, deviceScaleFactor, hasTouch, and isMobile flags automatically.

Q: Does Playwright support touch events like swipe and pinch?

Yes. Playwright's page.touchscreen API supports tap and multi-touch gestures. You can simulate swipes by combining touchscreen.touch() to create touch points and then moving them across coordinates. For pinch-to-zoom, create two simultaneous touch points and move them apart or together. The tap() method handles simple touch interactions like tapping buttons and links.

Q: Can I simulate slow 3G network on mobile in Playwright?

Playwright does not have a built-in network throttling API like Chrome DevTools. However, you can simulate slow networks using page.route() to add artificial delays to every request, or by using a proxy server. For Chromium-only projects, you can also use the Chrome DevTools Protocol (CDP) to enable network emulation with specific download and upload speeds, and latency settings.

A button that looks perfectly tappable on desktop might be unreachable on a 375px iPhone screen. A navigation drawer that slides in smoothly on Chrome Desktop might overlap content on a Galaxy S23. A form that validates instantly on a fast connection might time out on a 3G network in a rural area. These are not edge cases — they are the daily reality for over half your users.

Playwright makes mobile testing a first-class citizen. With its built-in device registry, touch event APIs, and viewport controls, you can validate every mobile interaction without maintaining a device farm. This guide covers everything from basic device emulation to advanced touch simulation, mobile CI/CD strategies, and how Claude AI can accelerate the entire workflow.

Why Mobile Testing Matters in 2026

Mobile traffic has crossed the 60% threshold globally, and in many markets — particularly e-commerce, social media, and news — mobile accounts for over 75% of all sessions. Despite this, most QA teams still write tests primarily for desktop viewports and treat mobile as an afterthought.

The Revenue Impact of Mobile Bugs

Google's research consistently shows that 53% of mobile users abandon sites that take longer than 3 seconds to load. But load time is just the beginning. Responsive layout bugs, untappable buttons, overlapping elements, and broken scroll behavior all contribute to mobile bounce rates. For an e-commerce site doing $10 million annually, even a 1% increase in mobile bounce rate can translate to $60,000+ in lost revenue.

Mobile bugs are also harder to reproduce. They depend on specific viewport widths, touch interactions, device pixel ratios, and operating system behaviors that developers rarely encounter on their desktop machines. Without automated mobile testing, these bugs only surface through customer complaints — by which point the damage is done.

What Mobile Testing Covers

Responsive layouts: Do elements reflow correctly at 375px, 390px, 412px, and 768px widths?
Touch interactions: Can users tap buttons, swipe carousels, and pinch-to-zoom without issues?
Mobile navigation: Do hamburger menus, bottom sheets, and slide-out drawers work correctly?
Viewport behavior: Does the virtual keyboard push content up properly? Do fixed headers remain accessible?
Performance on slow connections: Does the site remain functional on 3G or flaky WiFi?
Device-specific quirks: Does iOS Safari handle position: fixed correctly? Does Android Chrome respect viewport-fit=cover?

iOS is WebKit-only: Every browser on iOS — Chrome, Firefox, Edge, Brave — uses the WebKit engine underneath. Testing with Playwright's WebKit browser is the only way to catch Safari/iOS-specific bugs without an actual Apple device.

Playwright's Built-In Device Emulation

Playwright ships a devices registry containing over 100 predefined device profiles. Each profile bundles the viewport dimensions, user agent string, device scale factor, touch support flag, and whether the device identifies as mobile. When you create a browser context with a device profile, Playwright configures all of these properties automatically.

How Emulation Works

Device emulation in Playwright is not a simulator or an emulator in the Android/iOS sense. Instead, it configures a desktop browser engine to behave like a mobile device. The browser window adopts the specified viewport size, sends the device's user agent string with every request, renders at the correct device pixel ratio, and enables touch event support.

This approach has a critical advantage: speed. There's no need to boot a virtual machine, install an OS image, or connect to a physical device. Emulated mobile tests run at the same speed as desktop tests — typically under 2 seconds per test.

Listing Available Devices

List all devices

import { devices } from '@playwright/test';

// Print all available device names
console.log(Object.keys(devices));

// Inspect a specific device profile
console.log(devices['iPhone 15']);
// Output:
// {
//   userAgent: 'Mozilla/5.0 (iPhone; CPU iPhone OS 17_...',
//   viewport: { width: 393, height: 852 },
//   deviceScaleFactor: 3,
//   isMobile: true,
//   hasTouch: true,
//   defaultBrowserType: 'webkit'
// }

Emulation vs Real Devices

Emulation covers the vast majority of mobile testing needs, but it does have limitations. It cannot test native OS features like push notifications, the share sheet, or hardware sensors (accelerometer, camera). It also does not replicate the exact rendering of a specific mobile OS version — iOS 18 Safari and Playwright's WebKit may differ slightly on font rendering or scroll physics.

For 95% of responsive web testing, emulation is sufficient and far more practical than maintaining a device farm. Reserve real-device testing for final validation before major releases, or use a cloud service like BrowserStack or Sauce Labs for specific device-OS combinations.

Pro tip: Playwright's device profiles include landscape variants. Use devices['iPhone 15 landscape'] to test landscape orientation without writing custom viewport configurations.

Configuring Mobile Projects in playwright.config.ts

The most robust way to run mobile tests is through the projects array in your Playwright configuration. Each project defines a device, and Playwright runs your entire test suite against every project. This means one test file automatically validates desktop Chrome, iPhone 15, Pixel 7, and Galaxy S23 — no duplication required.

playwright.config.ts

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

export default defineConfig({
  testDir: './tests',
  fullyParallel: true,
  retries: process.env.CI ? 2 : 0,
  workers: process.env.CI ? 4 : undefined,
  reporter: 'html',

  projects: [
    // Desktop browsers
    {
      name: 'Desktop Chrome',
      use: { ...devices['Desktop Chrome'] },
    },

    // Mobile devices
    {
      name: 'iPhone 15',
      use: { ...devices['iPhone 15'] },
    },
    {
      name: 'iPhone 15 landscape',
      use: { ...devices['iPhone 15 landscape'] },
    },
    {
      name: 'Pixel 7',
      use: { ...devices['Pixel 7'] },
    },
    {
      name: 'Galaxy S23',
      use: {
        userAgent: 'Mozilla/5.0 (Linux; Android 14; SM-S911B) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Mobile Safari/537.36',
        viewport: { width: 360, height: 780 },
        deviceScaleFactor: 3,
        isMobile: true,
        hasTouch: true,
      },
    },
    {
      name: 'iPad Pro 11',
      use: { ...devices['iPad Pro 11'] },
    },
  ],
});

With this configuration, running npx playwright test executes every test file six times — once for each project. To run tests for a single device, filter with the --project flag:

Terminal

# Run tests on iPhone 15 only
npx playwright test --project="iPhone 15"

# Run tests on all mobile devices
npx playwright test --project="iPhone 15" --project="Pixel 7" --project="Galaxy S23"

# Run a specific test file on a specific device
npx playwright test checkout.spec.ts --project="Pixel 7"

Custom devices: When a device is not in Playwright's registry (like the Galaxy S23 above), define the profile manually with userAgent, viewport, deviceScaleFactor, isMobile, and hasTouch. Check the device's specs on the manufacturer's site or cross-browser testing guides for accurate values.

Testing Responsive Layouts

Responsive layout testing goes beyond checking if elements are visible. You need to verify that components reflow correctly at every breakpoint, that text remains readable, that images scale proportionally, and that interactive elements maintain adequate touch targets (at least 44x44px per WCAG 2.5.5).

Viewport Assertions

responsive.spec.ts

import { test, expect, devices } from '@playwright/test';

test.describe('Mobile responsive layout', () => {
  test('navigation collapses to hamburger on mobile', async ({ page }) => {
    await page.goto('https://example.com');

    // Desktop nav links should be hidden on mobile
    await expect(page.locator('.nav-links')).toBeHidden();

    // Hamburger button should be visible
    await expect(page.locator('.nav-toggle')).toBeVisible();

    // Tap hamburger to open menu
    await page.locator('.nav-toggle').tap();
    await expect(page.locator('.nav-links')).toBeVisible();
  });

  test('hero section stacks vertically on mobile', async ({ page }) => {
    await page.goto('https://example.com');

    const hero = page.locator('.hero-content');
    const box = await hero.boundingBox();

    // On mobile, hero should span full width
    const viewport = page.viewportSize();
    expect(box.width).toBeGreaterThan(viewport.width * 0.85);
  });
});

Breakpoint Testing with Multiple Viewports

Instead of relying solely on device projects, you can programmatically test multiple breakpoints within a single test to validate CSS media queries:

breakpoints.spec.ts

import { test, expect } from '@playwright/test';

const breakpoints = [
  { name: 'mobile-sm', width: 320, height: 568 },
  { name: 'mobile',    width: 375, height: 812 },
  { name: 'mobile-lg', width: 412, height: 915 },
  { name: 'tablet',    width: 768, height: 1024 },
  { name: 'desktop',   width: 1280, height: 800 },
];

for (const bp of breakpoints) {
  test(`no horizontal overflow at ${bp.name} (${bp.width}px)`, async ({ page }) => {
    await page.setViewportSize({ width: bp.width, height: bp.height });
    await page.goto('https://example.com');

    // Check that no element overflows the viewport
    const overflowX = await page.evaluate(() => {
      return document.documentElement.scrollWidth > document.documentElement.clientWidth;
    });
    expect(overflowX).toBe(false);
  });
}

Screenshot Comparison Across Viewports

Playwright's built-in visual regression capabilities are particularly powerful for mobile testing. Capture baseline screenshots at each breakpoint and compare them on subsequent runs:

visual-mobile.spec.ts

test('homepage visual regression on iPhone 15', async ({ page }) => {
  await page.goto('https://example.com');
  await page.waitForLoadState('networkidle');

  // Full-page screenshot comparison
  await expect(page).toHaveScreenshot('homepage-iphone15.png', {
    fullPage: true,
    maxDiffPixelRatio: 0.01,
  });
});

Touch Event Simulation

Mobile users interact with your application through touch, not mouse clicks. While Playwright's .click() method works on mobile contexts, true mobile testing requires simulating touch-specific gestures: taps, swipes, long presses, and pinch-to-zoom.

Basic Tap Interactions

touch-basics.spec.ts

test('tap to open mobile menu', async ({ page }) => {
  await page.goto('https://example.com');

  // Use .tap() instead of .click() for touch devices
  await page.locator('button.hamburger').tap();
  await expect(page.locator('.mobile-menu')).toBeVisible();

  // Tap a specific coordinate
  await page.touchscreen.tap(200, 400);
});

Swipe Gestures

Swipe gestures are essential for testing carousels, image galleries, bottom sheets, and pull-to-refresh patterns. Playwright does not have a built-in swipe() method, but you can simulate swipes using the touchscreen API:

swipe-gesture.spec.ts

async function swipe(page, startX, startY, endX, endY, steps = 10) {
  await page.touchscreen.tap(startX, startY);
  await page.mouse.move(startX, startY);
  await page.mouse.down();

  for (let i = 1; i <= steps; i++) {
    const x = startX + (endX - startX) * (i / steps);
    const y = startY + (endY - startY) * (i / steps);
    await page.mouse.move(x, y);
  }
  await page.mouse.up();
}

test('swipe carousel to next slide', async ({ page }) => {
  await page.goto('https://example.com/gallery');

  // Swipe left (start right, end left)
  await swipe(page, 350, 400, 50, 400);

  // Assert second slide is now visible
  await expect(page.locator('[data-slide="2"]')).toBeInViewport();
});

Long Press

long-press.spec.ts

test('long press shows context menu', async ({ page }) => {
  await page.goto('https://example.com/list');

  const item = page.locator('.list-item').first();
  const box = await item.boundingBox();

  // Simulate long press: mouse down, wait, mouse up
  await page.mouse.move(box.x + box.width / 2, box.y + box.height / 2);
  await page.mouse.down();
  await page.waitForTimeout(800); // typical long-press threshold
  await page.mouse.up();

  await expect(page.locator('.context-menu')).toBeVisible();
});

Mobile-Specific Selectors and Interactions

Mobile UIs often contain components that simply do not exist on desktop: hamburger menus, bottom sheets, pull-to-refresh indicators, sticky bottom navigation bars, and full-screen overlays. Testing these requires understanding how they behave in a touch context.

Hamburger Menu Testing

hamburger.spec.ts

test('hamburger menu opens and navigates', async ({ page, isMobile }) => {
  test.skip(!isMobile, 'Hamburger only exists on mobile');

  await page.goto('https://example.com');

  // Open hamburger
  await page.locator('[aria-label="Toggle navigation"]').tap();
  await expect(page.locator('.mobile-nav-overlay')).toBeVisible();

  // Navigate to a section
  await page.locator('.mobile-nav-overlay a[href="#pricing"]').tap();
  await expect(page.locator('#pricing')).toBeInViewport();

  // Menu should auto-close after navigation
  await expect(page.locator('.mobile-nav-overlay')).toBeHidden();
});

Scroll-Into-View for Mobile

Mobile viewports are small, so elements are often below the fold. Playwright's scrollIntoViewIfNeeded handles this automatically, but for custom scroll containers you may need manual scrolling:

scroll-mobile.spec.ts

test('scroll to CTA and tap', async ({ page }) => {
  await page.goto('https://example.com');

  // Scroll the CTA into view
  const cta = page.locator('.cta-section .btn-primary');
  await cta.scrollIntoViewIfNeeded();

  // Verify it's in the viewport
  await expect(cta).toBeInViewport();

  // Verify minimum touch target size (44x44px per WCAG 2.5.5)
  const box = await cta.boundingBox();
  expect(box.width).toBeGreaterThanOrEqual(44);
  expect(box.height).toBeGreaterThanOrEqual(44);

  // Tap the CTA
  await cta.tap();
});

Bottom Sheet and Overlay Testing

bottom-sheet.spec.ts

test('bottom sheet can be dismissed by swiping down', async ({ page }) => {
  await page.goto('https://example.com/product');
  await page.locator('button.show-details').tap();

  const sheet = page.locator('.bottom-sheet');
  await expect(sheet).toBeVisible();

  // Swipe down to dismiss
  const box = await sheet.boundingBox();
  await swipe(page, box.x + box.width / 2, box.y + 20,
    box.x + box.width / 2, box.y + box.height);

  await expect(sheet).toBeHidden();
});

Network Throttling for Mobile

Mobile users frequently experience slow, unreliable network connections. Testing your application under constrained network conditions reveals issues that never appear on a fast wired connection: images that never load, API calls that time out, and loading spinners that never disappear.

Simulating Slow Networks with page.route()

slow-network.spec.ts

import { test, expect } from '@playwright/test';

function delay(ms: number) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

test('page loads gracefully on slow 3G', async ({ page }) => {
  // Intercept all requests and add artificial delay
  await page.route('**/*', async (route) => {
    await delay(1500); // Simulate 1.5s latency per request
    await route.continue();
  });

  await page.goto('https://example.com', { timeout: 30000 });

  // Loading skeleton should appear while content loads
  await expect(page.locator('.skeleton-loader')).toBeVisible();

  // Content should eventually replace skeleton
  await expect(page.locator('.main-content')).toBeVisible({ timeout: 15000 });
});

Offline Mode Testing

offline.spec.ts

test('app shows offline message when disconnected', async ({ page, context }) => {
  await page.goto('https://example.com');
  await expect(page.locator('h1')).toBeVisible();

  // Go offline
  await context.setOffline(true);

  // Try to navigate — should show offline UI
  await page.locator('a[href="/dashboard"]').tap();
  await expect(page.locator('.offline-indicator')).toBeVisible();

  // Come back online
  await context.setOffline(false);
  await page.reload();
  await expect(page.locator('.offline-indicator')).toBeHidden();
});

CDP Network Emulation (Chromium Only)

For Chromium-based projects, you can use the Chrome DevTools Protocol to set precise network conditions:

cdp-throttle.spec.ts

test('test under slow 3G via CDP', async ({ page, browser }) => {
  const cdpSession = await page.context().newCDPSession(page);

  await cdpSession.send('Network.emulateNetworkConditions', {
    offline: false,
    downloadThroughput: (400 * 1024) / 8,  // 400 Kbps
    uploadThroughput: (400 * 1024) / 8,
    latency: 400,  // 400ms RTT
  });

  await page.goto('https://example.com');
  // Assert performance under constrained conditions
});

Geolocation and Permissions

Mobile PWAs and location-aware applications need to test geolocation, camera access, notification permissions, and other device capabilities. Playwright lets you grant or deny these permissions and mock sensor data without any browser extensions or manual interaction.

Setting GPS Coordinates

geolocation.spec.ts

test('shows nearest store based on location', async ({ browser }) => {
  const context = await browser.newContext({
    geolocation: { latitude: 40.7128, longitude: -74.0060 }, // New York City
    permissions: ['geolocation'],
    ...devices['iPhone 15'],
  });

  const page = await context.newPage();
  await page.goto('https://example.com/store-locator');

  // Tap "Find nearest store"
  await page.locator('button:has-text("Find nearest store")').tap();

  // Should show NYC stores
  await expect(page.locator('.store-card').first())
    .toContainText('New York');

  // Change location mid-test
  await context.setGeolocation({ latitude: 34.0522, longitude: -118.2437 }); // Los Angeles
  await page.locator('button:has-text("Refresh location")').tap();
  await expect(page.locator('.store-card').first())
    .toContainText('Los Angeles');

  await context.close();
});

Camera and Microphone Permissions

permissions.spec.ts

test('camera permission flow on mobile PWA', async ({ browser }) => {
  // Grant camera permission
  const context = await browser.newContext({
    permissions: ['camera', 'microphone'],
    ...devices['Pixel 7'],
  });

  const page = await context.newPage();
  await page.goto('https://example.com/scan');

  // QR scanner should activate without permission dialog
  await page.locator('button:has-text("Scan QR Code")').tap();
  await expect(page.locator('.camera-viewfinder')).toBeVisible();

  await context.close();
});

test('denied camera shows fallback UI', async ({ browser }) => {
  // Create context WITHOUT camera permission
  const context = await browser.newContext({
    permissions: [], // No permissions granted
    ...devices['Pixel 7'],
  });

  const page = await context.newPage();
  await page.goto('https://example.com/scan');

  await page.locator('button:has-text("Scan QR Code")').tap();
  // Should show manual entry fallback
  await expect(page.locator('.manual-entry-form')).toBeVisible();

  await context.close();
});

Mobile Testing in CI/CD

Running mobile device projects in CI requires the same infrastructure as desktop tests — no emulators, no device farms, no special hardware. Playwright's device emulation runs on standard CI runners, which makes it straightforward to integrate into Docker-based pipelines and GitHub Actions workflows.

GitHub Actions Matrix for Mobile Devices

.github/workflows/mobile-tests.yml

name: Mobile Tests
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        project:
          - "iPhone 15"
          - "Pixel 7"
          - "Galaxy S23"
          - "iPad Pro 11"
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test --project="${{ matrix.project }}"
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report-${{ matrix.project }}
          path: playwright-report/

Docker Considerations

Playwright's official Docker images include all browser dependencies pre-installed. Mobile device emulation works identically in Docker because it only changes viewport and user agent settings — no native mobile runtimes are needed:

Dockerfile

FROM mcr.microsoft.com/playwright:v1.50.0-jammy

WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .

# Run all mobile projects
CMD ["npx", "playwright", "test", \
  "--project=iPhone 15", \
  "--project=Pixel 7", \
  "--project=Galaxy S23"]

Shard mobile tests: Combine matrix strategy with Playwright sharding to run large mobile test suites in parallel. Use --shard=1/3 to split 300 tests across 3 runners per device, reducing wall-clock time dramatically.

Playwright vs Appium for Mobile Testing

Playwright and Appium serve different segments of mobile testing. Understanding when to use each tool prevents you from over-engineering your test infrastructure or leaving critical gaps uncovered.

Criteria	Playwright	Appium
Test target	Mobile web browsers (emulated)	Native apps, hybrid apps, mobile browsers
Device requirement	None — runs on any OS	Real device or Android/iOS emulator
Setup complexity	npm install + 1 config file	Appium server, SDKs, device drivers
Execution speed	Fast (1–3s per test)	Slow (5–30s per test)
CI integration	Standard runners, no special hardware	Requires macOS for iOS, device farms for scale
Touch gestures	Tap, swipe, long press (simulated)	Full native gesture support
Native features	Geolocation, permissions, network	Push notifications, sensors, file system, native UI
Browsers supported	Chromium, Firefox, WebKit	Chrome Mobile, Safari Mobile
Best for	Responsive web testing at scale	Native/hybrid app testing

The pragmatic approach: Use Playwright for all responsive web testing — it covers 95% of mobile web bugs with 10x faster execution. Add Appium only if you have native mobile apps or need to test platform-specific behaviors (push notifications, biometric auth, app install flows) that emulation cannot replicate.

Use Playwright When

Testing responsive web layouts, mobile navigation, touch interactions on web apps, viewport behavior, mobile web forms, slow network handling, mobile web performance

Use Appium When

Testing native iOS/Android apps, push notification flows, biometric authentication, app-to-app deep links, hardware sensors, app store install flows

Mobile Testing with Claude AI

Writing mobile tests requires thinking about viewports, touch targets, gesture patterns, and device quirks that desktop-focused developers often overlook. Claude AI bridges this knowledge gap. By describing your mobile UI to Claude through the Playwright MCP Server, you can generate device-aware test suites that automatically account for responsive breakpoints, touch accessibility, and mobile-specific patterns.

How AI Accelerates Mobile Test Generation

Claude AI understands the nuances of mobile web testing. When you describe a mobile interaction — "test the checkout flow on iPhone 15" — Claude generates tests that include proper viewport setup, touch-based interactions (.tap() instead of .click()), scroll handling for small screens, and assertions for mobile-specific UI states like bottom sheets and hamburger menus.

Instead of manually writing breakpoint tests for five different device widths, Claude generates the complete breakpoint matrix with overflow detection, touch target validation, and visual regression captures. Instead of guessing which mobile edge cases to test, Claude draws on its knowledge of common mobile bugs — iOS fixed-position issues, Android keyboard viewport resizing, Safari 100vh quirks — to include tests you would not think to write.

What You'll Learn in the Course

Course Coverage for Mobile Testing

Configure mobile device projects from scratch
Generate device-aware tests with Claude AI
Touch gesture simulation (tap, swipe, pinch)
Responsive breakpoint validation at scale
Mobile CI/CD with GitHub Actions matrix
Network throttling and offline testing
Geolocation and permission mocking
Visual regression across mobile devices

Frequently Asked Questions

Can Playwright test real mobile devices?

Playwright does not connect to physical phones or tablets. It uses device emulation, which replicates a mobile device's viewport, user agent, device scale factor, and touch capabilities inside a desktop browser engine. For most responsive and functional testing, emulation is sufficient and significantly faster than real-device farms. For native mobile features like push notifications or hardware sensors, use Appium alongside Playwright.

How do I emulate an iPhone in Playwright?

Import the devices object from @playwright/test and reference the device by name, such as devices['iPhone 15']. Spread it into a project's use property in playwright.config.ts or pass it to browser.newContext(). This automatically sets the viewport, user agent, deviceScaleFactor, hasTouch, and isMobile flags.

Does Playwright support touch events like swipe and pinch?

Yes. Playwright's page.touchscreen API supports tap and multi-touch gestures. Simulate swipes by combining mouse down, move, and up events across coordinates. For pinch-to-zoom, create two simultaneous touch points and move them apart or together. The .tap() method on locators handles simple touch interactions like tapping buttons and links.

What is the difference between Playwright mobile emulation and Appium?

Playwright emulates mobile browsers inside desktop browser engines (Chromium, WebKit, Firefox). It is fast, requires no physical devices, and runs in CI without special infrastructure. Appium automates real mobile browsers and native apps on actual devices or emulators. Use Playwright for responsive web testing and Appium for native app testing or when you need real device hardware behavior.

Can I simulate slow 3G network on mobile in Playwright?

Playwright does not have a built-in network throttling API. However, you can simulate slow networks using page.route() to add artificial delays to every request, or by using a proxy server. For Chromium-only projects, use the Chrome DevTools Protocol (CDP) to enable network emulation with specific download/upload speeds and latency settings via Network.emulateNetworkConditions.

Meet Your Instructor

Asim Noaman

Senior QA Automation Engineer & AI Testing Specialist

With years of hands-on experience building test automation frameworks for production applications, Asim specializes in combining traditional QA methodologies with cutting-edge AI tools. He has helped teams adopt Playwright and AI-driven testing workflows to ship faster with fewer bugs.

Udemy Instructor Published course author

Playwright + AI Expert Specialized in AI-powered QA

Production Experience Enterprise-grade frameworks

Connect on LinkedIn