# Does Loadster load test with real browsers or headless browsers?

> Loadster's Browser Bots run real Chrome in headless mode: a full browser engine with real rendering and JavaScript, just without a visible window.

Source: https://loadster.com/faqs/real-browsers-vs-headless/

Loadster uses real browsers in headless mode, so both descriptions are accurate.
Each Browser Bot runs a complete Chrome browser that parses HTML, executes JavaScript, and loads page resources, but
doesn't draw a visible window. "Headless" simply means the browser runs without a graphical user interface that anyone
can see (after all, the bots are running out in the cloud with no monitors attached).

## What "Headless" Actually Means

A headless browser isn't a stripped-down imitation of a real browser. Headless Chrome uses the same browser engine,
networking stack, and JavaScript engine as desktop Chrome, but runs with the on-screen display disabled.

Running in headless mode saves some of the resources required to continuously display and paint a visible browser
window, which makes it more practical to run large numbers of browsers at the same time. It still preserves the behavior
that matters for load testing: real network connections, JavaScript execution, resource loading, and front-end timing.
From your server's perspective, the requests look identical to traffic from a real user browsing with Chrome.

## Real Browsers vs Protocol-Level Simulation

When it comes to load testing, the more important distinction is between real browsers and protocol-level
simulation.

[Browser Bots](https://loadster.com/manual/browser-scripts/) each drive a full Chrome browser, execute your application's JavaScript, and
load the page resources. This exercises your site much like a real user would and captures front-end timing, but it also
requires significantly more computing resources because every bot runs its own browser.

[Protocol Bots](https://loadster.com/manual/protocol-scripts/) don't run a browser at all. Instead, they send HTTP requests directly, which
requires far fewer resources per bot and makes them a good choice for testing APIs or generating very large request
volumes.

Loadster customers have run tests with more than 170,000 concurrent Chrome browsers, while Protocol Bots can
scale into the millions. For more information about very large load tests, check out the FAQ
on [how many concurrent bots Loadster can run](https://loadster.com/faqs/maximum-concurrent-bots-or-virtual-users/) for more about what
affects these numbers.

You can mix both types of bots in the same test. For example, you might cover your most important or complicated
user flows with Browser Bots while using Protocol Bots to generate additional background traffic or hammer an API at
the same time.

## Headless Browsers in Playwright Load Testing

If you write [Playwright scripts](https://loadster.com/manual/playwright-scripts/), the same principle applies: Loadster runs your
Playwright Test code against real headless Chrome browsers, with one browser per bot. This is similar to the typical
Playwright workflow, where you might develop and debug with a visible (headed) browser locally and then run headless
browsers in your CI system.

Headless execution doesn't mean giving up real browser behavior. Whether you build scripts in Loadster's
editor or bring your own Playwright tests, [real browser load testing](https://loadster.com/use-cases/playwright-load-testing/) in Loadster
uses full browsers without requiring a physical screen to be attached.