Playwright page.goto Slow? Fix Navigation Time in CI

By default, page.goto() waits for the load event. The load event fires only once the whole page has loaded, including stylesheets, scripts, iframes and images. The DOMContentLoaded event fires once the HTML document has been completely parsed and all deferred scripts have downloaded and executed, and that event doesn't wait for images, subframes or async scripts to finish loading.

Playwright creates a new browser context for each test. Every test that opens the page loads it in its own context. Across a large suite, one slow page becomes a line item on your CI bill.

We'd expect a raised timeout to get the test green. It also keeps every slow second in the suite and hides which page was slow.

The real fix is to find the slow pages and stop paying for them in every test.

What page.goto waits for

A bare page.goto(url) is the same call as page.goto(url, { waitUntil: 'load' }). The waitUntil option decides when a navigation counts as finished, and it defaults to load.

The wait has two halves. A navigation commits once the response headers are parsed and session history is updated, and only then does the page start loading the document. Loading covers getting the rest of the response body over the network, parsing, running scripts and firing load events.

In the test below, both goto calls wait for the same thing. The comments list three of the waitUntil values, earliest first:

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

test('default goto waits for the load event', async ({ page }) => {
  // Equivalent calls: waitUntil defaults to 'load'.
  await page.goto('http://localhost:3000/dashboard');
  await page.goto('http://localhost:3000/dashboard', { waitUntil: 'load' });

  // 'commit'           response received, document started loading
  // 'domcontentloaded' the DOMContentLoaded event fired
  // 'load'             the load event fired: stylesheets, scripts, iframes, images
});

That split tells you where to look. A slow commit points at the server or the network, because nothing past the response headers has happened yet. A long gap between commit and load points at what the page pulls in afterwards: third-party scripts, fonts and images.

If the page does a client-side redirect before load, page.goto() waits for the redirected page to fire the load event. When the server sends multiple redirects, the navigation resolves with the first non-redirect response.

