To be blunt, the vast majority of articles on the internet regarding lowering TTFB are utter nonsense created by content writers with no technical or performance optimization skills who are simply repeating what everyone else says online. We started to offer WordPress Speed Optimization Service few years back and we wanted to share things we have learned for people or companies who want to improve their WordPress or Woocommerce website on their own. There will be couple of these posts, so keep an eye out.
What Is Server Response Time?
The response time of a server is a broad indicator of its responsiveness. It refers to the time between the user’s request and the web browser receiving the first byte from the server (time to the first byte).
Although most blogs and publications claim that TTFB is unimportant, it is. Lowering the server response time enhances website speed, resulting in a better user experience. The lower the TTFB, the better.
What Qualifies as a Good TTFB?
The response time of a WordPress site is strongly dependent on location; we expect a good TTFB to be in the 0.1-0.2 second range for users in the country or continent where the site is hosted, and 0.2-0.5 seconds overseas.
According to Google’s standards, anything in the 200-600 ms range suggests good TTFB, but if it’s more than 500 ms, there’s some work to be done.
It’s a good idea to evaluate your TTFB as a starting point – several tools may check for TTFB timings ( SpeedVitals is one of them ) as well as other metrics and factors that affect it, such as DNS hosting speed and HTTP2 protocol capability.
Because site speed varies all the time, the result will change each time you do a test, so it’s best to run a few tests from different places (US, Europe, Asia, Australia). Keep in mind that the higher the TTFB, the further away the testing location or the visitor is.
We don’t suggest the Google Page Insight tool because it only analyzes speed from the United States in most circumstances, resulting in erratic speed averages.
This is one of the site we can take a look. If you notice, our average TTFB is 11.6 seconds and America doesn’t load at all. This is a major issue for the website and should be fixed ASAP.
How To Reduce TTFB or Server Response Time Step by Step Guide
1. Use Fast DNS Hosting
Your TTFB is heavily influenced by the speed and quality of your DNS hosting. You can reduce server response times by using fast DNS hosting.
As a DNS host, we usually prefer Cloudflare. According to dnsperf.com, Cloudflare is usually one of the top three fastest DNS hosts in the globe.
If Cloudflare isn’t an option, we recommend Amazon CloudFront, Faslty, or Digitalocean DNS. They’re also quick, dependable, and have an easy-to-use UI. Some have better benefits than others, but CloudFlare is free and a fantastic place to start.
If you’re doing a DNS hosting migration yourself, keep in mind that every single DNS record from the original DNS host’s source must be copied and relocated to the new host. Even missing one record can cause your IT system to fail, resulting in no email delivery in or out.
2. Use Good Hosting
You want your hosting to be as close as feasible to the majority of your visitors. We normally recommend Cloudways or Siteground for most small businesses. Website loading speed is one of most important parts of the website you should look at. Your slow website site damages your Google rankings and you lose clients as we speak.
3. Make Sure You Are Using HTTPS for HTTP2 protocol support
Despite the fact that the HTTP2 protocol was released in 2015, some hosts still do not support it. HTTP2 greatly improves the speed of communication between the browser and the hosting server.
Using Keycdn tools, test if your hosting supports the HTTP2 protocol.
4. Make Sure There Are No Issues With Your SSL Certificate
SSL Certificate is still something few companies ignore. Some internet providers will warn users before entering in websites that don’t use SSL certificate.
Check your website on SSL checker.
5. Use Page Caching in WordPress
Without Page Caching, you can’t really run a WordPress site. Pages are pre-built before a visitor visits the website when Page Caching is enabled.
All of the PHP processing and database lookups necessary to build the HTML file are completed ahead of time and saved in the page cache. When a visitor accesses the website, the server immediately gives the HTML file, resulting in a speedier site for the user and a significant reduction in server load.
A website generated from scratch typically takes 1-4 seconds, whereas a cached page is available in a few hundred milliseconds (0.2-0.5 seconds). The TTFB will generally equal the page production time if no page caching is used, so it will be in the 1-4 second range.
It’s worth noting that certain hosts have built-in caching capabilities. Caching features are sometimes installed, but they’re either not functional or aren’t turned on. This is worth looking at as a troubleshooting step if you’re using a managed WordPress host.
Another sort of caching that can help improve the TTFB of busy or database-heavy sites is object caching.
6. WordPress plugins that aren’t needed should be removed.
Nine out of ten WordPress websites on which we have worked had between 40 and 50 plugins installed. In some circumstances, much more. The highest number of plugins we have encountered was – 83. Sure, not all of them are continually active, but they are typically the most significant bottleneck in a WordPress-based website. More plugins lead to more problems, security threats, and, most of the time, a nightmare to keep up with the latest version of WordPress. Maintain a modest number of plugins and remove those that are no longer required.
7. Is the high TTFB only seen on the homepage or is it also on all pages?
Observe whether the TTFB problems are limited to the homepage or affect all pages. It is possible to accomplish this by testing the homepage and other pages on the site from various locations a number of times. Please double-check that the URL you’re testing is right. Sometimes the issue is merely due to the usage of an incorrect variant of the website’s URL. It’s possible that the “www” is missing at the beginning of the URL, or that it’s testing HTTP rather than HTTPS and that the redirect is producing the high TTFB.
If the homepage is the only page that is having problems, the problem could be caused by a plugin or something else that is running on that page that is slowing it down.
8. Make sure there is nothing in the.htaccess file that shouldn’t be there.
Without knowledge never touch your .htaccess file. Always make a backup and be ready to upload the file again. Wrong line and your website will not work.
A high latency to first byte can be caused by duplicate and excessive code in your htaccess file.
When someone manually adds performance optimization code to the htaccess file and then installs a caching plugin (such as WP Rocket) on top of that, the htaccess file frequently ends up with redundant caching code.
This will inevitably slow down TTFB and the overall site.
It can also be a problem if your htaccess file contains strange rules or contains hundreds of thousands of lines. If you have thousands of redirection, it’s worth looking at putting them all into a redirect plugin to reduce the impact on TTFB. NOTE: If these redirects are in the plugin, they will be performed by PHP rather than the htaccess file, therefore they may be slower.
9. Check to see that there are no 404 errors on the page.
404 errors can occasionally result in TTFB issues downstream, particularly if the file is referenced at a high level in the HTML or CSS code. In some circumstances, checking and resolving 404 errors may be sufficient to resolve a TTFB issue.
10. Examine the server logs (Apache and PHP).
If you are still troubleshooting, you should definitely start looking at the log files to figure out what is going on under the hood of your computer. Although Query Monitor should assist you in resolving the majority of mistakes, there may still be some issues occurring at a lower level of the hosting environment that are causing problems.
11. Disable the combination of Javascript and CSS minification.
Content on the web nearly usually instructs you to minify and combine CSS and JS in order to resolve TTFB issues – this is completely incorrect and accomplishes absolutely nothing in the case of TTFB. The opposite is true: combining those tools or minifying them with a plugin can actually result in a slowdown in server response times, which is undesirable.
Consider deactivating CSS minification or combining it with JS, and then running a performance test to see how much faster your site is. There have been instances where JS and CSS minification or merging have led to TTFB issues, particularly when one of those files has a 404 error associated with it.
12. Database Size and Storage Engines
A large number of people on the internet will advise you to enhance your database. The size of your database is a concern if it is excessively large; but, practically speaking, most WordPress databases are no larger than a few hundred megabytes. 5, 10, or 20 GB databases are thought to be enormous and, therefore, potentially problematic. But let’s concentrate on what really counts in this case, which is selecting the most appropriate storage engine for your database. WordPress makes use of the MySQL database, which has two different storage engines to choose from: InnoDB and MyISAM.
Imagine your database as a Google or Microsoft Excel spreadsheet to better understand the differences between the two types of databases. The MyISAM protocol would only allow editing of one of those sheets or tabs at a time, which means that the tab in which the editing is taking place would be locked while it is being modified. Accordingly, from the database’s perspective, users are accessing the site as WordPress attempts to write information into the database. Because only one operation can be carried out at a time, one of these operations must be placed on hold. This signifies that the table has been locked, operations have begun to queue up, and as a result, things are slowing down significantly.
InnoDB, on the other hand, does not prevent the opening of new tabs. Locking is only possible at the row level, which means that only one user can edit a row on the sheet or table at a time. This is rarely a problem because it is uncommon for numerous rows to be changed at the same time in a table.
There are a variety of options for converting from MyISAM to InnoDB.
What Doesn’t Work
As previously stated, minifying or merging your TTFB or the overall performance of your site will not result in any significant improvement. It’s also important not to fall for bogus recommendations that tell you to fiddle with the WordPress heartbeat, because doing so has no effect. In fact, it has the potential to cause problems. Cleaning the database will likewise accomplish nothing, as previously said, therefore instead of cleaning the database, examine the storage engines.
Do you want someone to fix it for you?
We’ve optimized over 1000 WordPress sites and can assist you in making yours load as quickly as possible as well! To hire someone to do this for you, see our contact page, and a member of our staff will analyze your site and advise you on what you can do to improve the speed of it.
