What is requestStart?
The requestStart read-only property returns a DOMHighResTimeStamp representing the exact moment immediately before the browser starts requesting a resource from the server, cache, or local resource. This property is part of the PerformanceResourceTiming interface, which provides detailed timing information about how resources load on a web page.
Understanding requestStart requires placing it within the broader context of the Performance API. When a browser needs to fetch a resource—whether it's an image, script, stylesheet, or font—it goes through a series of phases: DNS resolution, TCP connection establishment, TLS handshake (for HTTPS), and finally, HTTP request transmission.
The significance of this property lies in what it enables developers to measure. By calculating the difference between responseStart (when the first byte of the response arrives) and requestStart, you can precisely measure request latency—the time the server takes to process the request and begin returning data. For a comprehensive understanding of timing metrics, pair this with our guide on Performance Timing to build complete visibility into your resource loading performance.
Key Characteristics
Several important characteristics define how requestStart behaves in different scenarios. First, if the resource is retrieved instantaneously from a browser cache, requestStart will return a value of 0 since no actual network request occurs. This behavior makes sense because when serving from cache, there is no meaningful requestStart timestamp to record.
Second, for cross-origin resources, requestStart may return 0 unless the server includes the appropriate Timing-Allow-Origin HTTP response header. This security measure prevents timing information from being used in cross-origin attacks, but it also means that cross-origin performance monitoring requires explicit server cooperation.
Third, if the transport connection fails and the browser retries the request, requestStart will reflect the start time of the retry rather than the original failed attempt. This behavior ensures that the timing data reflects the successful request rather than including irrelevant failure time.
For more information, see our web development page.
For more information, see our web design page.
1// Access existing resource timing entries2const resources = performance.getEntriesByType("resource");3resources.forEach((entry) => {4 const requestLatency = entry.responseStart - entry.requestStart;5 if (requestLatency > 0) {6 console.log(`${entry.name}: Request latency: ${requestLatency.toFixed(2)}ms`);7 }8});1const observer = new PerformanceObserver((list) => {2 list.getEntries().forEach((entry) => {3 const requestLatency = entry.responseStart - entry.requestStart;4 if (requestLatency > 0) {5 // Log or send to analytics6 console.log(`Resource: ${entry.name}, Request Latency: ${requestLatency.toFixed(2)}ms`);7 }8 });9});10 11// Observe resource timing entries as they are recorded12observer.observe({ type: "resource", buffered: true });Practical applications of requestStart measurements
Identify Server Bottlenecks
High request latency across multiple resources indicates server-side issues like slow database queries or resource contention.
Set Performance Baselines
Establish expected timing characteristics and budgets to detect performance regressions early.
Correlate with Core Web Vitals
Request latency impacts Largest Contentful Paint (LCP), helping prioritize critical rendering optimizations.
Monitor Third-Party Resources
Track performance of CDN, analytics, and advertising resources that affect overall page load.
Sources
- MDN Web Docs: PerformanceResourceTiming requestStart - Primary definition and usage examples
- MDN Web Docs: Navigation and Resource Timings - Timing hierarchy and context
- W3C Resource Timing Level 2 Specification - Technical specification
For more information, see our web development page.
For more information, see our web design page.