How DeveloperHub.io cut prerender load by 10x

Katie Brown

Cofounder & COO

TL;DR

Zaid Daba’een , CEO & Founder of DeveloperHub.io , switched his self-hosted prerender  deployment to use Lightpanda instead of headless Chrome. The result on his production infrastructure: pages serve 4x faster, instance load average dropped 10x, scheduled restarts went away, and the CPU alarms stopped. We collaborated to resolve two upstream issues along the way to allow the switch in production.

Why prerendering is still painful in 2026

If you run a JavaScript-heavy site and you care about being found by Google or AI crawlers, you have probably looked at prerendering. Crawlers either struggle with client-rendered content or take much longer to index it. Prerendering is the fix: a service runs the page in a real browser, waits for the JavaScript to finish, and serves the rendered HTML to bots.

The reference implementation is the open-source prerender Node server , which loads URLs in headless Chrome and returns the rendered HTML over HTTP. It runs on headless Chrome.

Chrome is heavy and painful to deploy at scale and slow in production and CI environments. Using Lightpanda means you can use a smaller server for a faster result.

DeveloperHub swapped its prerender layer

DeveloperHub.io  is a documentation platform used to publish their developer docs and API references. The customer-facing docs are JavaScript-rendered, which means crawlers need a prerendered version to read them properly. So like a lot of teams, DeveloperHub self-hosts the open-source prerender server, which has been running on Chrome for years.

Before switching to Lightpanda, Zaid filed two issues covering the gaps he needed closed.

The first, #1947 , was straightforward: his customers’ docs sites are built with Angular, and Lightpanda did not handle the Angular SPA loading pattern cleanly yet. We fixed it.

The second, #2029 , asked for something we had deliberately not allowed: overriding the User-Agent header. Our default position is that Lightpanda should identify itself as Lightpanda. But this use case was legitimate: DeveloperHub’s customers are enterprises, and their WAFs only allow a defined set of User-Agents through. Without a way to set a specific UA like DeveloperHub.io SSR, Lightpanda was simply blocked at the edge.

The compromise landed in PR #2100 . You can now pass --user-agent to override the full User-Agent string, with one restriction: any value containing mozilla (case-insensitive, anywhere in the string) is rejected. That rules out impersonating Chrome, Firefox, Safari, Edge and the long tail of real browsers. It leaves room for legitimate operator-defined User-Agents like DeveloperHub.io SSR. Lightpanda also always sends the Sec-Ch-Ua client hint header with "Lightpanda";v="1", so the browser’s real identity remains discoverable to servers that care to check.

The production numbers

With those PRs merged, DeveloperHub could switch their prerender deployment to use Lightpanda underneath. They ran it in production and sent us the numbers:

I’ve been using Prerender with Chrome for many years to prerender pages served by us, and handling the load was a pain vs cost of running the service. I’ve now completely switched to using Lightpanda, rewriting prerender entirely. This change serves pages 4x faster (a conservative estimate, it’s often closer to 6x) and lowering load average by 10x. Instances no longer require a restart, and I’m not receiving CPU alarms anymore. That’s one hell of a piece of software.

Zaid Daba’een , CEO & Founder, DeveloperHub.io 

Three concrete things shifted in DeveloperHub’s infrastructure when they made the switch from Chrome to Lightpanda.

Pages serve 4x faster. This is the time from a render request hitting the prerender service to the HTML coming back. DeveloperHub has set it up to debounce 250ms after every network request before considering the page “done” to ensure that any dynamic content has really finished loading. Faster prerendering means crawlers wait less, which translates directly into better crawl budget utilisation and faster indexing of new and updated pages.

Load average dropped 10x. Load average is the most honest metric for understanding how stressed a server actually is. A 10x drop means the same instance can absorb far larger spikes before it starts queuing work. Or, put differently, you can run far smaller instances for the same workload. That is the cost story behind the performance numbers.

DeveloperHub is running five concurrent page renders at the same time, which they weren’t able to do previously. This setup clears up the request queue much faster than one render per instance. With five concurrent page renders, load average for 1m is sitting at 0.12, compared to >1 previously.

