--- title: "Lightpanda vs Playwright and Headless Chrome: When a Lightweight Browser Is Enough" slug: lightpanda-vs-playwright-and-headless-chrome date: 2026-11-15T12:04:25+00:00 modified: 2026-11-15T12:06:23+00:00 permalink: https://brightdata.com/blog/comparison/lightpanda-vs-playwright-and-headless-chrome type: blog --- [ Blog ](https://brightdata.com/blog "Blog") / [Comparison](https://brightdata.com/blog/comparison) [Comparison](https://brightdata.com/blog/comparison) # Lightpanda vs Playwright and Headless Chrome: When a Lightweight Browser Is Enough This guide compares Lightpanda with Playwright’s headless Chrome across CPU, memory, and 44 Playwright checks. It includes a calibration and routing script that sends each site to plain HTTP, Lightpanda, or Bright Data Browser API, based on how much of the page text each one returns. 23 min read [ ](https://brightdata.com/blog/authors/satyam-tripathi) [Satyam Tripathi Technical Writer ](https://brightdata.com/blog/authors/satyam-tripathi) ![lightpanda-vs-playwright-G-benchmark-bench](https://media.brightdata.com/2026/11/lightpanda-vs-playwright-G-benchmark-bench.png) A Playwright script that loads one page at a time moves from headless Chrome to Lightpanda with a one-line connection change. Some results differ silently. For example, Lightpanda 1.0.2 clicked a button that an overlay covered. Lightpanda is an open-source [headless browser](/blog/proxy-101/what-is-a-headless-browser) that runs JavaScript and builds the DOM. Version 1.0.2 skips layout and paint to save CPU and memory. Playwright connects to it as it does to Chrome, so “Lightpanda vs Playwright” is a choice of browser. This guide shows which Playwright calls differ, what Lightpanda saves, and when plain HTTP or [Bright Data Browser API](/products/scraping-browser) is better. ## [](#TLDR)TL;DR - **Lightpanda can replace Chrome for text extraction on sites that pass a per-site check.** Lightpanda 1.0.2 returned at least 90% of the distinct words that full Chrome showed on 15 of 19 pages, or 16 with one extra flag. - **Keep Chrome for screenshots, dialogs, hover menus, and overlays.** Lightpanda matched Chrome on 22 of 44 Playwright checks by default and 30 with 4 flags, and most differences raised no error. Its user agent couldn’t be set to look like Chrome’s. - **The main gain is memory, not speed.** In a 16-page test on ARM Linux, Lightpanda used under half the CPU time of Chrome’s headless shell, but neither was consistently faster. Up to 8 concurrent pages, each extra page added about 14 MB against 69 MB in Chrome, and each Lightpanda server takes one authenticated proxy. Blocking images in Chrome saved about as much proxy traffic as switching. - **Route each site to plain HTTP, Lightpanda, or Bright Data Browser API, which handles full rendering, geo-targeting, and scale.** ## [](#Lightpanda-vs-Playwright-run-Lightpanda-as-Playwrights-browser)Lightpanda vs Playwright: run Lightpanda as Playwright’s browser Playwright drives Chrome over the Chrome DevTools Protocol (CDP), and Lightpanda implements CDP. So Playwright, Puppeteer, and the Go library chromedp connect to Lightpanda the same way they connect to a remote Chrome. The useful comparison is Lightpanda vs headless Chrome with one script. Lightpanda vs Puppeteer is the same question if you use [Puppeteer instead of Playwright](/blog/web-data/puppeteer-vs-playwright). Download a release and start its CDP server. The `--load-resources stylesheet` flag fetches external stylesheets, which Lightpanda skips by default. Every script in this guide connects to this server: ```none curl -L -o lightpanda https://github.com/lightpanda-io/browser/releases/download/1.0.2/lightpanda-x86_64-linux chmod a+x lightpanda ./lightpanda serve --host 127.0.0.1 --port 9222 --load-resources stylesheet ``` Other platforms use the same URL with `aarch64-linux`, `aarch64-macos`, or `x86_64-macos` in place of `x86_64-linux`. On ARM Linux, the 1.0.2 binary needs glibc 2.38 or later, which ships with Debian 13 and Ubuntu 24.04. Keep the server running in its own terminal. With Docker, start the same server from the project’s image: ```none docker run -d -p 127.0.0.1:9222:9222 lightpanda/browser:1.0.2 \ /bin/lightpanda serve --host 0.0.0.0 --port 9222 --load-resources stylesheet ``` To send Lightpanda’s traffic through a [proxy](/proxy-types), add `--http-proxy http://user:password@host:port` to the server command. That proxy is server-wide. With a [rotating proxy](/blog/proxy-101/static-vs-rotating-proxies), a sticky session keeps a page’s requests on one IP, but every page on that server then shares it. Playwright’s per-context `proxy` option worked with a proxy that needs no password, but failed with `CouldntConnect` when the proxy required authentication. To give each session its own authenticated proxy, start one server per proxy. Each server starts in about 65 ms and uses about 11 MB of memory before it loads a page. Then connect your [Playwright scraper](/blog/how-tos/playwright-web-scraping) to that server with `connect_over_cdp()` instead of `launch()`. You don’t need to run `playwright install` for this. Each Lightpanda 1.0.2 connection holds 1 browser context with 1 page, so open a new connection for each page that you load in parallel: ```none """Load one page in Lightpanda through Playwright. uv init && uv add playwright==1.64.1 httpx selectolax uv run python quickstart.py The calibration scripts later in this guide use httpx and selectolax. """ import asyncio from playwright.async_api import async_playwright async def main(): async with async_playwright() as pw: browser = await pw.chromium.connect_over_cdp("ws://127.0.0.1:9222") # Each Lightpanda 1.0.2 connection holds 1 browser context with 1 page context = await browser.new_context() page = await context.new_page() await page.goto("https://news.ycombinator.com/") titles = await page.locator(".titleline").count() print(f"{await page.title()}: {titles} titles") await browser.close() asyncio.run(main()) ``` The script printed: ```none Hacker News: 30 titles ``` Each new browser context starts with empty storage, so add your session cookies to each one with `context.add_cookies()`. Puppeteer connects the same way, through `puppeteer.connect()` and one `createBrowserContext()` per connection. With Puppeteer 25.16, the same page returned 30 titles. Selenium connects through WebDriver instead, after you start the server with `--protocol webdriver`. ## [](#Lightpanda-vs-headless-Chrome-CPU-memory-time-and-proxy-traffic)Lightpanda vs headless Chrome: CPU, memory, time, and proxy traffic [Lightpanda’s own benchmark](https://github.com/lightpanda-io/demo/blob/main/BENCHMARKS.md) reported 9 times the speed and 16 times less memory than Chrome on its demo site with 25 parallel processes. On public pages, with real network latency, the difference is smaller. I tested 16 public pages, such as Wikipedia, MDN, BBC News, and Walmart, in a Debian 13 container on an Apple M3 Mac. The test compared Lightpanda 1.0.2 with Playwright 1.64.1’s Chrome 156 headless shell, the standalone build of Chrome’s old headless mode. Each browser loaded the pages sequentially and then at a concurrency of 8, with a 1.5-second wait after DOMContentLoaded on each page. Values are medians of 3 runs, with wall-time ranges in parentheses, and memory is the peak proportional set size (PSS) of the browser processes only: Linux container, median of 3 runsLightpanda 1.0.2Chrome headless shellCPU time, sequential10.2 s21.3 sPeak memory (PSS), sequential286 MB559 MBWall time, sequential48 s (45 to 49)42 s (41 to 50)CPU time, concurrency 88.7 s19.7 sPeak memory (PSS), concurrency 8387 MB1,042 MBWall time, concurrency 810 s (9 to 17)17 s (8 to 18)With default flags, Lightpanda used 44% to 48% of the headless shell’s CPU time and 37% to 51% of its peak memory. Chrome loaded each concurrent page in a new context of one browser, and Lightpanda in a new connection to one server. From sequential to a concurrency of 8, each extra concurrent page added about 14 MB on Lightpanda and 69 MB on the headless shell. The stylesheet flag added 3% to 11% to Lightpanda’s CPU time in a macOS test. Neither browser was consistently faster in wall time. Most of each run went to network time and the fixed 1.5-second waits, which depend little on the browser. Both browsers got the same wait, so the CPU figures cover the same time window. On a slow page, that window can end before rendering finishes. By default, Puppeteer 25.16 launches Chrome in the new headless mode, which runs the full browser. On macOS, that mode used 1.6 to 2.1 times the headless shell’s CPU time. So if you use Puppeteer with its defaults, Lightpanda’s CPU saving is larger than this table shows. **Blocking images in Chrome saves about as much proxy traffic as switching to Lightpanda.** If traffic is your main cost, try that before you switch browsers. For the 15 pages other than Walmart, Chrome used a median total of 29.9 MB of proxy traffic and Lightpanda 24.1 MB. With images, fonts, and media blocked through `page.route()` request interception, Chrome used 22.3 MB, and its CPU time stayed the same in a macOS test. Walmart is excluded from these numbers, because it returned a short page to Chrome’s headless shell and its full results page to Lightpanda. Lightpanda skips images, but it can download more scripts and data. On Vercel’s pricing page, it prefetched React Server Components (RSC) payloads for 21 linked pages, against 4 in Chrome. Next.js prefetched each link that entered the viewport, and Lightpanda reported every observed link as inside the viewport. Lightpanda’s CPU saving was about 12 CPU-minutes per 1,000 pages. If you pay for proxy traffic, the 1.6 to 2 GB that 1,000 such pages use costs more than those 12 CPU-minutes. The larger gain is memory per concurrent page, which limits how many concurrent sessions one server can run. Before you plan server capacity, run a soak test on your own workload and hardware to check memory growth and stability. For the pages that need Chrome, Browser API runs the sessions, so they don’t use your servers. ## [](#Lightpanda-vs-Chrome-in-Playwright-which-calls-match-and-which-differ)Lightpanda vs Chrome in Playwright: which calls match and which differ I ran the same 44 Playwright checks in Python on a local test site, once on Chrome 156’s headless shell and once on Lightpanda. A check passed only when Lightpanda returned the same value as Chrome. With default settings, Lightpanda matched Chrome on 22 of the 44 checks. It matched on 30 with 4 flags, passed as `--load-resources stylesheet --load-resources iframe --load-resources worker --timezone America/New_York`. In `serve` mode, Lightpanda 1.0.2’s [default settings](https://github.com/lightpanda-io/browser/blob/1.0.2/src/Config.zig#L234-L242) don’t fetch external stylesheets, iframe documents, worker scripts, or images unless you pass `--load-resources`. Skipping external stylesheets changes results silently. On the test site, an external CSS file hid one element. Without `--load-resources stylesheet`, Lightpanda reported that element as visible, and `inner_text("body")` included its text. Most sites load their CSS from external files, so pass `--load-resources stylesheet` to remove much of the hidden price, menu, and modal text from your data. The table groups the 44 checks by what Lightpanda returned: Result on Lightpanda 1.0.2ChecksPlaywright featuresSame as Chrome with default settings22`goto`, client-side rendering with `fetch()`, `click`, `fill`, `select_option`, `check`, keyboard input, shadow DOM, `get_by_role`, XPath, `route.fulfill`, cookies, `localStorage`, IndexedDB, file upload, WebSocket, `history.pushState`, redirects and status codes, Shift\_JIS encoding, `networkidle`, console events, `aria_snapshot`Same with the 4 flags8`is_visible` and `inner_text` with external CSS, same-origin and cross-origin iframes, request events for CSS and frames, request interception for stylesheets, web workers, time zone emulationA different value, with no error11Bounding boxes, clicks on covered elements, CSS `:hover`, `@media` rules after a viewport change, `confirm()` dialogs, canvas and WebGL, `navigator` properties, user agent, screenshots, PDFs, Playwright tracesAn error or a missing API3A second page in one browser context, file downloads, service workersSeparately, capturing API responses with `page.on("response")` and `response.json()` worked as on Chrome. Lightpanda 1.0.3, released after these tests, fixed file downloads, and every other check stayed in the same table row. The Python and Puppeteer examples ran unchanged, so the commands also work with 1.0.3 in place of 1.0.2. The silent differences need the most care, because a test can pass on Lightpanda while the same page behaves differently in Chrome: - **Lightpanda clicked buttons under overlays.** A fixed-position overlay covered a button. On Chrome, Playwright’s actionability check failed and the click timed out, because another element would receive it. Clicking through an overlay can help a scraper, but a script tested only on Lightpanda can then stop at a cookie consent banner on Chrome. - **`confirm()` returned false.** A test page called `confirm()`, and on Lightpanda the call returned `false`. Playwright’s dialog handler then raised “No dialog is showing”, so a flow that waits for the user to confirm is cancelled. - **CSS hover menus stayed closed.** `page.hover()` fired the `mouseover` event, but a submenu shown with CSS `:hover` stayed hidden. - **Lazy-loaded content appeared without scrolling.** On a test page, an `IntersectionObserver` added 10 items at load on Lightpanda, and none on Chrome before a scroll. With no layout, Lightpanda 1.0.2 reported each observed element as inside the viewport, so a scraper can skip scrolling on pages with a fixed list. On infinite-scroll pages, the page can keep loading instead, as YouTube did in the page test below. - **Layout values differed.** Bounding boxes kept their size but not their position, and CSS `@media` rules didn’t apply after a viewport change. WebGL was unavailable, and `navigator` reported its own values, such as 4 CPU cores. Run flows on Chrome when they depend on dialogs, hover menus, overlays, or element positions. ## [](#What-to-check-before-you-switch-to-Lightpanda-rendering-standards-and-operations)What to check before you switch to Lightpanda: rendering, standards, and operations Each point below applies to Lightpanda 1.0.2, and later releases may change it. **Screenshots show text, not the rendered page.** `page.screenshot()` returns a PNG, but Lightpanda draws only the page’s text in one column, with no CSS layout, images, or colors. `page.pdf()` returns the same kind of output. In this IKEA example, Lightpanda ran with `--load-resources stylesheet`: *Same URL and viewport in both browsers.* Visual regression tests, image-based extraction, and computer-use agents that act on screenshots need a browser that renders the full page, as Browser API did on the right. **A fingerprint that differs from Chrome’s.** Lightpanda sends `User-Agent: Lightpanda/1.0` and, over HTTPS, the client hint `Sec-Ch-Ua: "Lightpanda";v="1"`. Its `--user-agent` flag rejects any value that contains “Mozilla”, and Playwright’s `user_agent` option doesn’t change the header. Its TLS and HTTP/2 fingerprints also differ from Chrome’s. Sites with bot detection can recognize every Lightpanda request, so test those sites at production volume before you move them to Lightpanda. That user agent is right for a crawler that identifies itself. Lightpanda can sign its requests with [Web Bot Auth](https://datatracker.ietf.org/wg/webbotauth/about/) through its `--web-bot-auth-*` flags, and Cloudflare verifies them for bots that register their public key. Verification tells a site who is crawling, and the site still decides whether to allow it. **Fewer web-standards passes than Chrome, especially on CSS.** [Lightpanda 1.0 reports](https://lightpanda.io/blog/posts/lightpanda-1-0) passing about 80% as many subtests as Chrome on the Web Platform Tests (WPT), the cross-browser conformance test suite. Most of those passes were generated character-encoding tests, and with them removed for both browsers, my count gives Lightpanda roughly 57% as many as Chrome. On CSS tests, it passed 24% as many, so expect the largest differences on CSS-heavy pages. **One proxy and one process per server, and one page per connection.** In 1.0.2, `--http-proxy` applies to the whole server, and Playwright’s per-context proxy failed with authenticated proxies. Each connection holds 1 page, and all sessions on a server share one process, so a crash stops all of them. Plan one server per proxy identity and one connection per parallel page. **No native Windows or Alpine build in 1.0.2.** Release 1.0.2 shipped Linux and macOS binaries plus Debian packages, and the project publishes a Docker image. On Windows, Lightpanda runs inside WSL2. Its Linux binaries link against glibc, so they don’t run on stock Alpine, which uses musl. **AGPL-3.0 license.** If you modify Lightpanda and let users interact with it over a network, the license requires you to offer them your modified source. Many companies restrict AGPL software in their open-source license policies even when it runs unmodified, so ask your legal team before you deploy it. **Telemetry is on by default.** Each Lightpanda process sends usage events to `telemetry.lightpanda.io`, with one event for every page or iframe navigation. In 1.0.2, the [event definitions](https://github.com/lightpanda-io/browser/blob/1.0.2/src/telemetry/telemetry.zig) contained no URLs. Set `LIGHTPANDA_DISABLE_TELEMETRY=true` to disable it, for example on servers with strict egress rules. ## [](#Is-Lightpanda-enough-for-your-pages-A-test-on-19-public-pages)Is Lightpanda enough for your pages? A test on 19 public pages A page test shows whether the differences in the 44 checks change your data, by comparing the text that Lightpanda and Chrome return for the same public pages. [Bright Data Browser API](/products/scraping-browser) rendered each page in full Chrome on Bright Data’s infrastructure, geo-targeted to India to match my test connection. That render is the reference for every comparison below. Plain HTTP, Lightpanda, and Lightpanda with the stylesheet flag then fetched each page after the reference, from a residential connection in the same country. Every browser waited until the page’s text stopped changing, as the scripts below do. A distinct word is a unique word of 3 or more letters. The table shows each option’s word recall in 2 runs, which is the share of the reference’s distinct words that the option also returned: PagePlain HTTPLightpandaLightpanda, stylesheet flagWikipedia article98%, 98%99%, 99%98%, 98%MDN reference page100%, 100%100%, 100%100%, 100%Python docs page**86%, 86%**100%, 100%100%, 100%React docs page100%, 100%99%, 99%99%, 99%Next.js docs page**71%, 69%****92%, 88%****78%, 76%**Hacker News100%, 100%100%, 100%100%, 100%BBC News100%, 100%99%, 99%99%, 99%The Verge90%, 91%97%, 97%97%, 100%Medium tag page**0%, 0%****2%, 25%****2%, 22%**GitHub repository**88%, 88%**99%, 99%99%, 99%Vercel pricing97%, 100%97%, 100%97%, 100%Figma pricing95%, 95%99%, 99%99%, 99%IKEA category page93%, 93%100%, 100%91%, 91%Amazon search**0%, 0%**96%, 94%95%, 94%Zara category page**1%, 1%**100%, 100%100%, 100%Booking.com search**0%, 0%****92%, 87%****73%, 72%**YouTube search**1%, 1%****100%, 88%**100%, 99%IMDb Top 250**0%, 0%**94%, 94%94%, 94%TradingView quote page**81%, 91%**95%, 95%94%, 94%At a 90% recall threshold, Lightpanda passed 15 of the 19 pages in both runs with default settings, and 16 with the stylesheet flag. Bold cells are below that threshold in at least 1 run. **The wait mattered as much as the browser.** With a fixed wait of 3 seconds after the DOMContentLoaded event, YouTube returned an empty body and IMDb about a quarter of its chart. Both pages were still rendering. Waiting until the text stopped changing raised both above 90%. *At 3 seconds the page was still rendering, so a fixed wait would have scored it as empty.* Recall does not count extra text, such as hidden menus or prices for other sizes. Extra text lowers precision, costs LLM tokens, and can mislead a model. The stylesheet flag changed both measures: Effect of `--load-resources stylesheet`PagesLess extra text, so higher precision11 of the 19 pagesMore extra textVercel’s pricing page, where precision fell from 78% to 64%, and Booking.comLower recall, by 9 points or moreIKEA, Next.js, and Booking.comSlowerTradingView, about 28 seconds with the flag against about 6 withoutStart with the flag, because it passed one more page than default settings and kept much of the CSS-hidden text out of your data. Medium, YouTube, and Booking.com show 3 different failure modes: - **A page that returned little text.** Medium’s tag page gave Lightpanda at most 179 distinct words, and at most 25% of the words in the Chrome reference. - **A page that keeps loading.** YouTube passed with the stylesheet flag, but it kept adding results, because Lightpanda reported each observed element as inside the viewport. The wait reached its time limit, and half to two-thirds of Lightpanda’s words were extra text that Chrome didn’t show. - **A page the flag made worse.** Booking.com reached 87% to 92% recall with default settings and 72% to 73% with the stylesheet flag. Route pages like Medium and Booking.com to Chrome. On pages like YouTube, where recall stays high but extra text grows, check your fields as well. Prices and item counts need field-level checks, because word recall ignores numbers and can’t show whether a list is complete. On the IKEA and Zara category pages, Lightpanda showed every price that the reference showed. Stores can show a different currency than you expect, so set the currency and delivery location before you compare. This Steam search shows the same results in 2 currencies: *The same Steam search URL through Browser API, with only the geo-targeting country changed.* ## [](#Do-your-pages-need-a-browser-at-all)Do your pages need a browser at all? Many pages are [static or server-rendered](/blog/web-data/static-vs-dynamic-content), so they don’t need a browser. Plain HTTP reached at least 90% word recall on 9 of the 19 pages in both runs. The plain HTTP requests named the crawler in their user agent, so other clients and headers can get different results. Lightpanda with default settings passed 6 more pages. Only Medium stayed below 90% recall in every column and every run. Many pages also embed their data as JSON in the HTML, or load it from the site’s internal API. To a plain HTTP request, 10 of the 19 pages returned JSON-LD or hydration data, such as Next.js `__NEXT_DATA__`, in their HTML. YouTube contained 10 to 19 search results in its `ytInitialData` object, readable without running the page’s JavaScript. The calibration scripts measure visible text and drop `