TLS time

Before the client and the server can begin exchanging application data over TLS, the encrypted tunnel must be negotiated: the client and the server must agree on the version of the TLS protocol, choose the ciphersuite, and verify certificates if necessary. This TLS handshake process directly follows the TCP session three-way handshake.

The figure above shows the standard TLS handshake. The whole process requires two roundtrips. So network conditions can greatly affect the TLS time.

Nevertheless, the network performance is not the only parameter to take into account. The newly TLS 1.3 standard reduces this TLS handshake process to only one roundtrip. So depending on the distance between the client and the server, using TLS 1.3 can really improve overall connection performances. Other techniques like "TLS False Start" can also be used to optimize this TLS handshake process.

Kadiska measures the TLS time. From a W3C Time Navigation API standpoint, TLS = connectEnd - secureConnectStart.

This metric is included in the "Network Setup" part of the "Navigation" and "Resources levels.

If you are looking for the TLS value itself, open a "Network" Section. In this section, TLS is provided in a time series together with two other network metrics (DNS and CT).

This section also provides TLS values per location (continent, country, region and city):

This information is also provided by ISP (Internet Service Provider).

Finally, from the "Network" section, select "Network TLS" section to see:

1. The TLS evolution with the geolocation of clients and corresponding TLS performances
2. The TLS distribution
3. The TLS performance per ISP
4. The TLS performance per Host
5. The TLS performance per OS/Device/Browser