The scheduled restarts went away, and the CPU alarms with them. Anyone who has run a Chrome-based service in production knows the pattern. Memory creeps up, performance degrades, you set a cron job to restart the workers every few hours to flush whatever is leaking. CPU spikes wake you up at 3am. Lightpanda runs without needing this, because the engine was designed for sustained automation workloads from day one.

Why this is an ideal workload for Lightpanda

Prerendering is the textbook case for what Lightpanda is good at. You fetch a page, you execute the JavaScript, you read the rendered DOM, you return the HTML. The output goes to a crawler, not a human, so every cycle Chrome spends on layout, paint and compositing is a cycle wasted.

Lightpanda’s engine has the parts you actually need for automation (HTTP, HTML parsing, a real DOM, V8) and CDP compatibility so existing tooling works without code changes. There is no graphics pipeline at all. On our public benchmarks , that translates to 16x less memory and 9x faster execution than headless Chrome on equivalent workloads. DeveloperHub’s production numbers (4x faster page serving, 10x lower load average) are what those engine-level wins look like once you account for everything else in a real prerender pipeline: HTTP overhead, network latency, the Node layer on top.

Try it on your own prerender setup

If you run prerender (or a similar service) and the cost of Chrome is hurting you, the swap is simple. Lightpanda implements the same Chrome DevTools Protocol as Chrome, so existing clients connect over WebSocket and behave the same way

You can run Lightpanda locally with Docker:

docker run -d --name lightpanda -p 127.0.0.1:9222:9222 lightpanda/browser:nightly

Then point your prerender server (or your Puppeteer / Playwright code) at ws://127.0.0.1:9222 instead of launching a Chrome process. The quickstart guide  walks through it end to end and takes about 10 minutes.

If your workload uses something Lightpanda does not yet support, open an issue on GitHub  or send a PR. We move fast on real use cases.

Try Lightpanda on your prerender pipeline

The quickest path is the 10-minute quickstart . If you want to talk through your setup first, get in touch at hello@lightpanda.io.

FAQ

What is prerendering and why do sites need it?

Prerendering is the practice of running a JavaScript site in a real browser, waiting for it to finish rendering, and then serving the resulting HTML to crawlers. Search engines and AI crawlers either cannot execute JavaScript or take significantly longer to index pages that require it. Prerendering gives them a static HTML version while real users still get the full client-rendered experience.

What is the prerender server?

The prerender open-source Node server  is a long-standing reference implementation for dynamic rendering. It exposes an HTTP endpoint that takes a URL, loads it in a headless browser, waits for the network to go idle, and returns the rendered HTML. It is the same project the prerender.io SaaS originally grew from, and it is self-hosted by teams who want to run their own prerender infrastructure.

Does Lightpanda work as a drop-in replacement for headless Chrome in a prerender setup?

Lightpanda implements the Chrome DevTools Protocol, so existing clients (Puppeteer, Playwright, the prerender server, custom CDP code) connect to it the same way they connect to Chrome. Switching the engine may require some upstream work on Lightpanda first. In this case that meant user-agent and Angular handling, and a rewrite of the prerender layer to talk to Lightpanda instead of launching Chrome processes. For simpler setups, the change can be as small as updating the WebSocket URL.open

Why is Chrome so heavy for prerendering specifically?

Chrome calculates layout, paint, and compositing even in headless mode. None of that work matters when the consumer of the output is a crawler reading HTML. You are paying for a full graphical pipeline you never use. Lightpanda has no rendering pipeline at all, which is why the memory and CPU footprint is an order of magnitude smaller for the same JavaScript execution work.on

Does Lightpanda support every site that Chrome supports?

Not yet. We are in beta and Web API coverage is increasing every release. Many real-world sites work today, but you may hit gaps. The right approach is to test on your own URLs early and open an issue if something breaks. The free tier of Lightpanda Cloud  is designed for exactly this kind of testing.

Where can I see the source code?

Lightpanda is open source on GitHub . The two issues relevant to this use case are #2029  and #1947  if you want to see what kind of changes were needed to make a prerender workload work end to end.

Katie Brown

Cofounder & COO

Katie led the commercial team at BlueBoard, where she met Pierre and Francis. She rejoined them on the Lightpanda adventure to lead GTM and to keep the product closely aligned with what developers actually need. She also drives community efforts and, by popular vote, serves as chief sticker officer.