One bug report describes an error in Firefox. In that report, a goto failed with an NS_BINDING_ABORTED error when the page started a navigation of its own at the same time (#20749). A maintainer replied that this matches what Firefox itself does. The issue is still open. If a Firefox-only failure names that error, look for a script on the page that navigates by itself.

Timing every navigation

Every fix below trades something, so measure before you change anything.

// fixtures.ts
import { test as base } from '@playwright/test';

export const test = base.extend({
  page: async ({ page }, use) => {
    const goto = page.goto.bind(page);
    page.goto = async (url, options) => {
      const start = Date.now();
      try {
        return await goto(url, options);
      } finally {
        // Recorded even when the navigation throws.
        base.info().annotations.push({
          type: 'goto',
          description: `${Date.now() - start}ms ${url}`,
        });
      }
    };
    await use(page);
  },
});

export { expect } from '@playwright/test';

Choosing a waitUntil

Once you know which pages are slow, the cheapest fix is to stop waiting for resources the test never touches. These are the waitUntil values page.goto() accepts:

• commit: finished when the network response is received and the document has started loading.
• domcontentloaded: finished when the DOMContentLoaded event fires.
• load: the navigation finishes when the load event fires, and load is the default.
• networkidle: finished when there have been no network connections for at least 500 ms. The docs mark it as discouraged.

Use domcontentloaded as the suite default. Use commit only when a readiness check follows it. Stopping early works for actions because Playwright waits for each action's target element to become actionable, so you can interact with the page at any moment.

Keep load when the test exists to prove that the page's subresources load, such as a synthetic check that a third-party support widget still arrives. In that test, waiting for every script is the point.

// Anti-pattern: 500 ms of network quiet on every navigation, and never on a polling page
import { test, expect } from '@playwright/test';

test('dashboard shows recent orders', async ({ page }) => {
  await page.goto('http://localhost:3000/dashboard', { waitUntil: 'networkidle' });
  await expect(page.getByRole('heading', { name: 'Recent orders' })).toBeVisible();
});

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

test('dashboard shows recent orders', async ({ page }) => {
  await page.goto('http://localhost:3000/dashboard', { waitUntil: 'domcontentloaded' });
  await expect(page.getByRole('heading', { name: 'Recent orders' })).toBeVisible();
});

Hydration readiness checks

Stopping early trades slow tests for a different risk: clicking before the page can respond. The Playwright navigation docs put it plainly: there is no way to tell that a page is loaded, because it depends on the page and the framework. Readiness has to come from a signal the app gives.

Playwright starts interacting with the page the moment it sees it. If a button is enabled but its listeners haven't been added yet, Playwright clicks it and the click has no effect.

// Anti-pattern: the button is enabled before hydration, so this click can do nothing
import { test, expect } from '@playwright/test';

test('user can create an account', async ({ page }) => {
  await page.goto('http://localhost:3000/signup', { waitUntil: 'commit' });
  await page.getByLabel('Email').fill('user@example.com');
  await page.getByRole('button', { name: 'Create account' }).click();
  await expect(page.getByText('Check your inbox')).toBeVisible();
});

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

test('user can create an account', async ({ page }) => {
  await page.goto('http://localhost:3000/signup', { waitUntil: 'commit' });

  // The app keeps this button disabled until hydration attaches its handlers.
  const submit = page.getByRole('button', { name: 'Create account' });
  await expect(submit).toBeEnabled();

  await page.getByLabel('Email').fill('user@example.com');
  await submit.click();
  await expect(page.getByText('Check your inbox')).toBeVisible();
});

Readiness signals

A shared goto fixture

A waitUntil choice copied into hundreds of goto calls is a choice nobody can change.

// fixtures.ts
import { test as base } from '@playwright/test';

export const test = base.extend({
  page: async ({ page }, use) => {
    const goto = page.goto.bind(page);
    page.goto = async (url, options) => {
      const start = Date.now();
      try {
        // Suite default; a call that passes its own waitUntil overrides it.
        return await goto(url, { waitUntil: 'domcontentloaded', ...options });
      } finally {
        base.info().annotations.push({
          type: 'goto',
          description: `${Date.now() - start}ms ${url}`,
        });
      }
    };
    await use(page);
  },
});

export { expect } from '@playwright/test';

Dev server vs production build

Some CI-only timeouts come from the server, not from the test. The webServer option launches a local dev server before the tests run, and the docs present it as ideal while you write tests during development, or when there is no staging or production URL to test against. Writing tests on your laptop and gating merges in CI are different jobs.

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

const isCI = !!process.env.CI;

export default defineConfig({
  webServer: {
    // CI tests the production build; local runs keep the dev server.
    command: isCI ? 'npm run build && npm run start' : 'npm run dev',
    url: 'http://localhost:3000',
    // Startup only. In CI that includes the build.
    timeout: 180_000,
  },
});

Skipping login navigations

The fastest navigation is the one a test never makes. A test that logs in through the UI opens the login page, submits the form and follows whatever redirects bring it into the app before it reaches the page under test. Tests can load an existing authenticated state instead, so they don't each have to log in, which the docs say speeds up test execution.

Log in once in a setup test and save the state. Our guide to auth state at scale covers per-worker accounts and logging in through the API; the basic version looks like this:

// auth.setup.ts
import { test as setup, expect } from '@playwright/test';

setup('log in once', async ({ page }) => {
  await page.goto('http://localhost:3000/login');
  await page.getByLabel('Email').fill(process.env.TEST_USER_EMAIL!);
  await page.getByLabel('Password').fill(process.env.TEST_USER_PASSWORD!);
  await page.getByRole('button', { name: 'Sign in' }).click();
  await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();
  await page.context().storageState({ path: 'playwright/.auth/user.json' });
});

Then have the test project load that state and depend on the setup project:

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

export default defineConfig({
  projects: [
    { name: 'setup', testMatch: '**/auth.setup.ts' },
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'], storageState: 'playwright/.auth/user.json' },
      dependencies: ['setup'],
    },
  ],
});

With the session loaded, go straight to the deep URL the test needs instead of the home page and a walk through the menu:

import { test, expect } from './fixtures';

test('user can update the billing address', async ({ page }) => {
  await page.goto('http://localhost:3000/settings/billing');
  await expect(page.getByRole('heading', { name: 'Billing' })).toBeVisible();
});

Blocking third-party scripts

A test that still waits for load waits for every analytics tag, chat widget and ad script the page pulls in, because the load event fires only once scripts, iframes and images have all loaded. page.route() can abort those requests so they stop holding the navigation back.

// Anti-pattern: every request the page makes now stalls in this handler
import { test, expect } from '@playwright/test';

test('checkout page loads', async ({ page }) => {
  await page.route('**/*', (route) => {
    const host = new URL(route.request().url()).hostname;
    if (host.endsWith('analytics.example.net')) return route.abort();
    return route.continue();
  });
  await page.goto('http://localhost:3000/checkout');
  await expect(page.getByRole('heading', { name: 'Checkout' })).toBeVisible();
});

// fixtures.ts
import { test as base } from '@playwright/test';

// Third-party hosts only: a matching request stalls until it is handled.
const blockedPatterns = [
  'https://analytics.example.net/**',
  'https://chat-widget.example.org/**',
  'https://ads.example.com/**',
];

