Test finds Google pauses its clock for slow-loading pages

By Zara Kincaid · 2026-07-29

The rule that wasn't: where the five-second myth came from

Google indexes content in two stages. Googlebot fetches raw HTML first, then hands it to the Web Rendering Service, a headless Chrome instance that runs JavaScript and builds the DOM before any content is indexed.^[1] That second stage is where the myth took root.

Google's Martin Splitt once described the median wait in the rendering queue as roughly five seconds. The industry misread that as a hard cutoff for page execution. That figure describes how long pages typically wait before rendering begins, not how long the renderer will run before abandoning a page.^[1]

What the test actually showed: delayed content still indexed

Dave Smart, technical SEO consultant at Tame the Bots, built a test page with two server-side API calls, each delayed by between three and six seconds. The combined wait ran anywhere from six to twelve seconds, well past the supposed five-second wall.

Google's rendering system captured all the content from both delayed API calls despite the page taking up to 12 seconds to fully load.verifiedVerified Source: tamethebots.com^[1] Smart said: "The total time for both api calls could be anywhere between 6 and 12 seconds, longer than the famous 5 second limit."

A follow-up test looped successive three-second delays to push the system further. Live testing tools cut out after 16 to 18 loops (48 to 54 seconds), while actual indexing continued for roughly 10 loops, or about 30 seconds.verifiedVerified Source: tamethebots.com^[1] Either figure dwarfs five seconds.

How Google's virtual clock works: pausing, not quitting

Smart said: "The WRS does time in its own way. Rather than the hardware clock, like you have on your computer or server, the WRS uses a virtual clock that they can control."^[1] That distinction matters for any site relying on external data feeds, third-party widgets or lazy-loaded content.

When the renderer fires a network request and waits for a response, it freezes its virtual clock rather than counting down. The Web Rendering Service froze its virtual clock while network requests of up to six seconds each were pending, meaning actual wall-clock time exceeded five seconds without aborting the render.verifiedVerified Source: tamethebots.com^[1] Real elapsed time and rendered time are two separate things inside Google's infrastructure.

When Google does stop: the event loop, not a stopwatch

The Web Rendering Service does eventually stop, but the trigger is not a clock. Google watches the browser's event loop and calls the render complete when the loop goes idle, signalling no further work is queued.^[1]

A page with runaway JavaScript that never settles, or one hammering the event loop with endless callbacks, is far more likely to cause incomplete indexing than a page that simply takes eight or ten seconds to fetch its data. The mechanism Google uses is state-based, not time-based.

Slow pages still hurt users, just not indexing

Businesses should not be told their content is invisible to Google simply because it loads in more than five seconds.^[1] That advice has been repeated confidently across audits and agency reports for years without any verified technical basis.

Slow pages do damage real visitors. Core Web Vitals scores, bounce rates and conversion all suffer when users wait. Speeding a page is worth the engineering effort, but the reason is user experience, not fear that Google will miss the content. Smart's testing, published 23 July 2026, is the most direct empirical challenge to the five-second rule to date.

Zara Kincaid

Zara Kincaid writes about artificial intelligence and search. Her focus is what happens to businesses when the front page of the internet stops being a list of links and starts being an answer.