Lowest Session Startup Latency: How to Measure and Cut It

The checkout tests passed on the new runner, but the suite took noticeably longer than it had on a laptop, and nobody could point to a slow page. The trace viewer settled it: every test sat idle before any request went out, while a browser came up somewhere else.

That idle stretch is session startup latency, the time between asking for a browser and being able to drive it, paid again on every task an agent or a test opens. The lowest startup comes from two things together: a provider that starts browsers fast, and a session that asks for nothing the task does not need. Solari browsers are ready in 8 ms, and this guide shows how to measure startup on your own workload and the four settings that keep it low.

What Session Startup Latency Includes

Before cutting startup, it helps to agree on where it begins and ends. A headless browser service has to create the session, and the agent's client then attaches to it through Playwright or any client that speaks the Chrome DevTools Protocol. Only after create and connect can the agent send a navigation.

Everything after that belongs mostly to the website being loaded. That is why a slow page and a slow start look alike in an end-to-end number, and why the measurement in the next section splits them apart.

How to Measure Startup on Your Own Workload

A measurement worth trusting times each step separately, from the machine where the agents actually run. In Node, performance.now() reads a monotonic, high-resolution clock, which suits short intervals like these. The snippet below times create, connect and the page load on a Solari session, with the release in a finally block so a failed run still closes.

import { chromium } from "playwright-core"
import { Solari } from "@solarisdk/browser"

const client = new Solari({ apiKey: process.env.SOLARI_API_KEY! })
const target = process.env.TARGET_URL!

const start = performance.now()
const session = await client.sessions.create()
const created = performance.now()
const browser = await chromium.connectOverCDP(session.cdpEndpoint)
const connected = performance.now()
try {
  const page = await browser.newPage()
  await page.goto(target)
  const loaded = performance.now()
  console.log({ create: created - start, connect: connected - created, goto: loaded - connected })
} finally {
  await browser.close()
  await client.sessions.releaseAndWait(session.id)
}

import { chromium } from "playwright-core"
import { Solari } from "@solarisdk/browser"

const client = new Solari({ apiKey: process.env.SOLARI_API_KEY! })
const target = process.env.TARGET_URL!

const start = performance.now()
const session = await client.sessions.create()
const created = performance.now()
const browser = await chromium.connectOverCDP(session.cdpEndpoint)
const connected = performance.now()
try {
  const page = await browser.newPage()
  await page.goto(target)
  const loaded = performance.now()
  console.log({ create: created - start, connect: connected - created, goto: loaded - connected })
} finally {
  await browser.close()
  await client.sessions.releaseAndWait(session.id)
}

import { chromium } from "playwright-core"
import { Solari } from "@solarisdk/browser"

const client = new Solari({ apiKey: process.env.SOLARI_API_KEY! })
const target = process.env.TARGET_URL!

const start = performance.now()
const session = await client.sessions.create()
const created = performance.now()
const browser = await chromium.connectOverCDP(session.cdpEndpoint)
const connected = performance.now()
try {
  const page = await browser.newPage()
  await page.goto(target)
  const loaded = performance.now()
  console.log({ create: created - start, connect: connected - created, goto: loaded - connected })
} finally {
  await browser.close()
  await client.sessions.releaseAndWait(session.id)
}

Run it many times and compare medians, because a single sample mostly measures the network on that second. The snippet logs timings only, which matters for the next point: once startup has its own number, the settings below show where it comes from.

Keep the Session Bare Unless the Site Needs More

The first setting is what the session is asked to do at create time. Every Solari session option is opt-in, and the default is a fast headless browser with no profile, recording, proxy or stealth.

Stealth, proxies, CAPTCHA solving and recording exist for specific sites and specific runs, not for every task. Turn them on per site, for the hosts that block automation or the runs that need a replay, and leave the rest of the fleet on the default. Once the session is lean, the next cost is how the client talks to it.

Use the Faster Connection Path

How the agent attaches to a session matters on every action, not only the opening one. Solari's launch() opens a browser and connects to it in a single call, and it is a bit faster per action than connecting a separate client to cdpEndpoint. To compare, time launch() as a single step against create plus connect from the snippet above.

Teams that already run Puppeteer or browser-use can keep them on cdpEndpoint, or move to wsEndpoint, which is also a bit faster per action and needs a matching, pinned patchright-core client. Both URLs are credentials: anyone holding one can drive the browser until it is released, so they stay out of timing logs. For most agents, though, the larger saving is not in the connection at all.

Skip the Sign-In With Profiles

An agent that has to log in before it works pays a startup cost no provider can remove on its own: the sign-in form. Solari profiles save a login with its cookies and localStorage data in Playwright's storageState format, so a session created with a profileId starts already signed in.

There is a rule that trips people up here. A profile seeds only the session's default context, so the agent should use session.context or session.newPage() from launch(), not browser.contexts()[0], and a context it creates itself does not carry the login. With logins handled, the remaining startup question is about machines rather than pages.

Resume Machines Instead of Rebuilding Them

Agents that run code or drive a full screen start a machine, and there the lowest startup is often not starting at all. Solari sandboxes spin up in 90 ms and a Solari desktop is usually ready in about a second, but a machine that has installed packages and opened apps holds far more setup than its boot.

Pausing a VM saves its state, and the next connect() picks up where it left off; a same-host resume took about 1.3 seconds on staging, five trials. Resume queues behind a pause that is still saving its snapshot, so calling it once the pause has settled is the faster path. For short waits inside a task, parkAfterMs freezes the VM's CPUs while its slot and connection stay held, so the next action wakes it with nothing to restore.

Choosing the Right Setup

The lowest session startup latency comes from measuring create and connect on their own, then removing every cost the task does not need. Keep sessions bare by default, connect through launch(), let profiles carry the login, and resume machines rather than rebuild them. A companion piece compares vendors on the same create, connect and release loop, and Introducing Solari covers the platform behind all three surfaces.

Get Started With Solari

Start by running the timing snippet against a free Solari account from the region your agents run in, then add a profile and only the options each site needs, and time it again. Solari is the fastest start for this job at the 8 ms figure above, and about 2x cheaper per browser hour than Browserbase at the list prices on Solari's pricing page. The Free plan includes $3 of monthly credits, so create a free Solari account and measure startup on your own workload.