export const test = base.extend({
  page: async ({ page }, use) => {
    for (const pattern of blockedPatterns) {
      await page.route(pattern, (route) => route.abort());
    }

    const goto = page.goto.bind(page);
    page.goto = async (url, options) => {
      const start = Date.now();
      try {
        return await goto(url, { waitUntil: 'domcontentloaded', ...options });
      } finally {
        base.info().annotations.push({
          type: 'goto',
          description: `${Date.now() - start}ms ${url}`,
        });
      }
    };
    await use(page);
  },
});

export { expect } from '@playwright/test';

Cache cost

Enabling routing disables the HTTP cache, however narrow the pattern. Rerun the suite with the timing annotations and compare before and after: keep the blocking only if the navigations got faster.

Each test runs in its own browser context: Playwright creates a new one every time a test runs. A request to reuse the static files an earlier test had downloaded got a maintainer's reply that the disk cache isn't shared between isolated contexts, and the issue is still open (#22865).

Don't block the third-party script a test exists to check. If the product depends on a support widget, the test for that widget runs without the route.

Navigation timeouts

By default, a slow goto has no navigation timeout to hit. The timeout of page.goto() defaults to 0, meaning no timeout, and so does the navigationTimeout test option. The limit a stuck navigation runs into is the test timeout, 30 seconds by default, so a slow page fails as a test timeout (our checklist for debugging Playwright timeouts works through that error from the other end).

// Anti-pattern: slow navigations now pass, and every slow second stays in CI
import { defineConfig } from '@playwright/test';

export default defineConfig({
  timeout: 120_000,
});

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

export default defineConfig({
  use: {
    // Below the 30-second test timeout.
    navigationTimeout: 15_000,
  },
});

import { test, expect } from './fixtures';

test('annual report renders', async ({ page }) => {
  // Known slow page: the report is built on request.
  await page.goto('http://localhost:3000/reports/annual', { timeout: 25_000 });
  await expect(page.getByRole('heading', { name: 'Annual report' })).toBeVisible();
});

CI-only navigation gotchas

Some navigation failures only look like readiness problems. page.goto() doesn't throw when the server returns a valid HTTP status code, including 404 and 500. Because page.goto() does not throw on a 404 or 500, the test carries on past the navigation and fails later, at a locator that never appears. Assert on the page's own content right after goto so a server error fails at the line that navigated.

Time before the test body counts too. Fixture setup and beforeEach hooks count toward the test timeout (30 seconds by default), so a beforeEach that logs in and opens a slow first page can use up most of a test's time before its first line runs.

Before blaming goto for hangs that recur at a regular interval in a long run, check what failed just before each one. Playwright Test discards the worker process along with the browser after any failed test and starts a new one. In one WebKit report (#42385), a goto hung roughly every 65 navigations. The reporter later traced it to macOS display sleep, and a contributor said it was already fixed in WebKit 2355 and asked them to try Playwright 1.63. The reporter confirmed the fix.

Tracking navigation time across runs

The timing fixture measures goto and nothing after it. The fixture's navigation counts as finished when the DOMContentLoaded event fires, so a readiness check after it is not in its numbers. One run's annotations can't tell you whether last month's fix held.

Currents defines a metric from an annotation whose type is currents:metric and whose description is a serialized JSON object. The JSON string must contain a name and a value. Custom metrics appear in the Test Results chart, where a Custom Metric control lets you browse the available metrics and aggregation functions. The fixture below adds that metric next to the existing annotation on every navigation:

// fixtures.ts
import { test as base } from '@playwright/test';

const blockedPatterns = [
  'https://analytics.example.net/**',
  'https://chat-widget.example.org/**',
  'https://ads.example.com/**',
];

export const test = base.extend({
  page: async ({ page }, use) => {
    for (const pattern of blockedPatterns) {
      await page.route(pattern, (route) => route.abort());
    }

    const goto = page.goto.bind(page);
    page.goto = async (url, options) => {
      const start = Date.now();
      try {
        return await goto(url, { waitUntil: 'domcontentloaded', ...options });
      } finally {
        const ms = Date.now() - start;
        base.info().annotations.push({ type: 'goto', description: `${ms}ms ${url}` });
        // The metric's description must be a serialized JSON object.
        base.info().annotations.push({
          type: 'currents:metric',
          description: JSON.stringify({ name: 'goto_ms', value: ms }),
        });
      }
    };
    await use(page);
  },
});

export { expect } from '@playwright/test';

In Currents' Test Explorer, the Slowest preset lists the tests with the highest average duration. Duration Impact measures how much total time a test contributes to the suite's runtime, from both how long it takes per run and how often it runs. Duration Trend compares a test's average duration across two equal periods, such as the last 30 days against the previous 30 days, and a negative value means the test is running faster.

Wherever the numbers end up, keep the order: time every goto, fix the slowest pages first, and keep a change only when the timings drop. A raised timeout never passes that test.

Frequently asked questions