Playwright vs Selenium for Scheduled Website Screenshot Jobs

For a new scheduled screenshot job, choose Playwright when you want screenshot capture and visual assertions in one workflow, particularly if you already use Playwright Test. Choose Selenium when the job belongs in an existing WebDriver language and browser ecosystem, or when remote execution through Selenium Grid is central. Both can capture screenshots. Neither project documentation establishes a universal speed or cost winner for this workload.

For repeatable results, the browser framework is only part of the decision. Keep the operating system, browser version, fonts, viewport, locale, timezone, page-ready condition, and screenshot policy consistent. Start with one worker when reliability matters most; expand concurrency after measuring the real workload.

1. Decision at a glance

Choose	When it fits	Trade-off to consider
Playwright	You are starting a focused job, already use Playwright Test, or want its built-in `toHaveScreenshot()` visual comparison workflow.	Standardize browser installation and the runtime image. Playwright rendering can vary across operating systems, browser versions, settings, hardware, power sources, and headless mode.
Selenium	You need to stay within an established WebDriver language/browser ecosystem, or need Selenium Grid’s remote sessions across machines, browser versions, or platforms.	Plan for browser and driver setup, and for the operational capacity of a Grid if you run one.

Make the choice using your current codebase, target browsers, language, desired remote execution model, visual comparison needs, and ability to keep the browser environment consistent. Selenium describes WebDriver as a W3C Recommendation. See the official Playwright visual comparisons, Playwright CI guidance, Selenium WebDriver documentation, and Selenium Grid documentation.

2. A scheduled Playwright screenshot job

This example uses Playwright Test to visit a page, wait for a meaningful readiness condition, and save a full-page PNG. It can run locally or in CI. The page’s selector is an example; replace it with a stable element from your target.

// tests/scheduled-shot.spec.js
const { test, expect } = require('@playwright/test');
const path = require('node:path');
const fs = require('node:fs/promises');

test('capture the scheduled page', async ({ page }) => {
  const url = process.env.TARGET_URL || 'https://example.com';
  await page.setViewportSize({ width: 1440, height: 1000 });
  await page.emulateMedia({ colorScheme: 'light', reducedMotion: 'reduce' });
  await page.goto(url, { waitUntil: 'domcontentloaded', timeout: 60_000 });
  // Prefer a page-specific readiness condition to an arbitrary long sleep.
  await page.locator('body').waitFor({ state: 'visible', timeout: 20_000 });
  await page.screenshot({ path: path.join('artifacts', 'page.png'), fullPage: true });
});

Install and run it:

npm init -y
npm install --save-dev @playwright/test
npx playwright install --with-deps chromium
mkdir -p artifacts
TARGET_URL=https://example.com npx playwright test tests/scheduled-shot.spec.js --workers=1

To use Playwright Test’s visual assertion workflow, establish and review a baseline in the same environment used by scheduled runs:

await expect(page).toHaveScreenshot('page.png', { fullPage: true });

Visual snapshot comparisons are useful when the question is whether a page changed. A recurring archive job may only need image files, in which case page.screenshot() is sufficient. Consult the official snapshot documentation for baseline behavior and configuration.

3. A scheduled Selenium screenshot job

This Python example uses Selenium WebDriver locally. Selenium Manager can assist with driver management in supported setups; the browser itself still needs to be available in the runtime. For remote execution, configure a Grid and use its WebDriver endpoint.

# screenshot_job.py
import os
from pathlib import Path
from selenium import webdriver
from selenium.webdriver.support.ui import WebDriverWait

url = os.environ.get('TARGET_URL', 'https://example.com')
Path('artifacts').mkdir(exist_ok=True)

options = webdriver.ChromeOptions()
options.add_argument('--headless')
options.add_argument('--window-size=1440,1000')

driver = webdriver.Chrome(options=options)
try:
    driver.set_page_load_timeout(60)
    driver.get(url)
    WebDriverWait(driver, 20).until(
        lambda d: d.execute_script("return document.readyState") == 'complete'
    )
    driver.save_screenshot('artifacts/page.png')
finally:
    driver.quit()

Install and run:

python -m venv .venv
. .venv/bin/activate
python -m pip install selenium
TARGET_URL=https://example.com python screenshot_job.py

save_screenshot() captures the current browser viewport. If the job needs a full-page image, verify the behavior for your chosen browser and binding and implement or select an approach that fits that target; do not assume viewport capture equals full-page capture. Selenium’s documentation also covers browser and element screenshot APIs in its binding-specific materials. For remote sessions, see getting started with Selenium Grid.

4. Schedule it in CI

A schedule runs code repeatedly; it does not by itself make captures reproducible. Pin the runtime image and dependencies, install the browser and its system dependencies as part of the job, and save artifacts under a predictable name. Here is a GitHub Actions example for the Playwright test above:

# .github/workflows/scheduled-screenshot.yml
name: Scheduled screenshot
on:
  workflow_dispatch:
  schedule:
    - cron: '17 6 * * *'
jobs:
  capture:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: mkdir -p artifacts
      - run: npx playwright test tests/scheduled-shot.spec.js --workers=1
        env:
          TARGET_URL: https://example.com
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: scheduled-page-shot
          path: artifacts/
          if-no-files-found: warn

Commit a lockfile so CI installs the dependency versions you reviewed. For stronger image consistency, use a pinned container image and keep it updated deliberately. Playwright’s CI guidance discusses browser installation, containers, workers, and sharding. It cautions that browser caching may not save time once cache restoration and Linux dependencies are considered; evaluate that against your own CI provider and current setup rather than assuming caching helps. See Playwright’s CI guide.

