What is TTFB
TTFB measures the duration from the user or client making an HTTP request to the first byte of the page being received by the client's browser. This time is made up of the socket connection time, the time taken to send the HTTP request, and the time taken to get the first byte of the page."...
Translating technical description to plain text for common owners of a website:
Why TTFB deserves attention
- "Nobody Likes a Slow Website" (Pingdom Website Speed Test)
- Faster webpages get better ratings (by Google, users, partners...) that slower alternatives which translates into more visits.
Big TTFB leads to slow page and that makes UX worse
For website visitors the "perceived speed" is one of the most important parameters for their browsing UX. One of key performance indicators of this speed-perception is TTFB as it is the moment when he gets a feeling "Ok, something happened and I will see content in a very short time". Waiting until TTFB seems like "passive time" during which they stare at a blank screen, look at some loading icon and are not able to do anything to speed things up. These time spans are often very short - measured in miliseconds and even the longer ones take only a couple of seconds. But in the era of fast internet speeds and "instant" reactions by their phones, seconds while browsing probably make some of them feel "powerless". Definitely not the menthal state somebody wants to return to.
TTFB time became very critical for UX as users' patience is not on the list of things a webpage owner can count on. Site with TTFB being too long will be perceived as slow, laggy, un-responsive... Not a great position to be in.
Speed of page affects your SEO
Then there is the famous SEO rule that Google rewards faster pages with a better score and crawls them more often while punishing slow ones by reducing their rank among search results. It seems reasonable: if they redirect someone to your page, it is sort of a reccomendation by them. They do not want to see that user come back frustrated that he was not able to see the desired content due to your slow site.
Also, consider that Google crawler is not really unlimited in resources. Going trough your sitemap and waiting for each page for 3sec+ before they can store it into their database means they are wasting their resources on someone obviously not up to the task or not having enough interest to optimize his webpage. Either way common wisdom and wise business commands tweaking the alghoritm to crawl slow sites less often.
This thrive for (really) fast web and "instantaneous" goes so far that in some cases a site will fake completing an action i.e. clicking a LIKE button will instantly change the grey heart into a red one, indicating a "like" by the user even though the backend server is yet to receive this information, process it, save the data to the database and return a response about the new status by this user. It will be done in the background carrying the risk of not successfully completing the task as the priority lies with the user receiving "instant satisfaction", god forbid having to wait for small, non-essential taks like this.
What is recommended TTFB
Simple answer is: The lower, the better. As it can not be 0, here are some recommendations for general orientation:
- Google finds TTFB under 200ms to be a very good results,
- 3 sec is the limit where users start to departure the site not willing to wait for slow loading times.
- If you want to know why tech-giants deeply care about it: famous Amazon research concluded that they loose millions of $USD with each additional second of loading time (while basically being a monopolist of e-commerce).
Rare users notice that a page is fast, but all users notice when a page is slow.
Keep in mind that users will not give you a pass for your site being much slower than those of tech giants and often used services like Google search, Facebook, Pinterest, AliExpress, Nike webshop... They set the standards and all others have to come as close as possible. If your site is too slow, people will try to find a way to make it done via faster channels.
Time to first byte, Wikipedia
It is safe to conclude that lower TTFB adds to a better UX and better websites' success. If those are among your goals, keeping TTFB low should be quite high on your priorities list.
Difficulties when trying to reduce TTFB
For this task it is important to understand what exactly TTFB time consists of:
- Making the connection with the server that hosts the webpage (via DNS servers);
- Securing the connection with a https/SSL handshake (if applied);
- Time for the server to prepare the response (for requested URL);
- Traveling distance for data between the server and the user;
Points (1) and (2) are almost never an issue while also being mostly out of control for common website owners.
Most often the biggest part of TTFB is (3) server preparing the response (often in a form of HTML, but cab also be as JSON, XML...). Time required for this operation depends on hardware speed, load on a server, code, programming language used, cache, database lookups, file lookups, parameteres like user ID, personalized content... If your TTFB is too long, this is where you start your optimizations.
Distance (4) can be a factor if you are serving global audience and want your site to really fast for all users. For local and regional audience it's often quite small (0-300ms).
Reducing TTFB while keeping "heavy" templates, personalized content etc. can be among the most difficult things for common website owners. It takes profound understanding of elements that affect loading times, the meaning of cache and the tradeoffs that come with it, knowing/understanding/maintaining good code etc.
What is the single best way for TTFB reduction for websites?
CACHE. Fast web is very predicated on cached content. Regardless of the type of cache being utilized (browser cache, full page cache, partial cache, reverse proxy cache, DB queries cache,...) cache can reduce the time required for some action much more than can be achieved by utilizing faster servers, changing the programming language, optimizing the code... If you need something to be truly fast, it almost certainly needs to be cached.
Of course, cache brings some of the compromises with it, so it is imperative that you understand how cache works and where it can be used.