Why build a new browser?
From intuition to reality

Three years ago when we started Lightpanda, we asked ourselves a seemingly simple question: what would a browser look like if it were built specifically for machines? Not primarily for rendering interfaces built for humans.

We released Lightpanda’s beta in November 2024 and today we’re excited to share more about the technical journey to this point.

Lessons from browsing the web at scale

Lightpanda’s founding team worked together at BlueBoard, a SaaS platform that tracked product visibility and pricing across thousands of e-commerce sites globally. BlueBoard’s infrastructure crawled over 20 million pages per day, relying on a massive fleet of headless Chrome instances orchestrated across dozens of servers.

Maintaining this setup was a constant battle between scaling limits, memory leaks, brittle page loads, and frequent crashes. The browser layer became the most fragile and expensive part of the stack. We spent 15% of our annual revenue keeping this infrastructure online. That was a clear signal: the ecosystem needed a tool built from first principles, designed for automation at scale. Lightpanda is the browser we wish we had back then.

Traditional browsers, like Chrome, are resource-intensive because they are designed for graphical rendering and user interactivity. But headless Chrome, the de facto solution, is suboptimal:

• High resource usage: even in headless mode, Chrome calculates graphical output
• Instability: running multiple instances of Chrome requires frequent restarts
• Cost: scaling headless Chrome-based solutions demands significant hardware resources

What is a web browser?

A web browser is a program that retrieves and displays information from web servers. Typically, browsers perform three key functions:

1. Fetching content: sending HTTP requests to a server and receiving responses
2. Rendering pages: processing HTML and CSS to display visually rich pages
3. Executing code: running JavaScript and interacting with web APIs to enable dynamic content and actions

For Lightpanda, the goal was to address the first and third functions while omitting graphical rendering. The thesis was that this critical difference would unlock efficiencies with a significant order of magnitude and make it well adapted for web automation.

Our first instinct: fork and optimize Chrome

Our initial idea was to start from Chromium (the open-source version of Chrome) and optimize it for machine use. By stripping out graphical rendering and other superfluous components, we hoped to create a lighter browser while benefitting from the battle-tested foundation that would allow us to maintain maximum compatibility with the modern web.

But we quickly ran into the limitations of that approach. Chromium’s codebase is not designed to be modular. Cleanly separating the graphical rendering from the rest of the browser is extremely difficult. Chromium is the product of nearly three decades of development, forks, and layering. Blink (the rendering engine behind Chromium) is a fork of Webkit (Safari), which is a fork of KHTML (Konqueror, a Linux browser now deprecated).

More importantly, we realized that starting from Chrome didn’t allow us to fully follow through on the vision. We didn’t want to hack a human-facing browser for machine tasks. We wanted to design a browser built for machines from the ground up. To do that, we had to take the harder path: building it from scratch.

Technical approach

Building from scratch

Rebuilding a browser, even in headless mode, is a colossal task. It doesn’t make sense if the performance and efficiency gains are not an order of magnitude better than existing solutions. Before we wrote a single line of code, our thesis was that anything less than a 10x improvement would not justify the complexity.

The core architecture of Lightpanda consists of:

1. HTML parsing and DOM manipulation
2. JavaScript engine
3. Networking layer
4. Web APIs
5. CDP server - for compatibility with client script libraries like Puppeteer and Playwright

Language Choice: Zig

A browser needs to be written in a system programming language. We chose Zig for its balance between low-level control and developer-friendly features. Key advantages include:

• Explicit memory management: Zig’s allocators allow fine-grained control over memory usage, which is critical for performance optimization
• Compile-time execution: Zig’s comptime feature simplifies the generation of boilerplate code, reducing runtime complexity and useful to generate the numerous Web APIs
• Interoperability: Zig integrates seamlessly with C/C++ libraries, enabling us to leverage existing solutions like V8 (Javascript engine) and Netsurf libraries (HTML parsing and DOM tree)

Why V8 as a JavaScript engine?

Since building a new browser from scratch is already a massive undertaking, we didn’t want to take on the added complexity of developing a new JavaScript engine. Instead, we chose to integrate an existing one: V8, the JavaScript engine used in Chrome and Node.js. It was selected for its:

• Performance: optimized for executing modern JavaScript
• Documentation and Ecosystem: a rich ecosystem of resources and examples
• Flexibility: well-suited for embedding into custom applications, and it’s also able to execute WASM code

Like any technical choice, this one comes with trade-offs. V8 is a powerful engine, but it’s also large and complex. In the future, we may explore lighter alternatives for more constrained or specialized use cases.

Web APIs: scope and prioritization

Modern web browsers implement over 300 web APIs, encompassing thousands of methods and types. For the beta version of Lightpanda, we prioritized APIs essential for web automation, such as:

• DOM manipulation: accessing and modifying HTML elements.
• XHR and Fetch: handling asynchronous HTTP requests.
• Basic JavaScript functions: supporting common operations needed by automation scripts.

Validating the vision

After several months of development, perseverance and belief in the vision, we reached a key milestone. Our early results confirmed both the performance hypothesis and the technical feasibility of building a browser from scratch.

To validate behavior against web standards, we integrated the Web Platform Tests  into our development pipeline. Maintained collaboratively by browser vendors, these tests helped us identify missing APIs and ensure consistent implementation across supported features.

On a representative test page, Lightpanda is 11 times faster than headless Chrome and uses 9 times less memory. Startup time, a critical factor in serverless and CI/CD contexts, is nearly instantaneous. In our benchmarks, Lightpanda launches over 30 times faster than Chrome.

These results were not achieved by optimizing around a single bottleneck. They reflect the cumulative impact of rebuilding the browser architecture. By removing the graphical layer, designing specifically for automation use cases, and choosing a high-performance system language, we validated that a fundamentally more efficient browser is possible.

Beyond performance

With this foundation in place, we now have all the core building blocks needed to fulfill our vision: a browser purpose-built for machines. The next step is to expand our web API coverage in order to improve compatibility across a broader range of websites.

Just as importantly, building our own browser has given us deep control over the web automation stack. This unlocks new possibilities, such as a native MCP server to control the browser remotely and LLM-friendly output formats to facilitate integration with AI agents. These are the kinds of features that are difficult to build cleanly on top of traditional browsers. They require deep integration, which is only possible when you control the stack end to end.

Lightpanda is open source and available on GitHub . Feel free to reach out with questions or explore the repo for more technical details.