For Selenium, the scheduler can invoke the Python script in the same way. Install a known browser environment in the runner or point a remote WebDriver client at a maintained Grid. Grid is useful when remote browser sessions and distributed execution are needed; it also introduces capacity and operational planning. See Grid concepts and Grid setup.

5. Make scheduled captures comparable

Changes in the environment or page state can look like product changes in the resulting image. Write down a screenshot policy and apply it to every run:

Browser environment: pin or otherwise record the OS image, browser version, automation package versions, fonts, and headless configuration.
Viewport and scale: set fixed width and height; keep device scale consistent if the framework exposes it.
Rendering preferences: set color scheme, reduced motion, locale, and timezone where relevant to the page.
Page readiness: wait for a meaningful selector or application-specific state. A network-idle condition can be inappropriate for pages with polling or persistent connections.
Dynamic content: decide how to handle timestamps, rotating banners, animations, advertisements, and personalized data. If visual comparisons matter, control or mask changing regions where your tooling supports it.
Authentication and consent: decide whether a run should use a stable authenticated state and whether cookie banners should appear in the image. Store credentials and state securely.
Artifacts: include the page identity and run date in filenames or metadata, define retention, and alert on failed runs.

Playwright specifically warns that screenshot rendering can differ with OS, browser version, settings, hardware, power source, and headless mode, and recommends using the same environment for consistent comparisons. See its visual comparison guidance.

6. Concurrency, reliability, and cost

Start with one worker

For a modest scheduled job, begin with one worker. Playwright recommends one worker in CI when prioritizing stability and reproducibility. Its test files can run in parallel by default; increase workers or shard only after measuring, and coordinate tests that share accounts, quotas, or mutable data. See CI guidance and parallelism documentation.

Scale only against the real workload

For Selenium, Grid routes remote sessions across machines and browser versions. Actual capacity depends on the machines, browser mix, page resource use, and desired simultaneous sessions. Measure throughput and failure rates on the intended runner images and URLs before setting concurrency. A larger worker count can increase resource contention and make captures less stable.

Measure total cost instead of guessing

The reviewed project documentation does not provide a directly comparable speed or total-cost benchmark for scheduled screenshot jobs. Measure cold start, time to page readiness, screenshot time, retry rate, job duration, CI minutes, and any Grid or hosted-browser charges using identical URLs and output requirements. Include the cost of maintaining browser images and diagnosing intermittent failures.

Make failures visible

Use finite navigation and readiness timeouts, always close browser sessions, preserve logs and failed-run artifacts, and send an alert when a scheduled job fails. Retry only errors likely to be transient; retries can conceal a broken page or unstable environment if they are silent.

7. Troubleshooting

Symptom	Likely cause	Fix
Browser executable or shared library is missing	The runner has the automation package but not the browser or OS dependencies.	Install the required browser and dependencies in the CI job or use a maintained image. For Playwright, follow its CI installation instructions; for Selenium, ensure the browser is installed and driver management is configured.
Screenshot is blank, incomplete, or captured too early	Navigation completion did not mean the relevant application content was ready.	Wait for a page-specific selector or state, check redirects and console/network errors, and choose a timeout that reflects the page. Avoid relying only on a fixed sleep.
Images or fonts differ between runs	Fonts, browser versions, operating systems, scale, or resource loading differ.	Standardize the runtime and browser, install required fonts, fix viewport and scale, and ensure assets have loaded before capture.
Visual assertions fail intermittently	Dynamic content, animations, layout shifts, or parallel jobs affect the output.	Reduce motion, wait for stable application state, control or mask volatile regions, and run with one worker while diagnosing. Keep comparison runs in the same environment.
Navigation times out on an otherwise active page	The page keeps network connections open or loads long-running requests.	Use a readiness selector or application condition instead of waiting for network idle or full network quiescence. Set a bounded navigation timeout.
Selenium session cannot reach the Grid	The Grid endpoint is wrong, inaccessible from the runner, or has no available matching node.	Check the endpoint and network route, inspect Grid status and node capabilities, then reduce concurrency or add suitable capacity.
Scheduled run differs from a local run	Different OS, browser version, fonts, locale, timezone, environment variables, or credentials.	Record and standardize those inputs; compare CI logs and browser versions before treating the image difference as a site regression.

8. Or skip the browser setup

If the job’s output is a screenshot file and you do not need to operate Playwright or Selenium, ScreenshotNeo provides a website screenshot API and MCP server. One GET request returns an image or PDF. 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

Python:

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}`);

Cookie and consent banners, newsletter popups, and chat widgets are removed before the shot; each cleanup step can be turned off.
Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed. Response headers report the page verdict and billing status.
An MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs.
The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.

9. FAQ

Can both tools capture an element instead of a page?

Yes. Playwright supports locator screenshots, and Selenium bindings document element screenshot methods. Choose the target element and verify the behavior in the browser and binding you deploy.

Which should I use for visual regression tests?

Playwright Test has a documented toHaveScreenshot() comparison workflow. Selenium can capture screenshots, but the reviewed Selenium sources do not establish an equivalent built-in visual assertion workflow. Your test framework and comparison tooling may affect the overall design.

Is either framework always faster or cheaper?

No conclusion is supported for this specific workload. Benchmark your actual URLs, browser environment, concurrency, retries, and infrastructure costs.

Does Selenium Grid make Selenium the right choice for every scheduled job?

No. Grid is a fit when remote sessions and distributed browser execution solve a real requirement. A single runner may be simpler for a small job.

How often should I update browser versions?

Use a deliberate update process: review browser and automation dependency changes, update the pinned runtime, then assess screenshot changes in that same environment before relying on new baselines.