Why Your Site Loads Fast Locally But Slow for Googlebot
On this page
“Slow for Googlebot” can mean two different things, and neither is what your browser shows you. One is how quickly your server answers Googlebot’s own requests, which Search Console’s Crawl Stats report shows. The other, and the one behind a low PageSpeed Insights score, isn’t Googlebot at all: it is Lighthouse simulating a mid-tier phone, plus field data from real Chrome users. Your site may feel fast to you because of a warm cache, a nearby server and a fast device. The fix depends on which number is slow: server response for the crawler, or the first-visit mobile path for visitors.
Three numbers, and only one is Googlebot
| Measurement | What it measures | Where you see it | Is it Googlebot? |
|---|---|---|---|
| Average response time | Response time for all resources Google's crawlers fetched from your site | Crawl Stats report (root-level properties) | Yes |
| Lab data | Lighthouse loading the page in a simulated environment | PageSpeed Insights | No |
| Field data | Real users' experience over the previous 28 days | PageSpeed Insights, Core Web Vitals report | No, real Chrome users |
Google’s PageSpeed Insights documentation says Lighthouse currently simulates the page load conditions of a mid-tier device (Moto G4) on a mobile network for mobile, and an emulated desktop with a wired connection for desktop. It also says PSI reports real users’ FCP, INP, LCP and CLS over the previous 28-day collection period. The crawler’s own number lives in the Crawl Stats report, which defines average response time as the average for all resources fetched from your site during the period.
Why your own view is faster
Warm cache. After your first visit, the site’s CSS, JavaScript, fonts and images can sit in your browser cache, so repeat loads skip much of the network. A first-time visitor downloads all of it.
Proximity. Near the origin server or a CDN location, round trips are short. A visitor in another region can wait longer for the same bytes.
Device and network. A laptop or a flagship phone on fast wifi runs JavaScript faster than the mid-tier phone Lighthouse simulates. On a slower CPU, script execution and rendering take longer, and a fast desktop can hide the cost of heavy JavaScript.
None of this is a measurement error. It is the difference between your conditions and a first visit on a phone.
When Googlebot itself gets slow responses
Crawl Stats shows response time and host status for Google’s crawling of your site. Click into file types to see average response time by date; the report suggests checking whether spikes in slow responses of one type line up with general slowness or unavailability.
This number is about your server, not about front-end weight on a phone. Google’s crawl budget guide says that when a site slows down, with longer latency or response times, or answers with server errors, Google lowers its crawl capacity limit and crawls less. If this is the slow number, look at server response and time to first byte, origin caching, and the hosting capacity behind them.
Why the lab and field numbers matter
Google’s page on Core Web Vitals says it highly recommends that site owners achieve good Core Web Vitals for success with Search, and that this, along with other page experience aspects, aligns with what its core ranking systems seek to reward. Its page experience guidance adds that site owners shouldn’t focus on only one or two aspects of page experience.
web.dev’s Core Web Vitals page sets the targets for good: LCP within 2.5 seconds, INP of 200 milliseconds or less, and CLS of 0.1 or less, measured at the 75th percentile of page loads, segmented across mobile and desktop. INP is the successor to First Input Delay, so a guide that still grades responsiveness by FID is out of date.
Two details in PSI’s field data change how you read it:
- It trails by 28 days. A fix you shipped yesterday shows up gradually, as real visits after the fix replace older ones in the 28-day window.
- It can be origin-wide. When a page lacks enough data, PSI falls back to origin-level data covering all pages of the site. A slow template elsewhere can then color the numbers you see for a fast page.
Diagnose the slow path
Read PSI’s diagnostics rather than the headline score. The LCP element entry names the content that defines Largest Contentful Paint, such as a hero image or a heading block. Render-blocking resources are the stylesheets and scripts that delay first paint. The unused JavaScript and CSS entries show weight the page ships without using.
Then open your browser’s DevTools, throttle the CPU and network to a mobile profile, and read the network waterfall with a cleared cache. Look for what blocks what, where the long bars sit, and whether the main content waits behind third-party requests. That is the path a first-time mobile visitor takes, not the warm path you test on.
Fix the first-visit mobile path
Work in the order the diagnostics rank the problems, and re-test after each change:
- Remove scripts you don’t need. Apps and plugins you installed and stopped using can keep adding scripts to every page. Uninstall them, confirm their code is gone from the page, and re-test.
- Fix images. Serve images at the dimensions they render, in a modern format, and lazy-load images below the fold so they don’t compete with the first screen.
- Cut theme weight. A theme that loads sliders, animations and libraries you don’t use adds weight you can only remove at the source: strip the features or move to a leaner theme.
Then let the field data confirm the result over the following weeks, since the lab score only shows the simulated load.
Frequently asked questions
Why is my PageSpeed score low when the site loads instantly for me?
You may have a warm cache, a nearby server and a fast device. Lighthouse simulates a mid-tier phone on a mobile network loading the page cold. Read the diagnostics, not only the score.
Does Googlebot see my PageSpeed Insights score?
PSI isn’t Googlebot. The crawler’s own speed measure is the average response time in the Crawl Stats report, which tracks how quickly your server answers Google’s crawl requests.
Will fixing Core Web Vitals raise my rankings?
Google recommends good Core Web Vitals and says they align with what its core ranking systems seek to reward, alongside other page experience aspects. It also says not to focus on only one or two aspects of page experience.