Time to First Byte (TTFB)
Lately Elon Musk has recently been publicly talking about performance of Twitter.
This article will talk about one important aspect of web performance, Time to First Byte (TTFB) and how changes have been made in this area to provide customers with a better experience.
TTFB is a metric that measures the time between a clients request and the time for the first byte of the response. This metric by itself won’t necessarily mean a website is performing well, but it is an important base metric to know as it plays a part in the perceived load speed, for example TTFB effects the Largest Contentful Paint (LCP) metric.
A good value for TTFB is 800ms and a poor time is over 1800ms:
Working on TTFB
Some typical problems with TTFB are slow infrastructure, databases etc. that reduce the ability of the origin servers to respond to requests quickly enough. At Domino’s we have tried to remove any bottlenecks with our servers by taking advantage of the following techniques:
1. Caching and reuse of content for multiple users can save on processing the same code over and over. Some webpages might have a mixture of content that is viewed by everyone and content that is viewed by a single customer only. This data can be split into different requests and the shared data can be cached. E.g. the basket is unique to a customer, therefore it isn’t cached or sent down on the original document request, but potentially the rest of the page can.
2. The above splitting of content then helps with rendering the cacheable content and storing it on a content delivery network’s (CDN) edge servers. There are usually more edge servers on a CDN than your own origin servers, and they are also likely to be closer to the customers devices.
This is beneficial for a couple of reasons, one, is that being closer to the customer means the response can travel faster as there is less network hops and physical distance, and secondly it takes load away origin servers, which helps against slow infrastructure and databases.
3. A large download size can reduce the effectiveness of the above two points, as a slow mobile connection can be very bandwidth limited, therefore you don’t want an initial document request of multiple megabytes even though it might perform fine on your local development machine.
The Domino’s homepage document size is currently under 70kB, but still includes styles and JavaScript that allows the browser to show relevant content quickly and doesn’t have any major flashes of unstyled content (FOUC). This was achieved by using methods like compression (gzip), minification and tree shaking.
Results
All the above techniques have had a positive impact on the TTFB, and the metrics like LCP it directly influences. Ultimately those metrics will improve a customer’s experience when visiting by allowing them to use and interact faster.
Useful links