BAS Is Slow and Eating Memory: Speeding Up a Bot and Cutting Resource Use

“BAS is slow” and “BAS eats memory” are almost always the same complaint: a browser is an expensive tool, and the bot pays full price for it even where a fraction would do. The good news is that optimising this rarely means rewriting logic - usually it means no longer loading what you never look at.

Measure first, fix second

The most common mistake is optimising blind. Before changing anything, answer one question: where does the time in a single iteration actually go?

Stamp timings around the key steps and write them to the log. The picture is nearly always the same: 80% of the time is waiting, not working. Waiting for page loads, fixed pauses, waiting for elements. That changes the plan - polishing logic is pointless when the bot spends two thirds of the iteration standing still.

Memory works the same way. “Uses a lot” is not a diagnosis. Does consumption grow over time (a leak) or is it steadily high from minute one (simply many threads)? Different problems.

Do not load what you never look at

The fastest win available. A bot that scrapes text still downloads images, fonts, analytics and ads - bandwidth, time and memory spent on things it will never see.

Blocking image loading on heavy sites saves multiples: a page with a gallery can weigh several megabytes for one kilobyte of useful text. It is configured in the network settings, and on slow proxies the effect is even more pronounced, because every extra megabyte becomes seconds.

Be careful where a site inspects behaviour: a browser that never requests a single image or font has an unusual request profile. On sensitive platforms that is one more signal.

The biggest win: not launching a browser

The key optimisation question is blunt: do you need a browser at all?

You need one when rendering matters: content drawn by JavaScript, bot protection, clicks on UI, complicated login flows. But a large share of tasks are just “request data, parse response”. There the HTTP client buys multiples rather than percentages: per-thread cost drops from hundreds of megabytes to single digits, and you can run an order of magnitude more threads.

The pragmatic middle ground is a hybrid: use the browser once to log in, capture the cookies, then do the rest over HTTP with those cookies. The heavy part runs once, the light part runs a thousand times.

Leaks on long runs

If memory use climbs hour over hour, that is not “just how BAS is” - it is accumulation. The usual sources:

• Tabs you never closed. Every open tab holds memory until the thread ends. Opened it, close it.
• Bloated profiles. Cache, cookies and history pile up between runs; a profile alive for months grows to hundreds of megabytes.
• Lists held in memory. Accumulating results in a variable and writing the file at the very end is a bad idea on long runs: it burns memory, and a crash costs you everything. Write in batches.
• Orphaned browser processes. After a thread crashes, the process can survive. They are invisible in the interface but still hold memory.

A good leak test: measure consumption at 10 minutes and at 2 hours. Stable numbers mean you simply have many threads. Growth means you have accumulation from the list above.

Waits matter more than they look

A fixed pause is the most expensive way to wait. It is either longer than needed (and you lose that time every iteration) or shorter (and you get “element not found”).

Replacing fixed pauses with waiting on events usually pays more than any other single change: a page that arrived in 0.4 seconds does not make the bot stand there for the allotted three. Across a thousand iterations that difference becomes hours.

The flip side: you cannot remove all pauses. A bot clicking with zero delay looks inhuman - idle emulation exists precisely for that. Optimise technical waits, not behavioural ones.

What to do, in order

If the bot is slow and you do not know where to start:

1. Time the steps - find where the time really goes.
2. Replace fixed pauses with event waits wherever possible.
3. Block images and other unused resources.
4. Check whether part or all of the work can move to HTTP.
5. Only then add threads.

The order matters. Adding threads to an unoptimised iteration multiplies the inefficiency: you spend memory on copies of a bot that spends two thirds of its time waiting.