Preconnect
Overview
The networking stack implements the blink interface for the W3C Resource Hints preconnect specification to allow site developers to request connections to servers in anticipation of future requests. The predominant use cases are:
- sub-resources for the current page that the preload scanner is not capable of identifying. This can include resources discovered by styles being applied (background images, fonts) as well as resources initiated by scripts (analytics beacons, ads domains, etc).
- Top-level domains used in future navigations. For example, clinking on a link to an url shortener or click tracker that then redirects to the actual page. If the page knows the resulting final destination it can start initiating the connection in parallel with the navigation to the redirector.
Issue 450682 tracks the implementation as well as issues that came up during implementation and experimentation.
Implementation Notes
Connection Pools (not all connections are the same)
Chrome maintains separate connection pools for the various different protocols (http, https, ftp, etc). Additionally, separate connection pools are managed for connections where cookies can be transmitted and connections where they can not in order to prevent tracking of users when a request is determined to be private (when blocking cookies to third-party domains for example). The determination of which connection pool a request will use is made at request time and depends on the context in which it is being made. Top-level navigations go in the cookie-allowed pool while sub-resource requests get assigned a pool based on the domain of the request, the domain of the page and the user's privacy settings.
Connections can not move from one pool to another so the determination of which pool a connection will be assigned to needs to be made at the time when the connection is being established. In the case of TLS connections, the cost of not using a preconnected connection can be quite high, particularly on mobile devices with limited resources.
The initial implementation for preconnect did not take private mode into account and all connections were pre-connected in the cookies-allowed connection pool leading to situations where the preconnected connection was not leveraged for the future request.
Preconnect Connection Pool Selection Heuristic (proposed)
The two different use cases for preconnect require different treatment for determining which connection pool a connection should belong to. In the case of a sub-resource request the document URL should be considered and the relevant privacy settings should be evaluated. In the case of the top-level navigation the document URL should NOT be considered and the connection. There are no hints that the site owner can provide to indicate what kind of request will be needed so it is up to the browser to guess correctly.
For preconnect requests that are initiated while the document is being loaded (before the onload event while the HTML is being parsed and scripts are being executed), Chrome will assume that preconnect requests are going to be for sub-resources that are going to be requested in the context of the current document and the connection pool will be selected by taking the owning document's URL into account.
For preconnect requests that are initiated after the document has finished loading, Chrome will assume that preconnect requests will be used for future page navigations and the connections will not take the current document's URL into account when selecting a connection pool (which effectively means the connection will be established in the allows-cookies pool).
This does leave a few possible cases for mis-guessing but should handle the vast majority of cases. Specifically:
- Top-level navigations that are preconnected before the page has finished loading may end up in the wrong connection pool as the document's URL will be considered.
- Sub-resource requests that are preconnected after the page has finished loading may end up in the wrong pool if the request requires a private connection.