Google measures website loading speed with three Core Web Vitals: the main block of the page should appear within 2.5 seconds (LCP), the response to a tap should come within 200 milliseconds (INP), and the layout should not jump by more than 0.1 (CLS). You can check all three for free in PageSpeed Insights: paste the address, choose the Mobile tab, and look at the top block with real-visitor data first, and only then at the score out of 100.
Core Web Vitals in plain words
The thresholds below come from the metrics overview on web.dev, the Chrome team’s site. One important detail: “good” has to hold not on average but for 75% of page loads, separately on phones and on desktops.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP, Largest Contentful Paint | when the largest block of the first screen appeared: an image, a video or a paragraph | up to 2.5 s | over 4 s |
| INP, Interaction to Next Paint | how quickly the page responds to a click, tap or key press | up to 200 ms | over 500 ms |
| CLS, Cumulative Layout Shift | how much elements shift unexpectedly while the page loads | up to 0.1 | over 0.25 |
Older articles mention FID instead of INP. It was replaced on 12 March 2024, as announced by the Chrome team. If a speed guide still talks about FID, it is out of date.
How to check website loading speed in 5 minutes
- Google PageSpeed Insights. Open pagespeed.web.dev, paste the page address, choose Mobile. Check not only the home page but also the page your ads lead to.
- The Core Web Vitals report in Google Search Console. It covers the whole site rather than a single page: it groups similar URLs and gives each group the status of its worst metric. After a fix you can start validation, and Google will monitor for 28 days whether the issue reappears.
- Yandex Metrica. If the site runs Yandex’s analytics service, open Reports → Monitoring → Page load time. It shows server response time, time to first paint and time to full load for real visitors. By default it reports the median, so half of all visits were slower.
Field data vs lab data: why the numbers differ
PageSpeed contains two different measurements, and they are often confused. The top block is field data from the Chrome User Experience Report (CrUX): real Chrome users over the trailing 28 days, at the 75th percentile. This is where the page passes or fails the Core Web Vitals assessment. The bottom block with the score out of 100 is a lab test: Lighthouse loads the page once on an emulated mid-range phone over a throttled mobile network. Per the documentation, 90 and above is good, 50–89 needs improvement, below 50 is poor.
The lab helps you find causes. Field data shows what people actually get. When they disagree, trust the field data.
Example: measuring our own site
On 1 October 2026 we ran our home page, aicapitalfactory.com, through PageSpeed on the Mobile tab. The lab run — an emulated Moto G Power on “Slow 4G”, Lighthouse 13.5.0 — scored 100: LCP 1.7 s, CLS 0.002, total blocking time 0 ms. The real-visitor block said “No Data”. The site is young, traffic is low, and CrUX has not collected it yet. That is the usual picture for a small business site in Uzbekistan. Until field data appears, rely on the lab and on your analytics.
Why the phone comes first
According to StatCounter, in September 2026 desktops accounted for 60.9% of page views in Uzbekistan and phones for 38.7%. That is an average across sites carrying the StatCounter tag, and your site may differ a lot. Customers who arrive from a link in Telegram or Instagram most likely open it on a phone. Check your own device split in your analytics.
Even with a desktop-heavy audience, test the mobile version first. Google’s documentation says it uses the mobile version of a site’s content for indexing and ranking.
The network in Uzbekistan is no excuse for a slow site. Per the Speedtest Global Index (Ookla, August 2026 edition), the country’s median mobile download speed is 65.27 Mbps, 72nd in the ranking. A median hides the tail, though: the Core Web Vitals assessment uses the 75th percentile, the slowest quarter of page loads. That is why PageSpeed tests on a throttled network.
The myth: “53% leave if a site takes longer than 3 seconds”
This figure appears in nearly every article on site speed. It comes from a post by Google’s ad platform DoubleClick, “The need for mobile speed”, dated 8 September 2016. The original is more careful: 53% of visits are “likely” to be abandoned if pages take longer than 3 seconds to load.
Footnote 6 of the post shows what is behind it: aggregated Google Analytics data from 3.7 thousand mobile sites that opted in to sharing benchmark data, worldwide, March 2016. The post does not say how an “abandoned visit” was defined or which load time was used. Context matters too: the post addresses ad-funded publishers. Another measurement in the same post put the average mobile page load at 19 seconds over 3G. And the post ends by recommending AMP, a project in which, as the authors write, Google itself takes part.
In retelling, the figure lost its “likely”, visits turned into “users”, and publishers’ mobile sites of 2016 turned into any website today. Don’t treat it as a law of nature. As an illustration that slow loading costs visitors, it is fine — with the year and the source.
What is actually known about speed and money
- Deloitte, “Milliseconds Make Millions”, 2020. The study was commissioned by Google. 37 brands in Europe and the US, 30 million sessions over four weeks. When a mobile site became 0.1 seconds faster across four metrics, retail conversion was 8.4% higher and average order value 9.2% higher. Travel sites saw conversion 10.1% higher. The authors’ caveats: it is a correlation from a regression model, not an experiment. Speed was measured with lab Lighthouse. On desktop the picture was contradictory.
- Vodafone, a case study on web.dev, 2021. This one is an A/B test: paid traffic was split evenly between two versions of a landing page. The faster version had a 31% better LCP and 8% more sales.
- Google itself says it always seeks to show the most relevant content, even if the page experience is sub-par. A fast site with empty copy won’t reach the top.
10 common causes of a slow site and what can be fixed in a day
| Cause | What to do | In a day? |
|---|---|---|
| 1. Full-size phone photos on the first screen | resize to the actual display size, save as WebP or AVIF | yes |
2. The main image has loading="lazy" |
remove it: web.dev says plainly never to lazy-load the LCP image; add fetchpriority="high" |
yes |
| 3. Images and banners have no dimensions | set width and height or aspect-ratio — first on the list of common causes of a jumping layout |
yes |
| 4. Video background on the first screen | replace it with a static poster image, load the video on tap | yes |
| 5. A slider of 5–8 large banners in the header | keep one screen with one offer | yes |
| 6. Third-party scripts: chat widget, pixels, map, live consultant | remove the unneeded ones, load the rest after the first screen | partly |
| 7. Six font weights with Cyrillic and Latin | keep two or three, load only the character sets you need | yes |
| 8. No caching for static files | set cache headers or add a CDN | yes |
| 9. Slow hosting, slow server response | check server response time in analytics; move hosting or add a CDN | usually not |
| 10. A heavy theme or site builder with dozens of plugins | switch off what is unused; if that does not help, rebuild | no |
Animations deserve a separate line. If elements move via top, left or width, the page recalculates layout on every frame. Move them with transform and opacity instead — details in our article on website animation. Why a site on a builder has a lower speed ceiling than one built in code is covered in Tilda, WordPress or a coded website.
What to do next
- Run the home page and your ad landing page through PageSpeed on the Mobile tab. Write down LCP, INP and CLS with the date.
- If there is no field data, repeat the test three times: the lab score drifts a little from run to run.
- Go down the table above from the top: the first five items usually bring most of the gain and don’t require rebuilding the site.
- After 28 days, compare with the field data in Search Console or with your analytics report.
When it is easier to rebuild a site than to speed it up, build speed in from day one. You can see how we combine parallax, scroll scenes and speed on our Website development page — and check it in the same PageSpeed. Packages start at 4.9 million so’m (about $415 at the Central Bank of Uzbekistan rate of 1 October 2026); all prices are in our price list (in Russian), and the exact price follows a free brief. What drives website prices in Uzbekistan is covered in How much a website costs.
