Original: www.medianova.com/en-blog/201…
It is well known that website speed is governed by many factors. As messy as it is, sorting it out is not impossible. With that said, one metric you can try To read and improve on is TTFB (Time To First Byte).
This article will help you thoroughly understand the basics of TTFB’s impact on Web performance.
So, what exactly is the first byte time (TTFB)?
First Byte Time (TTFB) is the name given to the time between the end user’s first request to the Web server and the web server’s response to the end user.
The use of DNS to resolve the site’s address and retrieve the response to the initial request sent to the site are the main factors that cause this time to occur.
In other words, this occurs in the following three steps, and performance in these phases will play an active role during TTFB. The factors that may be important in each step are listed below:
Step 1: Submit the first request to the site address
- DNS response time (How many DNS requests are resolved on the end user side)
- The shorter the distance from the web server to the end user, the better
- Network stability
Step 2: The Web server parses the request
- Physical hardware response time (how fast the Web server can parse requests)
- Existing server operating load
- Any network – related delays in the data center
Step 3: Send the first response to the end user
- The network speed of the end user
- Connection stability
Good TTFB, bad TTFB
In fact, this question will vary depending on the content of your site. Depending on the percentage of your site’s content that is dynamic versus static, the judgment is different. In general, many speed testing tools give the following ranges:
- 0-75ms perfect
- 75 — 200ms ideal
- 200-500ms is not far, though not enough
- > 500ms has a problem
But a site made up entirely of dynamic data actually goes beyond these limits, and TTFB is always more reasonable to judge based on the content of the site.
What slows TTFB down?
The network problems in steps 1 and 3 mentioned above prolong TTFB.
Similarly, in Step 2, old hardware and problems on disk or memory caused slowdowns during request processing.
The low I/O value of the disk prevents fast processing and accumulates many queued requests.
Similarly, if the server hardware is inadequate to handle operations or instantaneous spikes in requests, this can lead to an extended TTFB.
Additionally, unoptimized code, database, and Web server configuration can delay incoming requests.
Finally, the software on the server that handles requests slows down.
How to speed up TTFB
Once pain points are known, initial response time can be reduced by:
- The first startup renders static data
- By using CDN, you bring your site content closer to the end user
- Code optimization: Software setup, coding performance improvements can speed up first page rendering
- Database query optimization: Database normalization and database operations must be overhauled
- Cache the data into memory
- Use the latest hardware whenever possible, such as a new CPU, SSD, or NVME SSD
The influence of CDN on TTFB
Basically, this is what you get with a robust CDN:
- CDN using Anycast DNS will use the nearest DNS server and speed up site access
- The request is routed to the nearest server
- The source server is only used to process new content, and the CDN caches static data
- More hardware resources available
TTFB’s impact on Web performance
In fact, because the first byte initiates the data return phase, TTFB is closely related to the performance of subsequent transactions.
Tuning TTFB will ensure that the rest of the site is more efficient. With a good TTFB paving the way, subsequent I/O operations will be faster.
On the other hand, the user experience is greatly improved by high performance. Because the site loads faster, fewer potential users will definitely leave because they can’t wait for the page to load.
–End–
View more front-end good article please search fewelife concern public number reprint please indicate the source