DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Building Scalable Real-Time Apps with AstraDB and Vaadin
Register Now

Trending

  • Top 10 Engineering KPIs Technical Leaders Should Know
  • Implementing a Serverless DevOps Pipeline With AWS Lambda and CodePipeline
  • DevOps Midwest: A Community Event Full of DevSecOps Best Practices
  • Micro Frontends on Monorepo With Remote State Management

Trending

  • Top 10 Engineering KPIs Technical Leaders Should Know
  • Implementing a Serverless DevOps Pipeline With AWS Lambda and CodePipeline
  • DevOps Midwest: A Community Event Full of DevSecOps Best Practices
  • Micro Frontends on Monorepo With Remote State Management
  1. DZone
  2. Data Engineering
  3. Databases
  4. How to Improve the Resource Timing API

How to Improve the Resource Timing API

Mehdi Daoudi user avatar by
Mehdi Daoudi
·
Jan. 27, 15 · Interview
Like (0)
Save
Tweet
Share
3.10K Views

Join the DZone community and get the full member experience.

Join For Free

 [This article was written by Ryan Pelette.]

Getting visibility into webpage performance as experienced by the end user is key to any company. Over the last couple of years the amount of Real User Measurement methods and tools available to DevOps teams has skyrocketed to meet this demand.

However, the key method we all rely on to collect the data, the Navigation Timing API, lacks visibility of third party performance, or really anything other than the root request timing and page level metrics. Luckily the W3C was kind enough to work the Resource Timing API Specification to help fill that gap, and the spec was adopted by Chrome, Firefox, and IE. Sadly, as Steve Souders pointed out in November, there is a major shortcoming with this API to the point that it is rendered almost useless.

Resource Timing Shortcomings

The Resource Timing API allows developers to get the following data on each URL loaded from the page:

  • connectEnd*
  • connectStart*
  • domainLookupEnd*
  • domainLookupStart*
  • duration
  • entryType
  • fetchStart
  • initiatorType
  • name
  • redirectEnd*
  • redirectStart*
  • requestStart*
  • responseEnd
  • responseStart*
  • secureConnectionStart*
  • startTime

For any content that doesn’t share the same domain as the document (i.e. any third parties and domain sharding), additional steps are required to obtain any of the metrics above that are marked with an asterisk. To get them, each HTTP response must include the Timing-Allow-Origin header. Without including the header, the closest metric for understanding the impact of a particular request is “Duration.”

Sadly, few third parties have implemented this header; Facebook is the most prominent to have done so. But Google, probably the largest third party provider on the web when you factor in their Ads and Analytics platforms, is a supporter of the API in Chrome, but has yet to adopt the header for their many products.

Unfortunately, duration is flawed since it includes the time the request was blocked by another request or the rendering logic of the browser. In other words, it includes a portion of time that is due to the page rendering (not the servers), and another portion encompassing the communication over the network.

Relying on this data to report on third party performance is a huge red herring and can place the blame on providers who actually had little or no impact on perceived and total load times of the page. For this reason, we at Catchpoint have delayed inclusion of any features utilizing the Resource Timing API in Glimpse, our Real User Measurement Product.

The Duration Trap

Interestingly, the issue of “Duration” including browser time also impacts network browser tools like Chrome Developer, Firefox Developer Tools, and Firebug. In these tools, the “Duration” metric for each request listed includes Blocked (or Stalled) time – which is the time between the browsers detecting the request and starting an HTTP request.

Clearly the developers of the tools followed what seems logical from the browser perspective; the Duration is the time from detecting the request to finishing it. However, the end users of these tools often read it from their perspective, i.e. how long it took for the URL to finish loading.

Fixing the API

To solve the shortcomings of the API, Steve Souders proposed a new metric called “networkDuration” (domainLookupStart to responseEnd). While the addition of “networkDuration” in the API would be a great gift for all of us RUM fanatics (Steve kicked off this request here), we propose that the need for Timing-Allow-Origin be removed entirely from the Specification.

The “networkDuration” is the sum of the various components (DNS, Connect, TTFB, etc) and is not offering any more privacy protection than providing each of the values. The privacy concerns over knowing how a URL performed are minimal, as revealing this data would hardly impact any company (you can measure this data through the browser network tools or synthetically today). Neither does this data impact the privacy of the end user, as none of the values are from user behavior or personal information – nothing private between the end user and the target server.

If anything, the owner of the webpage must demand that the performance data of their partners – the third parties on the page – is available to them as owners since it impacts their performance. Since the end user is ignorant about the third parties, any performance issue they perceive on the page is attributed to the webpage (or their internet connection) rather than the real culprit(s).

And as long as we’re enhancing the spec, it would be great if we could get something added regarding support entries of URLs that fail. Those which time out are currently not reported on at all, leaving another hole in the visibility that it provides.

Conclusion

Today’s Real User Measurement methods and tools do not provide clear insight into the performance of URLs loaded by the page from other domains. Those who rely on the Resource Timing API might be collecting the wrong measurements and pointing fingers at the wrong companies.

It is time to change this API. Let’s remove the privacy limitations it has – they are not protecting anything valuable, they are simply impeding companies from measuring clearly what they must measure.

API

Published at DZone with permission of Mehdi Daoudi, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • Top 10 Engineering KPIs Technical Leaders Should Know
  • Implementing a Serverless DevOps Pipeline With AWS Lambda and CodePipeline
  • DevOps Midwest: A Community Event Full of DevSecOps Best Practices
  • Micro Frontends on Monorepo With Remote State Management

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: