The short answer
The green score in PageSpeed Insights is lab data, a simulation. Google does not rank on it. What feeds Google's page experience signals is field data: real measurements from real Chrome users on your site over the previous 28 days.
So the first question is not "how do I get to 90". It is "what are real visitors actually experiencing", which is a different number in a different part of the same report. For a lot of small Indian business sites the honest answer turns out to be hosting located on the other side of the world, and no amount of image compression fixes that.
The three numbers Google actually cares about
Core Web Vitals is three metrics, and the thresholds are public and fixed.
| Metric | What it measures | Good |
|---|---|---|
| LCP | How long until the main content appears | 2.5 seconds or less |
| INP | How quickly the page responds when someone taps or clicks | 200 milliseconds or less |
| CLS | How much the layout jumps around while loading | 0.1 or less |
Two details matter and are usually left out. Google assesses these at the 75th percentile of your page loads, so it is not your average visitor, it is roughly your unluckiest quarter. And mobile and desktop are measured separately, which is why a site can pass comfortably on desktop and fail on the traffic that actually matters.
INP replaced First Input Delay as a stable metric in 2024. If you are working from an older checklist that talks about FID, that checklist is out of date.
Lab data and field data, and why the difference costs people money
Open PageSpeed Insights on your own site and you will see two sections. Most people look at the big coloured score and stop.
That score comes from a simulated load on a virtual mid-range device on a throttled connection, run from wherever Google's testing infrastructure happens to be. It is genuinely useful for debugging, because it is repeatable and it tells you specifically what is heavy. It is not what you are ranked on.
The section above it, if it appears, is field data drawn from the Chrome User Experience Report. Those are real page loads by real people on their real phones and connections, collected over a rolling 28 day window. That is the data feeding Google's page experience signals.
If your field data section is missing entirely, that is information too. It means Chrome has not collected enough real visits to your site to report on it. Very common for a new or low traffic small business site, and it means nobody can tell you your real world speed from the outside, including any agency quoting you a number. In that situation your lab score is the only signal available, which is fine, as long as everyone is honest that it is a proxy.
The practical version: chase the lab score to find problems, judge yourself on the field data once you have enough traffic to have any.
The reason that is specific to India: where your server is
This is the one that gets missed, and it is often the largest single factor.
Every request from a browser to a server is a round trip, and that trip is bounded by physics. A server in Mumbai, Hyderabad or Chennai answering a visitor in Pune is a short trip. The same site hosted in Virginia or California answering that same visitor is a long one, and it is not one trip, it is one for the HTML plus one for each stylesheet, script, font and image that is not cached.
Plenty of Indian small businesses are on cheap shared hosting whose data centre is in the United States, usually without knowing it, because the hosting company's website is in rupees and the checkout was in rupees so it never came up. The site feels fine to the developer testing over office fibre. It feels slow to a customer on a phone in a lift.
You can check this yourself in about a minute. Open your browser's developer tools, go to the Network tab, reload your homepage, and look at the time to first byte on the very first request. That number is mostly your server's distance and your server's speed, and almost nothing else. If it is high, no amount of compressing images will save you, because the browser has not even received the HTML yet.
Two fixes, and they are not the same thing:
- Move the hosting closer. If your customers are in India, your server should be in India, or Singapore as the nearest serious alternative. This is the real fix and it fixes every request.
- Put a CDN in front. A CDN caches your static files at locations near your visitors, which helps a great deal for images, CSS and fonts. It does less for pages that have to be generated fresh by the server on every visit, which is most of WordPress unless page caching is set up properly.
What to fix, in order of how much it usually helps
Ranked by what we actually see move the numbers, not by what is easiest to sell.
- Hosting and server locationCovered above. If time to first byte is bad, start here and stop reading the rest until it is sorted, because everything else is measured on top of it.
- ImagesAlmost always the biggest weight on a small business site. Serve WebP, size the file to the space it actually occupies rather than uploading a 4000px camera original into a 600px slot, and add width and height attributes so the browser reserves the space.
- Layout shift from images, ads and fontsCLS is the cheapest of the three to fix and the most irritating to users. Anything that loads late and pushes content down needs its space reserved in advance. A late loading web font that changes text size is a common culprit and is worth checking specifically.
- Plugin and script bloatEvery plugin adds requests. Sliders, chat widgets, analytics, heat mapping, three different font libraries. Audit what is loading on the homepage and remove what nobody is using. This is also the fix that most often improves INP, because INP is usually about JavaScript blocking the main thread.
- CachingPage caching, browser caching with sensible expiry headers, and object caching if the site is database heavy. Cheap to set up and it compounds with everything above.
- The theme and page builderLast because it is the most disruptive, but be realistic: some builders generate deeply nested markup and load their entire framework on every page. If the site is already fighting its own theme, a rebuild is sometimes cheaper than an ongoing optimisation battle.
An honest word about speed as a ranking factor
Speed matters. It matters less than people selling speed optimisation tend to imply.
Google has been fairly consistent that page experience is a tiebreaker rather than a primary signal. A fast page about nothing does not outrank a slow page that answers the question. If your site is not ranking and it loads in three seconds, speed is unlikely to be your problem, and you would get more from fixing what the pages actually say.
Where speed genuinely pays is on the human side. People leave slow pages, particularly on mobile data, and particularly before they have any reason to be invested. That shows up as lost enquiries rather than lost rankings, which is worth reading about separately in why a site gets visitors but no enquiries.
Be sceptical of a guaranteed 90+ score. It is achievable on almost any site by stripping functionality, deferring everything, and optimising for the test rather than the visitor. A 95 that took away your booking widget is not an improvement. Ask what the field data did, and ask what was removed to get there.
How we approach this on our own site
For what it is worth, this site is hand written static HTML with one stylesheet, one small deferred script, a self hosted font and no page builder, which is an unusual position and not one most businesses need to copy. It does mean we have chased these numbers ourselves rather than only for clients, including a run of layout shift problems that took three separate attempts to trace to the real cause.
The thing that generalises from that experience is dull: the fix is almost never the exciting one. It is usually the server, the images, or one script nobody remembered adding.
Common questions
Does my PageSpeed Insights score affect my Google ranking?
Not directly. The headline score in PageSpeed Insights is calculated from lab data, a simulated page load in a controlled environment. Google's page experience signals are fed by field data from the Chrome User Experience Report, which is real measurements from real Chrome users over the previous 28 days. Use the lab score to find and debug problems, and judge real world performance on the field data section, if your site has enough traffic for it to appear at all.
What are the Core Web Vitals thresholds?
Largest Contentful Paint should be 2.5 seconds or less, Interaction to Next Paint should be 200 milliseconds or less, and Cumulative Layout Shift should be 0.1 or less. Google assesses these at the 75th percentile of page loads, and measures mobile and desktop separately. Interaction to Next Paint replaced First Input Delay as a stable metric in 2024, so any checklist still referring to FID is out of date.
Does it matter where my website is hosted if my customers are in India?
Yes, and it is often the single largest factor. Every request is a round trip between the visitor's browser and your server, and a server on another continent lengthens every one of them. Plenty of Indian businesses are on hosting billed in rupees whose data centre is actually in the United States. Check your time to first byte in your browser's Network tab: if that number is high, the server is the bottleneck and optimising images will not help, because the browser has not received the page yet.
Will a CDN fix a slow website?
Partly. A CDN caches static files such as images, stylesheets and fonts at locations near your visitors, which genuinely helps. It does much less for pages generated fresh by the server on each visit, which describes most WordPress sites unless page caching is configured properly. A CDN is a good addition and a poor substitute for hosting located near your audience.
Why is my site fast for me but slow for my customers?
Usually three reasons at once. Your browser has the site cached, so you are not doing the work a first time visitor does. You are likely on better connectivity than a customer on mobile data. And Google assesses at the 75th percentile, which means your experience as a repeat visitor on good internet is not the experience being measured. Always test in a private window on mobile data before deciding the site is fine.
Should I rebuild my site to make it faster?
Usually not as a first step. Work through hosting, images, layout shift, plugin bloat and caching first, since those cover most of the gap on most sites and cost far less. A rebuild becomes the sensible option when the theme or page builder is itself the bottleneck, loading its whole framework on every page, at which point ongoing optimisation costs more over time than starting cleanly.
Where to start today
Run your homepage through PageSpeed Insights, then ignore the score for a moment and look for the field data section. If it is there, that is your real answer. If it is not, open your Network tab and check time to first byte, because that one number tells you whether this is a hosting conversation or a content conversation.
If you would rather someone just looked, send us the URL on WhatsApp and we will tell you which of the six items above is actually costing you the most.