We knew Google's web rendering service (WRS) does its own thing with caching but now a new post from Gary Illyes and Martin Splitt of Google said the "WRS caches everything for up to 30 days." This is done to help "preserve the site's crawl budget for other crawl tasks," Google wrote.
Google explained that the time to live of the WRS (web rendering service) cache is unaffected by HTTP caching directives.
Here is what Google posted:
Crawling the resources needed to render a page will chip away from the crawl budget of the hostname that's hosting the resource. To ameliorate this, WRS attempts to cache every resource (JavaScript and CSS) referenced in pages it renders. The time to live of the WRS cache is unaffected by HTTP caching directives; instead WRS caches everything for up to 30 days, which helps preserve the site's crawl budget for other crawl tasks.
Gary Illyes added on LinkedIn, that he was a little concerned sharing a specific number, like 30 days. He wrote, "I was debating that '30' for some time (with myself that is) cos I was afraid it'll create another round of 15mb confusion, but also because it might actually change in the future." Ultimately he went with it, he wrote, "but then again, everything might, so I'm happy you found it useful (or good to learn anyway)."
Joe Hall asked on Bluesky:
When you say that WRS caches every resource for 30 days, does that mean WRS essentially doesn't need to do any client side rendering for 30 days after the initial render? Or does the cache only apply to the resource and not the post rendered HTML?
Martin Splitt from Google responded on Bluesky and said:
It does apply to resources. Which is why I recommend fingerprinting JS files as these tend to update more frequently. I'm not 100% sure if it applies to XHR GET requests, it does *not* apply to XHR POST requests for sure.
Interesting tidbits, no?
