Optimize the connection duration (TCP + TLS) sub-part of the Time to First Byte

The connection duration of the TTFB consists of setting up the TCP and TLS connection. Understand the sub-part of the TTFB to reduce the total time to first byte

Arjen Karel Core Web Vitals Consultant
Arjen Karel
linkedin
  1. Core Web Vitals
  2. Time to first byte
  3. Connectionduration

Optimize the connection duration (TCP + TLS) sub-part of the Time to First Byte

The Time to First Byte (TTFB) can be broken down into the following sub-parts:

  • Waiting + Redirect (or waiting duration)
  • Worker + Cache (or cache duration)
  • DNS (or DNS duration)
  • Connection  (or connection duration)
  • Request (or request duration)

Looking to optimize the Time to First byte? This article provides an in-depth analysis of the DNS duration part of the Time to First Byte. If you are looking to understand or fix the time to first byte and do not know what the waiting duration means please what is the time to first byte and fix and identify time to first byte issues before you start with this article

The connection duration part of the time to first byte consists of some time where the browser is connecting to the web server. After that connection the browser and server will usually add and encryption layer (TLS). The process of negotiating these 2 connections will take a little but of time and that time is added to the Time to First Byte.


Connection process in detail

The Transmission Control Protocol (TCP) is responsible for establishing a reliable connection between the client (browser) and the server. This process involves a three-way handshake:

tcp 3 way handshake

  • SYN (Synchronize) Packet: The client sends a SYN packet to the server to initiate the connection and request synchronization.
  • SYN-ACK (Synchronize-Acknowledge) Packet: The server responds with a SYN-ACK packet, acknowledging the receipt of the SYN packet and agreeing to establish a connection.
  • ACK (Acknowledge) Packet: The client sends an ACK packet back to the server, confirming the receipt of the SYN-ACK packet. At this point, a TCP connection is established, allowing data to be transferred reliably between the client and server.

TCP ensures that data is sent and received in the correct order, resending any lost packets and managing flow control to match the network's capacity.

Once the TCP connection is established, the Transport Layer Security (TLS) protocol is used to secure the connection. The TLS handshake involves several steps to authenticate the server and establish a secure communication channel:

  • ClientHello: The client sends a "ClientHello" message to the server, indicating the supported TLS versions, cipher suites, and a random number (Client Random).
  • ServerHello: The server responds with a "ServerHello" message, selecting the TLS version and cipher suite from the client's list, and providing its digital certificate and a random number (Server Random).
  • Certificate and Key Exchange: The server sends its digital certificate to the client for authentication. The client verifies the certificate against trusted certificate authorities.
  • Premaster Secret: The client generates a premaster secret, encrypts it with the server's public key (from the certificate), and sends it to the server.
  • Session Key Generation: Both the client and server use the premaster secret, along with the Client Random and Server Random, to generate a shared session key for symmetric encryption.
  • Finished Messages: The client and server exchange messages encrypted with the session key to confirm that the handshake was successful and that both parties have the correct session key.

Once the TLS handshake is complete, the client and server have established a secure, encrypted connection. This ensures that any data exchanged is protected from eavesdropping and tampering by third parties.

HTTP/3 speeds up TLS connections by integrating with the QUIC protocol, which reduces the number of round trips needed to establish a secure connection by combining the handshake processes into one, and supports 0-RTT resumption for faster reconnections. Additionally, QUIC's use of UDP eliminates head-of-line blocking and improves congestion control, leading to more efficient data transmission and quicker page loads.

How does the connection time impact the Time to first byte?
The TCP and TLS protocols impact the Time to First Byte (TTFB) by introducing both latency and computational overhead during the initial connection setup. The TCP connection requires a three-way handshake to establish a reliable connection, which adds round-trip time delays. The TLS handshake, necessary for securing the connection, adds additional round trips to negotiate encryption parameters and verify certificates. 

This combined process can add real delays to the TTFB, especially if network conditions are not optimal or if older versions of TLS are used (which require more round trips compared to newer versions like TLS 1.3)

How to minimize Connection time Impact on the TTFB

To minimize the impact the connection time has on the TTFB the most viable thing to do is configuring your webserver to use the latest technologies like http/3 and TLS 1.3. Also ensure the webserver is geographically close to your visitors since the connection time requires multiple round trips the physical distance to the server also impacts the connection time. For sites with a global audience a CDN is the only way to ensure short connection round-trips.

When looking to optimize server settings these are settings that could be enabled or configured to speed up the connection duration:

  • HTTP/3 - brings the QUIC protocol over UDP instead of TCP, allowing for faster and more efficient data transfer
  • TLS 1.3 Adds more security and reduces handshare round trips and is required for 0-RTT Connection resumption. 
  • 0-RTT Connection Resumption - TLS 1.3 feature that allows returning clients to send encrypted data immediately upon reconnection by re-using previously exchanged  information.
  • TCP Fast Open. Enables data to be sent in the initial SYN packet, reducing the round-trip time for the TCP handshake.
  • TLS false start - Allows early sending of data before the TSL handshake is complete.
  • OCSP Stapling -  Speeds up certificate validation by eliminating the need for the client to contact the certificate authority directly

Time to Fist Byte TIP: not only does a CDN deliver shorter round trip times. Leveraging a CDN will often immediately improve TCP and TLS connection times because premium CDN providers will have correctly configured these settings for you!

How to find TTFB issues caused by slow connection time

To find the impact that real users experience caused by redirect you will need to use a RUM tool like CoreDash. Real user monitoring will let you track the Core Web Vitals into greater detail and without the 28 day Google delay.

In CoreDash simply 'click on Time to Fist Byte breakdown' to visualize the connection part of the Time to First Byte.  

ttfb dns coredash breakdown



Optimize the connection duration (TCP + TLS) sub-part of the Time to First ByteCore Web Vitals Optimize the connection duration (TCP + TLS) sub-part of the Time to First Byte