Your machine misses the check’s deadline

Close your other tabs and reload the page. That single change clears this row more often than everything else on this page put together, and it takes four seconds.

An interstitial challenge hands your browser a computation — some arithmetic, some rendering, some measurement of how your browser behaves — and asks for the answer back within a short window. The window exists because the challenge cannot wait forever on a page it suspects is hostile.

A browser that answers in time proceeds. A browser that does not is indistinguishable, from the challenge's side, from one that refused. There is no third outcome, and that is the loop you are stuck in.

What eats the budget

• Extensions. Every one of them runs its own content script on every page you open, before the challenge script gets its turn. Ten extensions is ten programs competing for the same thread.
• Other tabs. A background tab that is decoding video or running a heavy script shares your processor with the challenge.
• Thermal and power throttling. A laptop on battery saver, or one that has been hot for an hour, can run at a fraction of its rated speed.
• Software graphics. Every pixel the challenge draws goes through the processor instead of a graphics chip, which is both slow and its own separate row.
• Old hardware, honestly. A machine from 2013 running a 2026 challenge is doing an amount of work nobody designed for it.

Is it my internet connection?

Almost certainly not, and this is the most common wrong guess about this symptom — reasonably so, because a spinner is what a slow connection looks like everywhere else on the web.

The challenge script is small and arrives in a moment even on a poor connection. What takes time is running it, and running it happens entirely on your machine. You can confirm this without any tools: if other pages load normally while the interstitial hangs, your connection is fine and the wait is local. If a video plays smoothly in another tab while the challenge sits there, that is confirmation twice over — and it is also, awkwardly, part of the cause.

How long is “a few seconds”, really?

This site does not know, and no page that has not been given a vendor's configuration does. The window is chosen by whoever deployed the challenge, it differs between vendors, it differs between the same vendor's protection levels, and it is not published.

What can be said without inventing anything: the window is short enough that ordinary competition for the processor decides the outcome, and it is fixed while the amount of work on your machine is not. That asymmetry is the whole row. Anything you free up before the challenge runs is time it gets.

How this page measured it

Your reading reports the wall-clock time of this page's own read, which is a far heavier job than any challenge runs — tens of seconds rather than a few. It is not a simulation of a challenge and it is not presented as one. It is a load test on the same processor, and a machine that struggles here struggles there.

Alongside it, forty animation frames are sampled immediately after the read, with your extensions still running, and the number slower than 24 milliseconds is printed. That is the number that most directly describes what the challenge is up against.

Why does it work on my phone and not my laptop?

Because the comparison is not about raw speed, and a recent phone is frequently the faster machine anyway. Three differences matter more.

Your phone runs almost no extensions. On a laptop, every extension's content script runs before the page's own code on every load; on a phone browser there is usually nothing in that queue.

Your phone has one page in the foreground and aggressively suspends the rest. Your laptop has thirty tabs, several of them doing work you have forgotten about.

Your phone is on mobile data, which is a differently classified address — so if the phone gets through, it may not be the speed that made the difference at all. Test the laptop with the tabs closed before concluding anything.

Getting the time back

1. Close the other tabs before you go back to the site. This is the largest and cheapest single change.
2. Turn off the heaviest extensions temporarily. Not all of them — the two or three that inject the most.
3. Plug the laptop in and let it cool. Power and thermal throttling are invisible and enormous.
4. Turn hardware acceleration back on if your graphics row also fired. The two rows compound.

What to close, in what order

If you want to be systematic rather than closing everything, the ranking below is by how much of the processor a tab typically holds while it sits in the background. Work down it until the challenge completes.

1. Anything playing or decoding video, including a paused video that is still buffering, and any tab with a live call in it.
2. Web applications that keep working while unfocused — a mail client, a chat client, a document editor with autosave, an online spreadsheet with live data.
3. Tabs with automatically refreshing content: dashboards, live scores, anything that updates itself while you are not looking.
4. Everything else, which is usually cheap, and a browser window from yesterday you have not looked at since.