Website page loading speed remains a measurable gap between many sites and modern performance benchmarks. In July 2025, 48% of mobile websites and 56% of desktop websites achieved good overall Core Web Vitals, according to The Web Almanac by HTTP Archive. The figures below separate current field results from older Google and SOASTA studies, because Core Web Vitals, page weight, and full load time measure different parts of the experience.
Contents
- How many websites meet modern benchmarks
- What becomes the largest content
- Page weight and request counts
- JavaScript and main-thread blocking
- Mobile loading, abandonment, and conversion
- What speed improvement case studies show
How many websites meet modern benchmarks
The 2025 Web Almanac reports the share of websites passing overall Core Web Vitals using Chrome User Experience Report field data alongside HTTP Archive measurements. Its primary measurements were taken in July 2025. Overall, 48% of mobile websites achieved good Core Web Vitals, compared with 56% of desktop websites. That difference matters for SEO and UX work: a site can perform adequately on a desktop test while falling short for mobile visitors.
Site popularity also changed the result. Among the 1,000 most popular mobile websites, 51% achieved good Core Web Vitals. The figure fell to 42% for the next 10,000 websites and to 37% for the next 100,000. Across the top 10 million websites, 49% achieved good mobile Core Web Vitals. These are July 2025 measurements, not a forecast or a universal score for every site.
Individual loading metrics reveal where the overall result comes from. In 2025, 70% of desktop pages had good First Contentful Paint below 1.8 seconds, while 55% of mobile pages met that level. Time to First Byte below 0.8 seconds was good on 55% of desktop websites and 44% of mobile websites. First Contentful Paint concerns the first rendered content, and Time to First Byte concerns server response timing; neither is interchangeable with a complete page-load time.
| July 2025 benchmark | Desktop | Mobile |
|---|---|---|
| Good overall Core Web Vitals | 56% | 48% |
| Good First Contentful Paint below 1.8 seconds | 70% | 55% |
| Good Time to First Byte below 0.8 seconds | 55% | 44% |
What becomes the largest content
Largest Contentful Paint measures when the main visible content appears. The element counted as the largest content was an image on 85.3% of desktop pages and 76.0% of mobile pages in July 2025. Text was the largest content on 14.4% of desktop pages and 23.7% of mobile pages. Inline images accounted for 0.3% of desktop pages and 0.4% of mobile pages.
The distribution points to different optimization priorities. Image-heavy desktop pages should examine the hero or other prominent image first. On mobile, the larger text share means that heading and paragraph rendering can also determine when the main content is considered visible. A page does not need the same LCP diagnosis on both device types.
Among LCP images, JPG was used on 57% of desktop pages. PNG accounted for 26% of LCP images across device types, while WebP accounted for 11%. The remaining formats or cases are not quantified in the supplied Web Almanac figures, so these percentages should not be treated as a complete format inventory.
Resource priority was also uncommon. The fetchpriority=high attribute appeared on 16.3% of desktop pages with LCP images. That result describes observed adoption in July 2025; it does not establish that every page should use the attribute or that applying it alone will improve LCP.
For practical SEO work, the measurable sequence is straightforward: identify the actual LCP element, determine whether it is an image or text, then inspect its format and delivery priority. The data supports focusing on the content that users see first, rather than treating every asset as equally important.
Page weight and request counts
HTTP Archive’s 2024 Page Weight chapter describes distributions from crawl data, not one universal loading time. The median page made 71 requests on desktop and 66 on mobile. At the 10th percentile, pages made 24 desktop requests and 22 mobile requests. At the 25th percentile, the figures were 42 and 39.
The upper percentiles show how much more complex pages can become. At the 75th percentile, desktop pages made 115 requests and mobile pages made 109. At the 90th percentile, desktop pages made 176 requests and mobile pages made 170. Request count is not a direct time measurement, but every additional request can add resources, scheduling decisions, and opportunities for delay.
| 2024 request distribution | Desktop | Mobile |
|---|---|---|
| 10th percentile | 24 | 22 |
| 25th percentile | 42 | 39 |
| Median | 71 | 66 |
| 75th percentile | 115 | 109 |
| 90th percentile | 176 | 170 |
The median desktop page weighed 2,652 KB in October 2024, while the median mobile page weighed 2,311 KB. Between October 2023 and October 2024, median desktop page weight grew 8.6%, or 210 KB. Median mobile page weight grew 6.4%, or 140 KB over the same period. These year-over-year changes are estimates of distribution movement in the Web Almanac data, not a prediction of future page growth.
Images and JavaScript were substantial parts of the median desktop homepage. It delivered 1,054 KB of images and 613 KB of JavaScript in 2024. The figures help explain why page speed audits often need both media and code work: reducing only one category may leave most of the payload untouched.
JavaScript and main-thread blocking
The 2024 JavaScript chapter of The Web Almanac found a median JavaScript payload of 613 KB on desktop pages and 558 KB on mobile pages. The median desktop page made 23 JavaScript requests, compared with 22 on mobile. At the 90th percentile, desktop pages made 70 JavaScript requests and mobile pages made 68.
Payload size is only part of the problem. The median mobile page delivered 206 KB of unused JavaScript, equal to 44% of bytes delivered. At the 90th percentile, mobile pages had 818 KB of unused JavaScript. Those measurements suggest that a page can transfer substantial code that does not contribute to the initial experience.
The performance cost also appears in blocking time. In July 2025, median mobile Total Blocking Time was 1,916 milliseconds, compared with 92 milliseconds on desktop, according to the Web Almanac performance chapter. Total Blocking Time describes main-thread blocking in a lab measurement; it is not the same as a field Core Web Vitals pass rate or a full load duration.
Together, the numbers identify several separate questions for an audit: how many JavaScript files load, how large the payload is, how much is unused, and how long the main thread is blocked. A mobile page with 558 KB of median JavaScript and 206 KB of unused code has a different optimization opportunity from a page whose main problem is server response time.
Mobile loading, abandonment, and conversion
Google’s January 2017 global mobile analysis provides older benchmarks that should retain their original period. It reported that the average mobile landing page took 22 seconds to fully load. The analysis also reported that 53% of mobile site visitors left pages taking longer than three seconds to load; that abandonment figure used March 2016 benchmark data and was published in 2017.
Visual completion was slower than the first threshold suggested. For 70% of analyzed mobile pages, above-the-fold visual content took nearly seven seconds to appear. For the same share of pages, all above- and below-the-fold visual content took more than 10 seconds to load. The analysis modeled the probability of a mobile visitor bouncing as increasing 113% when load time rose from one to seven seconds.
Page weight was another constraint in that study. Seventy percent of analyzed mobile pages exceeded 1 MB, 36% exceeded 2 MB, and 12% exceeded 4 MB. A 1.49 MB mobile page took seven seconds to load on the study’s fast 3G connection. Thirty percent of analyzed mobile pages could save more than 250 KB through image and text compression.
These findings came from older emulated Nexus 5 and Chrome testing on a representative 3G connection, so they should not be presented as current global behavior. They remain useful as historical evidence that mobile users experience the combined effect of payload size, network conditions, and rendering work.
What speed improvement case studies show
The Google Mobile Site Speed Playbook cites a 2017 SOASTA study in which mobile pages loading one second faster saw up to a 27% increase in conversion rates. The phrase “up to” matters: it describes the upper result reported by that study, not a guaranteed gain for every website.
The same playbook reported an average bounce rate of 13% for mobile loads under three seconds and nearly 60% after nine seconds. In a 2016 review of travel, retail, and finance sites published in the playbook, only 14 of 316 reviewed sites loaded in two seconds or less. The top retail sites in the European review averaged 3.8 seconds to load.
The case studies show how speed changes can connect to business metrics, while retaining their original publication context. Money.co.uk reduced load time from 11.7 seconds to 3.5 seconds after a Google speed audit. After the speed and usability work, its click-through rate increased from 12% to 32%, and its bounce rate fell from 80% to 52%.
Settled reported a 23% increase in mobile conversion after improving page load times almost three-fold. That result is a company case study published in 2017, not a controlled estimate that can be transferred directly to another site.
For a current website, the strongest reading of these statistics is diagnostic rather than promotional. Start with field Core Web Vitals, then inspect LCP content, page weight, request counts, JavaScript bytes, unused code, and blocking time. Historical Google and SOASTA results show why the business impact can be material, but their dates, testing conditions, and study designs should remain visible whenever the figures are used.