Over the years as this site has grown in both content and traffic and as my relative knowledge about developing performant websites hasn’t, I’ve been disappointed in the performance of this site. I have worked to improve the situation from time to time only to let it slide again when I’d move to a new host and as I’ve let my coding practices lag industry best practices.
In an effort to change that and improve both the performance of this site and my own understanding of the subject, I presented a short series a few months back that was meant to be the introduction to a longer series about performance.
As a reminder here’s the first series where I tried to set the context.
- An Introduction To The Performance Of Websites
- What Happens When Your Browser Requests a Web Page?
- What Are Performance Budgets And Why You Should Use One
- Performance Testing—Tools And Waterfall Diagrams
Today I want to get back to the series and look at things a little more in-depth than I did previously.
The Critical Path
In my article about the critical path I talked about what happens the moment you request a web page in a browser (or other device) to the point where it finishes loading. I said there were five distinct stages of the process.
- DNS Lookup
- Browser sends an HTTP request
- Server responds and sends back the requested HTML file
- Browser begins to render HTML
- Browser sends additional requests for objects embedded in the html file (CSS files, images, javascript, etc.)
The first three stages comprise the time to first byte (TTFB) and this second series within a series will begin to focus on how to optimize the TTFB of a web page.
This series will cover the first two steps in the critical path, DNS and HTTP. I’ll come back with another series not long after talking about servers and server response times and I’ll cover the last two steps at later date. I want to spend a little time in the remainder of this post giving you an overview of TTFB and I’ll dig into more details about optimizing performance for TTFB over the next few weeks.
I should say up front, that much of what will be in this series, isn’t going to have the greatest impact on performance. It will have some, but more significant impact will likely come from the series I’ll publish after this one.
However, when it comes to performance every millisecond counts, especially if it means keeping a few more visitors on your site. I also think this series will illuminate a few things about hosting websites on a server that many of us don’t pay much attention to.
What is Time to First Byte?
The time to first byte (TTFB) is all the time from the moment a request is made for a web page to the moment the first byte of data is delivered. It includes the time needed to send the HTTP request, make a DNS lookup, and create the HTTP handshake between client and server. It includes the time needed for the server to process the request and the time needed for the server to send back the first byte of the response to the client.
When the browser receives the first data packet, the TTFB is recorded. Keep in mind that not every file will have been delivered at this point, just the first byte of information; the first data packet.
- TTFB = DNS Lookup time + HTTP request time + Process request time + HTTP response time
Overall the time to first byte measures how fast the network and server are able to deliver the request and return the first packet of information for the requested HTML page.
What is a Good TTFB?
Figuring out a good TTFB was a little more difficult than looking up the definition. I found recommendations to be fewer and farther between.
I found recommendations to keep the TTFB of static content at 100ms or less and to keep the TTFB of dynamic content between 200ms and 500ms maximum. The recommendation I trusted most came from Google with a suggested 200ms as the upper limit for the time to first byte.
Given it’s expected that dynamic content will have a higher TTFB than static content, it makes a good argument that caching dynamic content will play a large role in reducing the time to first byte.
Since one of my goals is to improve this site, it makes sense to use this site as an example throughout. I ran the site’s home page through testers at WebPageTest.org and KeyCDN.com to discover I have a lot of work to do to get TTFB under 200ms.
Results can vary from test to test even using the same tool, but they typically don’t vary by a huge amount. Still, as much of this series will focus on changes to make improvements of milliseconds, it may not be obvious whether or not I’ve actually improved anything.
I’m guessing if I post before results here neither of us will remember what they were by the time I get to the after results. I know that’s true for me and so I’ll present both before and after results at the end of the series.
What I’ll Cover in This Series
Speaking of the end of the series, here’s a quick overview of the rest of this series as well as the next one on server resources.
The next couple of weeks I’ll dig into DNS, how you can specifically test DNS times, some general information about DNS, and a number of things we can do to reduce those times. The weeks following I want to look at HTTP requests and some of the ways to improve the times those requests take. As part of the subject I’ll look at HTTP/2 and briefly at HTTPS.
Finally I’ll talk about the specific DNS and HTTP changes I’ve made. I’ll talk about why I made the changes I did and I’ll show you the before and after results.
I originally planned on covering the third step in the critical path in this series, but as the series grew longer, I decided to push the third step to its own series, but I think I can safely tell you what will be included in that series.
I’ll cover hosting and servers, both hardware and software and ideally help you understand how to choose hosting beyond the advice to spend more to get better hosting. I’ll talk about things like which is more important CPU or disk space. On the software side I’ll talk about the pros and cons of running Apache and NGinx.
Then I’ll look at the performance issues of dynamic sites. What kind of issues might be caused by server side languages and how can we improve the performance of database-driven sites? Caching will be of prime concern for the latter. Since I run WordPress, I’ll probably spend one week running you through a caching plugin and how you might want to set one up.
I’ll cover more details of each topic than what I’ve just mentioned, but hopefully that gives you a good idea where both this and the next series are going. In time I’ll get to the fourth and fifth critical path steps.
Closing Thoughts
TTFB or time to first byte is the time a browser waits to receive the first data packets from a web server after requesting a web page. There are some things in regards to TTFB that we can’t control, but there are plenty of things we can improve and optimize.
While TTFB probably isn’t where the major performance bottlenecks are occurring with your site, it’s always possible you can make some improvements. In my case I hope to be able to shave a second or more of load time solely by improving the time to first byte and shaving a that much time is a significant improvement.
Next week I’ll start looking at DNS and what changes we can make to reduce the time of the lookup.
Download a free sample from my book, Design Fundamentals.