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

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 an encryption layer (TLS). The process of negotiating these 2 connections will take a little bit 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:

• 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.

• 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 handshake 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.