VLearnVibium

Fix: Slow Vibium Performance

Fix slow Vibium performance — run headless, pre-download Chrome, reuse one session, use precise selectors, and tune timeouts for fast runs.

By Pramod Dutta··4 min read·Verified with Vibium 26.2
▶ Animated overview · made with Remotion

To fix slow Vibium performance, run headless for unattended work, pre-download Chrome with vibium install, reuse a single browser session instead of relaunching, use precise selectors, and tune action timeouts. Vibium is AI-native browser automation on a single Go binary that drives real Chrome over WebDriver BiDi, so it is already fast — most "slowness" comes from a handful of avoidable patterns rather than the engine. The biggest culprits are a one-time Chrome download on first run, relaunching the browser for every page when one session would do, running a visible window when headless would be faster, and scripts that silently wait out the full 30-second default timeout because a selector never matches. Vibium's actionability checks auto-wait for elements, which removes flaky sleep() calls, but a wrong selector turns that helpful wait into a 30-second stall. Created by Jason Huggins, co-creator of Selenium and Appium, Vibium gives you simple levers — headless mode, session reuse, sharper selectors, and per-action timeouts — that together make a slow script fast.

Why is my Vibium script slow?

Slow Vibium runs almost always trace to one of four causes: a one-time Chrome download on the first run, relaunching the browser per action instead of reusing a session, running headed when no window is needed, and waiting out the default 30-second timeout because a selector never matches. None of these are engine problems — each has a direct fix below. Start by identifying which one applies, because the fixes are different: a slow first run points to the download, while a script that is slow every time points to session reuse, headless mode, or selectors.

How do I fix a slow first run?

A slow first run happens because Vibium downloads Chrome for Testing the first time you launch. Pay that cost once, ahead of time, by pre-downloading the browser during setup:

pip install vibium
vibium install   # pre-download Chrome for Testing now, not on first launch

In Docker or CI, run vibium install in the image build step so containers never download Chrome on a cold start. After this, every launch starts immediately because the browser is already cached locally.

How do I make Vibium run faster overall?

Two launch-time changes give the biggest wins: run headless, and reuse one session for all your work instead of launching the browser repeatedly. Headless Chrome skips rendering a visible window, and a single session avoids paying browser startup over and over:

from vibium import browser_sync as browser
 
vibe = browser.launch(headless=True)   # no visible window = faster, lighter
try:
    for url in ["https://example.com/a", "https://example.com/b", "https://example.com/c"]:
        vibe.go(url)                   # reuse the SAME session for every page
        print(vibe.find("h1").text())
finally:
    vibe.quit()

Launching once and looping is far faster than calling browser.launch() inside the loop, which would start and tear down Chrome on every iteration. Keep headed mode (headless=False) only for local debugging when you actually want to watch the browser.

How do selectors and timeouts affect speed?

A script that is slow on a specific step is usually waiting out the full 30-second default timeout because its selector never matches. Vibium auto-waits for an element to become actionable, which is a feature — but if you target the wrong element, that wait becomes a 30-second stall before it finally errors. Use precise selectors so matches resolve instantly, and lower the timeout where a fast failure is better than a long hang:

from vibium import browser_sync as browser
 
vibe = browser.launch(headless=True)
vibe.go("https://example.com")
 
# Precise selector resolves immediately instead of scanning loosely.
vibe.find('button[data-testid="submit"]').click()
 
# Fail fast on an optional element instead of waiting the full default.
vibe.find("#promo-banner", timeout=2000).click()
 
vibe.quit()

Prefer stable attributes like data-testid or an id over brittle, deep CSS paths. Trust Vibium's auto-wait via find() instead of adding time.sleep() calls, which always cost their full duration even when the page was ready sooner.

Tips for fast, reliable runs

  • Pre-download Chrome with vibium install so first runs are instant.
  • Run headless=True for any unattended or CI work.
  • Reuse one session — launch once, loop your pages, quit once.
  • Use precise selectors so matches resolve immediately instead of stalling.
  • Lower per-action timeouts on optional elements to fail fast instead of waiting 30 seconds.

For the full performance and configuration reference and any options you are unsure about, see the official docs at vibium.com and github.com/VibiumDev/vibium.

Next steps

Frequently asked questions

Why is my Vibium script slow?

The most common causes are a slow first run while Vibium downloads Chrome, relaunching the browser for every action instead of reusing one session, running headed when you do not need a window, and waiting on the full default timeout because a selector never matches. Each is a quick, targeted fix.

Does running Vibium headless make it faster?

Yes. Headless Chrome skips rendering a visible window and is typically faster and lighter than headed mode, especially on servers and in CI. Launch with browser.launch(headless=True) for unattended runs and keep headed mode only for local debugging where you want to watch the browser.

How do I avoid slow first runs in Vibium?

Vibium downloads Chrome for Testing on first launch, which makes the very first run slow. Pre-download the browser once with vibium install during setup or your image build so the download cost is paid ahead of time and every later run starts immediately.

Vibium is created by Jason Huggins. This is an independent tutorial — see the official Vibium site and GitHub repo for canonical docs.

Related guides