You start a batch of fifty prompts, switch to your inbox, come back twenty minutes later and find the queue barely moved. Nothing is broken. The browser did exactly what it was designed to do.

Background tabs are deliberately slowed down

Modern browsers aggressively throttle tabs that are not visible. Timers fire far less often, animation frames stop entirely, and work that depends on the page actually rendering simply does not happen. Chrome has tightened this behaviour over successive releases, and the reason is sound: a laptop with thirty open tabs would otherwise burn battery running work nobody is looking at.

For most browsing this is invisible and helpful. For automation that drives a real interface, it is the difference between a queue that runs and a queue that crawls.

Why Grok is affected more than most

Grok generates in the page. The extension does not call a private API behind the scenes, it drives the same interface you would drive by hand: it fills the prompt box, submits, waits for the result to render, then collects it. Every one of those steps depends on the page being alive and painting frames.

Hide the tab and the page stops painting. The extension is still there and still willing, but the thing it is waiting for never arrives until you look at the tab again.

The extension is not slower in the background. The page it is driving has effectively been paused underneath it.

What actually works

You cannot switch this throttling off from inside an extension, and you would not want a tool that could. What you can do is arrange things so the Grok tab never becomes a background tab in the first place.

  • Use a second window, not a second tab. This is the fix that solves it for most people. A separate browser window with the Grok tab active stays visible even while you work in another window on top of it. Tabs within one window compete; windows do not, as long as the Grok window is not fully covered on some systems.
  • Give it a second monitor. If you have one, park the Grok window there and forget about it. Nothing ever covers it, so nothing ever throttles it.
  • Run long batches on a spare machine. An old laptop doing nothing but draining a queue is the most reliable setup there is.
  • Do not minimise. A minimised window is the one case that reliably stalls everything, on every platform.

Things that do not help

A few suggestions circulate that are worth skipping. Playing a silent audio file to keep the tab "active" does not restore rendering. Extensions that claim to disable throttling generally cannot affect another tab's render loop. Reducing the queue size does not help either, since the throttling applies per item regardless of how many are waiting.

Sanity checks before you blame throttling

If the queue stalls even with the tab visible, work through these in order:

  1. Confirm you are signed in to Grok and your session has not expired mid run.
  2. Check whether the site is rate limiting you, which usually shows up as slow or refused responses in the page itself.
  3. Watch one generation from start to finish with the tab in focus. If that single item completes normally, throttling is your answer.
  4. Check that your laptop is not asleep or in a low power mode that suspends the browser wholesale.

The short version

Give the Grok tab a window of its own, keep it visible, and start the batch. Long queues run fine when the page they depend on is allowed to keep running. If you are setting up your first big batch, the guide to queueing 100 prompts covers the naming and download settings worth getting right first.