How-To: Add Timing-Allow-Origin Header to Improve Your Website Performance Measurements
We all want our websites to load faster and to make them engaging so that users get what they want from the website. As a result, developers continuously employ a range of web performance solutions with the goal of improving end-user experiences and yielding high website conversion rates.
The key to ensuring great user experiences (UX) is to constantly measure and optimize the performance of different resources that load on a website. Whether it’s a first-party resource that you control or a third-party resource that you don’t control, understanding how fast and responsive these resources are on your users’ devices can greatly influence some of your website design goals and decisions and ultimately impact conversions and profitability.
Currently, browsers only report the resource timing information for resources that download from the same origin as the base page HTML. The timing information for resources downloaded from different origins is always reported as 0, except for the fetchStart and responseEnd fields to protect the privacy of users’ browsing activities from a malicious actor.
In December 2012, the W3C introduced the Timing-Allow-Origin (TAO) header that when present in an HTTP response header of a cross-origin resource can allow an included set of origins to read its timing information. The TAO header could also be a wildcard (*) allowing all origins to read its timing information. Note that TAO can add risks by allowing various side-channel attacks that enable attackers to leak private user information if it is presented on resources that are somehow customized to users’ interests. Therefore, the use of TAO should ideally be encouraged only on resources that are not user-personalized.
TAO enables website owners and surrogate content delivery network (CDN) infrastructures to build a richer resource timing dataset that their researchers and analysts could use to gain insights as to how well cross-origin resources perform on various user devices and network conditions.
For example, one could use such data to measure how responsive certain third-party resources are for mobile and non-mobile users and identify the ones that fail to respond in a timely manner. A richer resource timing dataset could also be useful to understand the performance of all first-party resources, especially the ones you control but are served from different origin hostnames.
Even though TAO allows detailed measurement of website resources, its adoption has fallen short among website owners. In 2013, only about 1.2% of the total resources embedded on a few hundred thousand websites presented the TAO header. After five years, this number has only managed to increase to 15%. Even with that 10x increase, we are in no way close to having that header added to most resources.
Today, on a median website, only 20% of the origins present the TAO header; this means the origin that loads the base page HTML cannot read the timing information of the resources that load from the other 80% of the origins and therefore cannot develop techniques to optimize their performance.
Many third-party origins, such as the ones from Google and online social networks, have already begun to take the first steps to add support for TAO and have thus enabled thousands of websites to measure their performance. This effort has helped to raise the adoption to 15%, but the adoption of TAO by these third parties alone is not sufficient to move the needle beyond 15%.
We need the first parties and the remaining third parties to consider adding TAO to their resources as well. While it is not recommended to present TAO on all resources, the goal of the web performance community should be to make sure that TAO is presented on 100% of the resources that are not user-personalized.
How to add the TAO header
Changing your web server configurations to present the TAO header is straightforward. For example, on Apache web server instances, using the Header directive, you can add the following line to the appropriate virtual host configuration:
Header add Timing-Allow-Origin "*"
The above line will allow all origins to read the timing information for the resource on which the above header is presented.
Alternatively, if you wish to allow only a specified set of origins to read the timing information, you could add the following line to your Apache configuration:
Header add Timing-Allow-Origin: “<origin_A>”
Header add Timing-Allow-Origin: “<origin_B>”
Header add Timing-Allow-Origin: “<origin_C>”
The above three lines will allow only origin_A, origin_B, and origin_C origins to read the timing information of the resource on which the above three lines are presented. For instructions on how to add response headers on Nginx web servers, check out this article.
Guidelines
If you are a website developer, here are four guidelines regarding TAO headers:
Understand the benefits and implications of adding the TAO header to your resources.
Ensure that subdomains and other alternately spelled domains embedded on your web pages present the TAO header in cases where the served resources are not user-customized. Note that where you prefer to provide a list of specific origins in the TAO header, security risks around the leakage of user information will be significantly minimized. Because the risk is minimal, you should consider adding the TAO header with an origin-specific list.
Reach out to the third-party vendors you use on your websites to check if they would consider adding the TAO header on their servers for resources that do not leak any private user data.
Finally, if your resources are used by other websites as third-party assets, raise the topic of adding the TAO headers on your resources with your architects, product managers, and security folks.
Once we all have worked on the four guidelines mentioned above, we hope to see wider adoption of the Timing-Allow-Origin header and could more precisely measure and optimize web performance.
Thanks to Akamai’s Martin Flack, Yoav Weiss, and Cliff Crocker for their help in refining some messaging in this blog post.