Trimmed Build: 62% Faster Context Spin-Up on Linux x64

Why Build Choice Matters at High Concurrency

BotBrowser's fingerprint protection model is the same in every release. Profiles are the same, per-context fingerprint behavior is the same, the CLI flag surface is the same. What changes between builds is what the browser does around that protection model: how long the startup path takes, how many seconds it costs to spin a context up to first navigation, how much CPU a context burns at peak, and how much shared memory a fleet retains over a long run.

For long-running interactive sessions, this overhead is small relative to total session time. For short-session privacy workloads that create a context, load a small number of pages, and rotate to the next identity within seconds to minutes, this overhead is the workload. A 400ms saving per context turns into hours of saved wall time per day.

This is the question Trimmed Build answers.

What Trimmed Build Is

BotBrowser ships in two builds:

• Standard Build is the default distribution with the full browser feature surface. Long-running sessions, interactive workflows, and scenarios that exercise the full surface should stay on Standard.
• Trimmed Build is an ENT Tier 3 distribution tuned for short-session, high-concurrency automation. It preserves the same fingerprint protection model, the same Per-Context Fingerprint behavior, the same profile compatibility, and the same CLI flag surface. What changes is the runtime cost around the protection model.

Trimmed Build ships through the enterprise distribution channel, alongside Per-Context Fingerprint and Dynamic Per-Context Proxy Switching. The Standard Build release on the public download channel is unchanged.

The Linux x64 Benchmark

The numbers in this article come from a controlled comparison of BotBrowser 148 Standard vs BotBrowser 148 Trimmed on the same Linux x64 host, using the same benchmark matrix, the same build-matched public profile bundle, the same per-context flags, the same external target, and the same sampling cadence.

The matrix:

• 1..20 contexts per repeat
• 10 repeats per context count per build
• 2 builds
• Total: 400 official samples
• Both profiles verified to support per-context flags, per-context proxy, proxy auth, and custom headers before the matrix started
• Process metrics sampled every 250ms; CPU from Linux process accounting; RSS/PSS/USS from process memory rollups
• Every repeat closed the browser and checked for residual Chromium processes

For the complete table and methodology, see the Trimmed Build section in the public benchmark page.

Headline Numbers

Negative percentage means Trimmed is faster or lighter than Standard.

Metric	Standard mean	Trimmed mean	Delta
Wall time (ms)	7,262.91	2,771.09	-61.85%
Avg create ms/context	443.44	65.10	-85.32%
Avg first nav ms/context	2,456.19	1,505.45	-38.71%
CPU avg %	4.12	1.83	-55.42%
CPU peak %	25.77	8.29	-67.81%
PSS peak KB	960,327	660,188	-31.25%
USS peak KB	800,760	497,876	-37.82%
Success rate	100%	100%	unchanged
Residual processes	0	0	unchanged

Three properties of this table matter as much as the percentages themselves:

1. Per-context creation falls 85% on average and 87.51% at p95. This is the dominant lever for short-session workloads, where context spin-up is repeated thousands of times per shift.
2. CPU peak falls 68%. Peak CPU per context, not average, is what limits how many concurrent contexts a host can sustain before scheduler contention starts to add latency.
3. Success rate stays at 100% and residual processes stay at 0. The reduction is a runtime cost reduction, not a stability or cleanup regression.

The Gap Is Stable Across All Context Counts

The per-context matrix shows Trimmed Build is faster than Standard at every context count from 1 to 20 on every dimension that matters:

• Wall time delta ranges from -44.44% (at 2 contexts) to -69.83% (at 13 contexts).
• Per-context creation delta ranges from -79.76% (at 16 contexts) to -88.33% (at 2 contexts).
• First navigation delta ranges from -29.05% (at 16 contexts) to -52.51% (at 1 context).
• CPU avg delta ranges from -34.23% to -95.52%. CPU peak delta ranges from -51.68% to -97.09%.
• PSS peak delta sits between -27.89% and -32.83% across the full range.

The gap does not collapse at high concurrency, and it does not collapse at low concurrency.

Memory: Peak vs Stable

The memory savings split into two regimes. Peak (the worst single sample during a repeat) and stable (the steady-state sample after the fleet has settled):

• Peak: PSS -31.25%, USS -37.82%. This drives how much headroom a host needs to avoid OOM under bursty load.
• Stable: PSS -22.74%, USS -29.37%. This drives how dense a fleet can pack onto a single host over a long shift.

Both regimes drop materially. If RSS is the binding constraint on your hardware sizing, this matters more than the wall-time numbers.

Process Hygiene

Process counts are not reduced because main browser, network service, GPU, and utility processes are unchanged. Renderer count scales with context count in both builds. What changes is the peak process count during context churn: mean 26.27 → 19.50, median 27.00 → 19.50, p95 40.10 → 28.05. A smaller peak means less file-descriptor pressure during repeated context create-and-destroy cycles.

When to Choose Trimmed Build

The decision is workload-driven, not host-driven. Trimmed Build is the right pick when:

• Context spin-up dominates total wall time. Short-session privacy testing, single-page consistency checks, and high-rotation per-context fleets all fit here. The -85% per-context creation delta is the headline.
• CPU peak per context is the bottleneck. Hosts that already run at high CPU utilization see the -68% peak delta translate directly into more concurrent contexts per host.
• Shared memory (PSS/USS) is the binding constraint. Memory-pressured hosts see -31% to -38% peak headroom returned.
• Workloads rotate through many identities per hour. Each context lives seconds to minutes before the next identity takes over. The shorter the per-context lifespan, the larger the Trimmed advantage.

Standard Build remains the right pick when:

• Sessions are long-running and interactive.
• The workload exercises the full browser feature surface.
• The host has plenty of memory and CPU headroom, and per-context spin-up is not the bottleneck.

What Stays the Same

Trimmed Build does not change the protection model. Everything below remains identical to Standard Build:

• Fingerprint protection: Canvas, WebGL, WebGPU, Audio noise, font fallback policy, Client Hints, and the full set of profile-controlled signals behave the same.
• Per-Context Fingerprint: BotBrowser.setBrowserContextFlags works the same. Per-context proxy, per-context locale/timezone/language, and per-context noise seeds work the same.
• Profile compatibility: A profile that loads cleanly in Standard loads cleanly in Trimmed.
• CLI flags: The --bot-* and standard Chromium flags work the same.
• CDP surface: BotBrowser CDP commands behave the same.

You do not change how you write automation code when you move from Standard to Trimmed.

How Trimmed Fits Into ENT Tier 3

ENT Tier 3 is the deepest enterprise track. It already unlocks:

• Per-Context Fingerprint: 100+ fingerprint identities in a single browser process, with verified canvas isolation and 29% memory savings versus multi-instance at 50 concurrent profiles.
• Dynamic per-context proxy switching: change a context's proxy at runtime without recreating the context.
• Mirror: distributed privacy verification across multiple browser instances.
• Trimmed Build: the short-session distribution described in this article.

The three capabilities compose. A high-density privacy workload running on Trimmed Build with Per-Context Fingerprint and runtime proxy switching is the densest deployment shape BotBrowser ships. At 50 concurrent profiles on a Linux x64 host, this configuration combines the 29% per-context memory savings with the 62% Trimmed wall-time reduction and the 85% per-context spin-up reduction.

Scope Notes

Linux x64 is the deployment shape Trimmed Build is built for: short-session, high-concurrency Ubuntu fleets are where the gap is largest. The benchmark includes external navigation and uses a fixed matrix for both builds. Profile bundles, host class, launch flags, and target endpoint were held identical between builds; runtime credentials, proxy pool, and absolute paths are intentionally omitted from this customer-facing report.

Getting Trimmed Build

Trimmed Build is part of the ENT Tier 3 enterprise distribution. It is not available on the public download channel. For access, see the Enterprise page or Pricing for tracks and engagement model, or contact enterprise sales directly.

For the full product overview, engineering design, and FAQ, see the Trimmed Build documentation. For implementation patterns at high concurrency, see Scaling Browser Contexts: 100+ Identities Per Machine and the Per-Context Fingerprint documentation. For the full benchmark methodology, see the Performance Benchmark page.