Mobile pages spend 37 percent of load time after the initial request reaches the server. Field data from CrUX and HTTP Archive show that many sites still miss Core Web Vitals targets for LCP, INP, and CLS. Navigation and resource timing APIs identify the specific delays in the TTFB to LCP pipeline and how protocol choices affect concurrency.
Key Takeaways
- HTTP Archive reports that many sites still exceed recommended performance targets in field data (Core Web Vitals/Speed metrics discussion in State of the Web)
- Google Chrome will prioritize 'Core Web Vitals' reporting in user experience measurement (CrUX adoption trend statement)
- Google's PageSpeed Insights is used to evaluate page performance and provides optimization suggestions (tool capability, used widely in industry)
- Chrome User Experience Report (CrUX) uses real-user 'Core Web Vitals' collected from actual browser users
- The Largest Contentful Paint element is defined as the largest element by rendered area within the viewport at render time (web.dev LCP definition)
- 37% of the total page load time on mobile is attributable to delays after the initial request (TTFB-to-LCP pipeline effects)
- HTTP/1.1 and HTTP/2 request multiplexing affect concurrency; HTTP/2 allows multiple concurrent streams over one TCP connection
- HTTP/3 uses QUIC over UDP to reduce head-of-line blocking issues compared with TCP-based transport
- TLS 1.3 reduces the number of round trips required for handshake in common cases (0-RTT / 1-RTT behavior)
- W3C Navigation Timing Level 2 defines navigation timing attributes to measure page load phases
- W3C Resource Timing Level 2 enables high-resolution timing for resource fetches to analyze load time bottlenecks
- A 2019 study found that performance improvements can increase revenue by 4.0% per 1 second improvement in load time (study of e-commerce)
Core Web Vitals from real users show HTTP and transport choices and network delays strongly shape perceived load time.
Related reading
01 · Category
Industry Trends3 stats
01
HTTP Archive reports that many sites still exceed recommended performance targets in field data (Core Web Vitals/Speed metrics discussion in State of the Web)https://httparchive.org/reports/state-of-the-web
02
Google Chrome will prioritize 'Core Web Vitals' reporting in user experience measurement (CrUX adoption trend statement)https://web.dev/vitals/
03
Google's PageSpeed Insights is used to evaluate page performance and provides optimization suggestions (tool capability, used widely in industry)https://developers.google.com/speed/pagespeed/insights/
Interpretation
Industry Trends Interpretation
Industry trends show that despite growing measurement and optimization focus, field data still finds many websites exceeding recommended performance targets in Core Web Vitals, while Google’s CrUX-driven emphasis on Core Web Vitals and widespread use of PageSpeed Insights reflect a tightening industry shift toward measurable speed improvements.
02 · Category
Measurement Benchmarks11 stats
01
Chrome User Experience Report (CrUX) uses real-user 'Core Web Vitals' collected from actual browser usershttps://developer.chrome.com/docs/crux/
02
The Largest Contentful Paint element is defined as the largest element by rendered area within the viewport at render time (web.dev LCP definition)https://web.dev/articles/lcp/
03
37% of the total page load time on mobile is attributable to delays after the initial request (TTFB-to-LCP pipeline effects)https://web.dev/articles/ttfb/
04
Core Web Vitals target for INP is 200 ms or fasterhttps://web.dev/articles/inp/
05
Core Web Vitals target for CLS is 0.1 or lesshttps://web.dev/articles/cls/
06
The PerformanceObserver API can observe Core Web Vitals (LCP, CLS, INP) by subscribing to entry typeshttps://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver
07
The Performance Timing API marks 'loadEventEnd' at the end of the load event (use for load timing calculations)https://developer.mozilla.org/en-US/docs/Web/API/PerformanceTiming/loadEventEnd
08
The Resource Timing API provides 'transferSize' and 'encodedBodySize' for estimating download cost impacting load timehttps://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming
09
The Time To First Byte (TTFB) is measured as response start time minus request start time using timing APIshttps://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/responseStart
10
The Navigation Timing API 'domContentLoadedEventEnd' is an end timestamp for DOMContentLoaded, often used to approximate interactivity timinghttps://developer.mozilla.org/en-US/docs/Web/API/PerformanceNavigationTiming/domContentLoadedEventEnd
11
The 'Paint Timing' API can measure first paint (FP) and first contentful paint (FCP) using performance entrieshttps://developer.mozilla.org/en-US/docs/Web/API/PerformancePaintTiming
Interpretation
Measurement Benchmarks Interpretation
Measurement Benchmarks are pointing to a clear mobile performance trend where 37% of total page load time is lost to delays after the initial request, so improving the Core Web Vitals targets of LCP, INP 200 ms or faster, and CLS 0.1 or less is essential for real-world user experience.
More related reading
03 · Category
Performance Enablers8 stats
01
HTTP/1.1 and HTTP/2 request multiplexing affect concurrency; HTTP/2 allows multiple concurrent streams over one TCP connectionhttps://www.rfc-editor.org/rfc/rfc7540
02
HTTP/3 uses QUIC over UDP to reduce head-of-line blocking issues compared with TCP-based transporthttps://www.rfc-editor.org/rfc/rfc9114
03
TLS 1.3 reduces the number of round trips required for handshake in common cases (0-RTT / 1-RTT behavior)https://www.rfc-editor.org/rfc/rfc8446
04
WebP provides smaller image sizes than JPEG and PNG; Google reports significant size reduction for web imageshttps://developers.google.com/speed/webp/
05
Chrome's Network Information API exposes effective connection type and downlink estimates to help adapt loading behaviorhttps://developer.mozilla.org/en-US/docs/Web/API/NetworkInformation
06
COOP and COEP headers can impact cross-origin isolation, enabling certain performance features (e.g., SharedArrayBuffer usage) for appshttps://web.dev/articles/cross-origin-isolation-guide/
07
QUIC supports stream multiplexing without TCP head-of-line blocking at the transport layerhttps://www.rfc-editor.org/rfc/rfc9000
08
Modern browsers support preload to initiate fetches earlier than when JS requests them (spec: HTML preload)https://html.spec.whatwg.org/multipage/links.html
Interpretation
Performance Enablers Interpretation
Across the main performance enablers, moving from TCP to HTTP/3 with QUIC and from older TLS setups to TLS 1.3 cuts transport delays by reducing head-of-line blocking and handshake round trips, while smarter browser and content choices like Chrome’s Network Information API, WebP’s smaller images, and cross-origin isolation via COOP and COEP help unlock faster, more adaptive loading behavior.
04 · Category
Performance Impact3 stats
01
W3C Navigation Timing Level 2 defines navigation timing attributes to measure page load phaseshttps://www.w3.org/TR/navigation-timing-2/
02
W3C Resource Timing Level 2 enables high-resolution timing for resource fetches to analyze load time bottleneckshttps://www.w3.org/TR/resource-timing-2/
03
A 2019 study found that performance improvements can increase revenue by 4.0% per 1 second improvement in load time (study of e-commerce)https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3290936
Interpretation
Performance Impact Interpretation
For the Performance Impact category, faster website loading can directly translate to business gains, with a 2019 e-commerce study finding revenue rises by 4.0% for every 1 second improvement in load time.
report visual · Comparison
Where the Time Goes in Mobile Page Loads
A large share of mobile load time comes after the initial request—highlighting the importance of the request-to-render pipeline.
Core Web Vitals target for INP is 200 ms or faster200
37% of the total page load time on mobile is attributable to delays after the initial request (TTFB-to-LCP pipeline effe
37%
Core Web Vitals target for CLS is 0.1 or less
0.1
source-verifiedweb.dev
Reference
Cite This Report
This report is designed to be cited. We maintain stable URLs and versioned verification dates. Copy the format appropriate for your publication below.
APA
Catherine Wu. (2026, February 13). Website Load Time Statistics. Gitnux. https://gitnux.org/website-load-time-statistics
MLA
Catherine Wu. "Website Load Time Statistics." Gitnux, 13 Feb 2026, https://gitnux.org/website-load-time-statistics.
Chicago
Catherine Wu. 2026. "Website Load Time Statistics." Gitnux. https://gitnux.org/website-load-time-statistics.
Sources & references
25 datasets cited across this report
+16 additional datasets cited (not shown individually)