I assume that TTFB metric, relate to the HTML page that the Web server sends to his Web client in the “first-time phase” when the Web client connects the Web server.
But, what about the rest of the communication channel between the Web client and the Web server?
In case that the HTML page includes links to additional Resource\Assets such as Java Scripts and CSS file, the Web client will need to create an additional request asking for this “Resource\Assets”.
Given that the Web browser asks from the Web server to get a specific resource such as CSS file, do we still use the TTFB metric for measuring the amount of time until the Web browser gets the First Byte (of the CSS file in our example)?
Or, the use of the term “TTFB” is related only to the initialization phase in which the Web browser is “waiting” for the HTML page that the Web server needs to send?
TTFB - Time To First Byte - Time for DNS + Apache (or other server) to begin a connection.
TTS1 - Time To Serve Asset #1 - Time for LAMP to construct + send content.
Normally TTS1 is the killer. For example with WordPress (or any other CMS), consider several potential pitfalls.
Recently I had a client which was using ACF + to render each page took 700+ separate database selects. If well tuned MariaDB is being used, then pages will be fairly fast + in certain situation can cause problems. For example, the only way this type of site could possibly survive launch traffic, will be to use a mod_rewrite based caching plugin.
Another recent client was using a theme which generated 100+ separate database selects, so same consideration applies.
Redirection plugins are normally broken. Consider a redirection plugin managing 100 redirects, which is written by a poor coder. Here’s how most of these plugins work, which will shut a site down in no time.
a) For every page request…
b) Read each row (one by one).
c) Log matches + many times 404s.
In the case of no matches, you have 100 reads.
In the case of a match, you have reads till you hit a match, then a database write (sometimes many writes) describing the match.
In the case of 404s many redirection plugins log these too… For what reason… who knows.
You can see that a common link hit during a launch will either read all redirects + continue, which will require a mod_rewrite caching plugin… if the link has no redirect. If there is a redirect or 404 + database writes start pouring in, then the site will circle the drain quickly.
This also relates to the Pretty Links plugin, which is used on many sites.
Security plugins are another bane of serving content.
Because they log all manner of nonsense, 404s, page accesses. Everything you can get from your normal server logs or Google Analytics, security plugins duplicate.
Imagine the effect of TTS1 if there are 100s of writes/page across many poorly designed plugins.