Googlebot sees your page down to 10 million pixels, but not the end of your carousels

In August I wrote here that Googlebot's rendering limit is not a time limit: the 5 seconds never existed and what Google watches is the Event Loop. This weekend Natzir Turrado measured the other half of the problem, space. How far the screen Google paints your page on reaches, which lazy-loaded images it requests and which ones never load. The result dismantles a widespread fear and exposes a blind spot almost nobody checks.

The size of the viewport Googlebot renders with

Let's start with the measurement, because it changes everything. Natzir built test pages that write what they see into their own rendered HTML, and ran them through the live test in Search Console's URL Inspection. Googlebot starts with a mobile viewport of 412×732 pixels. Around 5 seconds in it resizes it in one go to the full page height, without ever scrolling.

• Richard Hearne, who was discussing the test with him, recalled measuring a viewport of just over 9,000 px the last time he tried. The ceiling has risen by three orders of magnitude.
• All 200 images with loading="lazy" spread down the 200,000 px page loaded.

How Google handles lazy-loaded images in a carousel

Vertically yes, as we have just seen, but sideways only partly. The viewport does not stretch horizontally: it stays at 412 px. In a horizontal carousel, Googlebot only requested the lazy images within about 1,500 px of the edge, and Natzir checked in Search Console's list of loaded resources that the ones further away were never requested. With cards about 300 px wide, that is the first four or five. My reading is that this is the margin Chrome uses to load lazy images early, the same one it applies vertically.

What changes in practice for a website

Those two measurements lead to four consequences, and none of them is the one people usually take for granted.

• Vertical lazy loading hides nothing from Google. Since the viewport is as tall as the page, everything below enters the screen at once. There is no need to set every image to eager "in case Google misses it". The ones at the top, yes, but for the user's LCP.
• The blind spot is carousels. If the image carries its src in the HTML, Google has the URL even if it does not download it while rendering. If the carousel uses a script that keeps the URL in data-src and moves it to src on swipe, the last cards have no image for Google. And if slides are created when the arrow is clicked, they do not exist for Google, because it does not click.
• Infinite scroll that relies on the scroll event loads nothing. Googlebot never scrolls. Product or article listings need pagination with plain links to each page, not a "load more" that only reacts to the user's finger.
• The URL Inspection screenshot is misleading. It is cut at about 1,750 px tall and looks as if Google missed the rest, when its viewport reaches much further down. What you need to check is the rendered HTML, not the screenshot. Natzir has released a Chrome extension, GSC Full Fetch & Render, that shows the full screenshot.

How reliable these data are

It is worth putting the right margin on it. It is one person's test, run on 10 October 2026 in Search Console's live test, and Hearne warns that this tool gives different results from one request to the next. In August we already saw that the live test and actual indexing do not behave the same: with requests in an infinite loop, one cut off at 16-18 calls and the other at 10. The good news is that the test pages are public and anyone can repeat the experiment on their own property.

My take: the limit is sideways, not vertical

For years I have heard that Google only sees the top of the page and that lazy loading hides content. Vertically that is not true, and no normal page will ever reach the 10 million pixel ceiling. Where there is a limit is sideways and in anything that needs a user gesture. Before rewriting a site's lazy loading, I would check the carousels on product and category pages on mobile: what sits from the fifth card onwards and whether it is in the HTML.

This week a developer at a client told me they were cutting features from a page because "Google stops rendering after 5 seconds". It is a line I have been hearing for years. And it is not true.

Dave Smart's test on Google's Web Rendering Service

Dave Smart, from Tame the Bots, published the test that proves it on 23 July 2026. He built a page with two API calls that each take between 3 and 6 seconds to respond from the server. Total: between 6 and 12 seconds. Google rendered and indexed the full content, both in URL inspection and in actual indexing.

Where does the myth that Google stops rendering after 5 seconds come from?

Google's Web Rendering Service does not use the hardware clock. It uses a virtual clock that can speed up, slow down or freeze. When the WRS waits on a network request, it freezes time. That is why, if you set up a counter with setInterval inside your page, it stops at 5 and you conclude there is a 5-second limit. What you are really measuring is a clock that does not advance while Google works.

The rendering test data that confirms the myth is false

• In the test, two calls that took 9 real seconds of server time reported a total time of 0.02 seconds.
• In actual indexing, the clock always starts at midnight UTC, so every timestamp comes out as 00:00:00.

So is there any limit to Google's rendering?

Yes, but it is not a time limit. Google watches the Event Loop to decide when the page is idle. Smart built a page with requests in an infinite loop: the live tool cut off at 16-18 calls (48-54 seconds) and actual indexing at 10 (30 seconds).

My take on the Web Rendering Service rendering limits

My reading, after seeing how many teams have rewritten architectures chasing this threshold: the problem is never the clock, it is the Event Loop. If you have constant polling, infinite animations or listeners that reactivate on their own, then you do have something to fix. If not, stop optimizing against a made-up number and optimize for the user, who has far less patience than Googlebot.