Reduce Initial Server Response Time for WordPress

What is TTFB and Server Response time?

TTFB stands for Time To First Byte. The time to first byte is the amount of time between the initial page request (from the browser) and the first byte of page output reaching the browser.

Server response time is effectively a part of TTFB. This is how long it takes for the server to process the request for the page and start generating page output.

Consequently server response time is more specific to server side processing, where as TTFB takes additional factors in to account, which include the initial DNS lookup, network latencey, and server response time (the time it takes the server to process the request).

Although TTFB and server response times are technically two different things (with one being part of the other), they’re both closely related, and are often interchangeable in terms of terminology.

Do TTFB and server response times matter?

Google Page Speed insights (https://pagespeed.web.dev/) shows you the performance metrics for your site. These performance metrics are part of what’s used to determine page ranking in google search results. Consequently if you want your site to rank well and be easily found, not only is it going to have to be SEO optimised, but it’s also going to need to have good performance metrics.

So if search engine rankings are important to you, server response times and TTFB do matter.

Although Google don’t directly measure TTFB and server response times as a direct, individual metric, TTFB and server response times preceed other metrics that Google measures, such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP).

First Contentful Paint is the time between a page being requested and the first part of page content being rendered by the browser.

Largest Contentful Paint is the time between a page being requested and the largest part of page content being rendered by the browser.

If your site has a slow TTFB or a slow server response time, the time between a page being requested and FCP or LCP is increased simply due to the increased TTFB.

You can find an explanation of how a browser renders a page in this post.

The simplest way to think about TTFB and server response times would most likely be along the lines of:

“A slow TTFB/server response time causes other measured performance metrics to be slow”.

How TTFB is measured.

When a page is requested, there are steps, or pahses, that make up a request. TTFB is a sum of the following pahses:

• Redirect time
• Service worker start up time (not always applicable)
• DNS lookup
• Connection and TLS (HTTPS) negotiation
• Request (up until the first byte is served)

In a more graphical form this looks like:

The server response time is only part of the above, and therefore part of TTFB, which is from “Request start” to “Response end” and it’s (mostly) what’s going on in your WordPress installation that this is specific to.

As you can see from the above, there’s quite a lot that’s upstream of your site, and upstream of the web server that can affect TTFB:

• Redirect
• Worker start
• Fetch start
• HTTP cache
• DNS
• TCP

And the parts that are also part of TTFB and server response time:

• Request start
• Interim request start
• Response start

And the part that’s only specific to server response time:

• Response start to response end

All of the above, combined, cover both TTFB and server response time.

As you can see there’s a lot of factors involved here, starting with DNS and network latency going all the way through to the request being processed and served (by your WordPress installation).

As you’ve most likely noticed, some of these factors aren’t actually “within” your WordPress, but are upstream of it.

Due to this, the actions you may need to undertake aren’t always going to be something carried out within your WordPress installation.

What is a good TTFB?

There are tools such as SpeedVitals and KeyCDN that you can use to test your site’s TTFB.

Page speed insights flags a TTFB of 600ms or more as probelmatic, but recommends a TTFB of 200ms or less, so:

• TTFB of 200ms or less = GOOD
• TTFB of 200ms to 600ms = Will pass core web vitals, but could be better
• TTFB of more than 600ms = Fails core web vitals, so needs to be improved

Page Speed Insights will also flag the following problem if your site has a poor server response time:

Hosting and poor TTFB and slow server response times.

As I’ve mentioned above, there are a lot of factors that affect TTFB and server response times.

Some of these factors you have a degree of control over, but there’s one that you might not have any control over, and that’s hosting.

There’s a lot of variables when it comes to hosting. Different types of web servers, different types of database servers, if you’re using shared or dedicated hosting, and what else the server is doing when it receives a request for your site.

If you have your own server you’ll have a greater degree of control over the server itself, and things like what web server and database server is in use. On the other hand, if you’re using shared hosting, you won’t have any control over these, and your site is held on a server containing sites belonging to other people.

Also, I hate to break it to you, but web hosting providers don’t have a magic “speed up the hosting” button.

Shared hosting is likely to be slower, but it is cheaper, and you there are things that you can (usually) do if you’re using shared hosting that will help with server response times and TTFB.

Shared hosting advice:

• Check that your hosting provides enough RAM and CPU to handle your WordPress, upgrade to obtain more RAM and CPU if your site causes these limits to be reached.
• Check your hosting provider regularly applies updates.
• Aim to obtain hosting that provides facilities to improve performance (such as object caching being available)
• Aim to use hosting that provides up to date technologies, such as the Litespeed web server.
• Use a CDN in addition to shared hosting to supplement your site’s performance.
• If your site receives large amounts of traffic, consider upgrading to your own server.

Obviously some of what I’ve mentioned above involves paying more money.

If you’ve got a lot of money to allocate to running your site, investing in good hosting is advisable.

That said, you can get a fairly decent TTFB on shared hosting that doesn’t cost a great deal, and there are some CDNs that can be used for free.

Based on my experience, if you spend less, you’re likely to have to put more effort in to other TTFB and server response time related factors. You’ll also need to have a fairly reasonable grasp of how everything works, and how to apply the guidance you’ll read with regard to TTFB and server response times. What you don’t pay in money, you can end up paying in time, effort, and educating yourself. It is possible, just harder.

To give you some perspective, I run this site on shared hosting (£8.99 plus VAT per month) that has the Litespeed web server and object caching available by default, I’m also using the free version of the QUIC.cloud CDN, and Cloudflare’s free plan, so my costs are pretty low, and I’ve got a TTFB of under 200ms for almost all locations in Europe and the United States that SpeedVitals measures. Mind you, I’ve had to work to get that to what it is!

Really, what I’m saying here is that it is possible to get a decent TTFB when using shared hosting, but you have to work for it.

How to improve TTFB and server response times.

As you’ll know by now, there are numerous factors that affect TTFB and server response times. Both the site itself, and the components in between the site and the browser have some effect on TTFB and server response times.

Let’s start with the site and work back toward the client:

• WordPress and site code execution.
• WordPress and site database queries.
• Page output compression.
• WordPress and site caching.
• Hosting PHP.
• Hosting TLS version.
• HTTP/3.
• Network latency.
• DNS lookup overhead.

Now let’s take a look at these one by one, and what can be done to improve TTFB and server response times.

WordPress and site code execution.

Your WordPress executes as a whole to serve a page. This includes all plugins and theme code, as well as WordPress core. Reducing the number of plugins in use reduces the total amount of code being executed, so initially you might try reducing the number of plugins you’re using.

Plugins and themes can vary as well. You can occasionally have bottlenecks in plugin code. This is when there’s some kind of aspect of the plugin code that takes a long time to execute.

If you have your own server it’s possible to use some kind of application performance monitoring such as New Relic or if you’re using Cloudlinux you may be able to use Cloudlinux’ Xray performance monitoring to identify bottlnecks in code. Although this might help you identify slow aspects of code, unless you can write code, you might not be able to address these issues, and you might only be able to disable the respective plugin or switch themes.

There is the Code Profiler plugin for WordPress which you can use in a similar way, but you have to be using the paid version for granular reports to be generated. The free version alone does show you some basic, yet handy information, such as which plugins have high execution times.

You’d install and activate this plugin like you would any other:

After installing this plugin, click on “Code profiler” in the menu on the left hand side of your WordPress dashboard, then select a page to profile (preferably a slow one), then click on “Start profiling”:

And the code profiler plugin will then generate a report:

As you can see the report shows that Astra has a higher execution time compared to other components, and I’m also warned about Solid Security using Composer. An execution time of 0.7 isn’t particularly high for a theme, this report effectively exaggerates this as there are few components that have a long execution time.

The reason Composer is mentioned is because if you gave more than one plugin that’s using Composer, it can cause plugins to slow down. This is because Composer will load the plugin classes for both plugins when the call for the first plugin takes place.

In practical terms based on the report that’s generated doing something like using a different theme (then checking it’s execution time in WordPress) and using a different security plugin (if multiple plugins are using Composer) might well be a suitable course of action.

It would also be advisable to remove the code profiler plugin once you’ve gained the required information so that it’s code is no longer executed.

WordPress and site code execution – summary

• Identify site components with high execution times (using an application performance monitor or code profiler).
• Replace or remove components with high execution times.
• Uninstall the code profiler plugin when you’ve obtained the required information (if this is the method you used).

WordPress and site database queries.

The site’s database is heavily involved with page output when using WordPress. This is because all your page and post content is stored in the database. Consequently the database has to be queried for page output to be generated. Large numbers of queries, or large numbers of tables, or large numbers of rows in tables can cause a delay in a response being served.

The MySQL query monitor plugin can be used to establish which queries and which components have lenghty queries. You’d install and activate this plugin just like you would any other plugin:

After installing and activating this plugin, when logged in as an adminsitrator you can browser a page on your website and you’ll see some timings at the top of the page (see screen shot below) and clicking on these gives a breakdown of MySQL queries. You can then click on the “time” and the “rows” coumn headings to sort queries by time and by the number of rows involved:

Again, you have the option of removing plugins that have a high time or row overhead, but there are steps you can take as an alternative initial measure:

• Clean up the database
• Add keys (or indexes) to database tables

Cleaning up the database.

The WP Optimize plugin is good for cleaning the site’s database. You’d install and activate this plugin just like any other plugin:

After ativating this plugin hover over “WP-Optimize” in the menu on the left hand side of your WordPress dashboard, then click on “Database”:

BEFORE YOU CARRY OUT THIS NEXT STEP MAKE SURE YOU HAVE A BACKUP AVAILABLE!

Once on the database page, you’ll see a list of potential optimisations that you can undertake on the site’s database:

You can either run all the optimisations in one go by clicking the blue “Run all selected optimizations” button toward the top right, or you can run individual optimisations using the “Run optimizations” buttons down the left hand side.

What you’re doing here is removing data that isn’t used (but is still queired) to generate page output.

After carrying out the optimisations, uninstall the WP Optimize plugin.

Add keys (or indexes) to database tables.

You can use the Index WP MySQL For Speed plugin to do this automatically. You’d install and activate this plugin just like you would any other.

After installing and activting, hover over “tools” in the menu on the left hand side of your WordPress dashboard, then click on “Index MySQL”:

BEFORE YOU CARRY OUT THIS NEXT STEP MAKE SURE YOU HAVE A BACKUP AVAILABLE!

It’s then just a case of selecting all the tables, then clicking “Add keys now”:

After you’ve added the keys, you can then uninstall this plugin. The keys will remain in effect even if the plugin is uninsalled.

WordPress and site database queries – summary

• Make sure you have a backup before carrying out database optimisation.
• Use the MySQL query monitor to identify components generating a large numnber of queries and queries that take a long time to complete.
• Consider removing components that generate a large number of queries or queries that take a long time to complete.
• Use the WP Optimize plugin to remove data from the database that isn’t required.
• Use the Index WP MySQL For Speed plugin to add keys (or indexes) to database tables
• Uninstall WP Optimize and Index WP MySQL For Speed once you’ve optimised the database.

Page output compression.

There are a variety of caching plugins that can be used to compress page output.

This can also be added by adding this to the top of your site’s .htaccess file:

<IfModule mod_deflate.c>
  # Compress HTML, CSS, JavaScript, Text, XML and fonts
  AddOutputFilterByType DEFLATE application/javascript
  AddOutputFilterByType DEFLATE application/rss+xml
  AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
  AddOutputFilterByType DEFLATE application/x-font
  AddOutputFilterByType DEFLATE application/x-font-opentype
  AddOutputFilterByType DEFLATE application/x-font-otf
  AddOutputFilterByType DEFLATE application/x-font-truetype
  AddOutputFilterByType DEFLATE application/x-font-ttf
  AddOutputFilterByType DEFLATE application/x-javascript
  AddOutputFilterByType DEFLATE application/xhtml+xml
  AddOutputFilterByType DEFLATE application/xml
  AddOutputFilterByType DEFLATE font/opentype
  AddOutputFilterByType DEFLATE font/otf
  AddOutputFilterByType DEFLATE font/ttf
  AddOutputFilterByType DEFLATE image/svg+xml
  AddOutputFilterByType DEFLATE image/x-icon
  AddOutputFilterByType DEFLATE text/css
  AddOutputFilterByType DEFLATE text/html
  AddOutputFilterByType DEFLATE text/javascript
  AddOutputFilterByType DEFLATE text/plain
  AddOutputFilterByType DEFLATE text/xml
  # Remove browser bugs (only needed for really old browsers)
  BrowserMatch ^Mozilla/4 gzip-only-text/html
  BrowserMatch ^Mozilla/4.0[678] no-gzip
  BrowserMatch bMSIE !no-gzip !gzip-only-text/html
  Header append Vary User-Agent
</IfModule>

The post about enablling GZip compression goes in to more detail about this topic.

Page output compression – summary

• Enable compression on your site either via your caching plugin or by manually adding compression rules to your site’s .htaccess file.

WordPress and site caching.

WordPress and caching plugins is quite an extensive topic. I’ve written a whole post dedicated to caching in WordPress.

If you have the Litespeed web server in your hosting, the Litespeed Cache plugin is a good choice. There’s a post covering how to configure the Litespeed cache plugin here.

If you don’t have the Litespeed web server available, the W3 Total Cache plugin is a good alternative. There’s a post covering how to configure W3 Total Cache here.

WordPress and site caching – summary

• Use a good fast caching plugin in your WordPress.
• Ensure your caching plugin is configured appropriately to gain the full benefits of caching.

Hosting PHP version.

It’s a good idea to be using the most recent version of PHP that you can. This is because more recent versions can handle a greater number of requests per second.

If you’re using cPanel based hosting the “Multi PHP manager” can be used to specify the PHP version to be used by your site:

To use this, you’d tick the box on the same line as your site’s domain, select the desired PHP version from the drop down on the right hand side, then click “apply”:

Other PHP managers work in roughly the same way: Select the domain, choose the PHP version, apply the change.

Hosting PHP version – summary

• Set the most recent version of PHP that you’re able to in your hosting.

Hosting TLS version.

Using TLS 1.2 as a minimum is advsable, due to it’s reduce latency.

If you’re using shared hosting you might not be able to choose or adjust this.

If you’re using cloudflare you can specify TLS 1.2 under:

SSL/TLS > Edge Certificates > Minimum TLS Version:

If you’re using the QUIC.cloud CDN TLS 1.3 is available by default.

Hosting TLS version – summary

• If you have the ability to do so, ensure TLS 1.2 is in use in your CDN or hosting.
• You may not have the ability to select this if using shared hosting.

HTTP/3.

HTTP/3 can knock a significat percentage off your site’s TTFB (10%-12%).

If you’re using shared hosting you might not be able to use this, you’ll need to check with your hosting provider.

If you’re using the Litespeed cache plugin but aren’t using the QUIC.cloud CDN, HTTP/3 is possible, but your hosting provider may need to open UDP port 443 in the server’s firewall for this to be possible.

If you’re using the Litespeed cache plugin and are using the QUIC.cloud CDN, HTTP/3 is in place by default as long as your hosting provider may need to open UDP port 443 in the server’s firewall.

If you’re using cloudflare you can chekc if HTTP/3 is enabled under:

Speed > Optimisation:

If you find that HTTP/3 isn’t enabled in cloudflare, you can click the link icon on the same line as HTTP/3 to go to the page where you can enable HTTP/3.

You can use this http/3 test to see if http/3 is in use for your site.

HTTP/3 – summary

• If you’re able to use HTTP/3 in your hosting and CDN.
• You may not have the option to specify this if you’re using shared hosting without a CDN.

Network latency.

While the use of a CDN is likely to help, if you’re not using a CDN, there’s not much you can actually do about this, other than make sure that the server on which your site is hosted is geographically close to your target audience.

If TTFB and server response times are a concern to you, and you’re hosted on a server that isn’t geagraphically close to you audience, you might consider migrating your WordPress site to a provider that is close to your target audience.

Network latency – summary

• Try to use hosting geographically close to your target audience.
• Consider migrating your site if your hosting is geographically distant from your target audience.

DNS lookup overhead.

The overhead of a DNS lookup can add to TTFB and server response times for the first page call.

To address this, you’d have to use a CDN providers nameservers. You can do this for free with both Cloudflare and QUIC.cloud.

You’ll need to have an undertstanding of how DNS works to be able to configure this manually, and both cloudflare and QUIC.cloud can detect your current DNS settings to automate the configuration.

For QUIC.cloud:

Once logged in to your QUIC.cloud account you’d click on:

DNS zones > +Add New Domain to DNS Zones > Enter your domain name > Add domain

QUIC.cloud will then scan your domains’s DNS zone, and display the records it finds.

You’ll then need to click “Enable and add records”.

QUIC.cloud will then present you with nameserver addresses that you need to set against your domain with the party that holds your domain registration.

You can find QUIC.cloud’s guidance covering setting up and using their DNS here.

For Cloudflare:

Once logged in to your cloudflare account you’d initially need to add your site by clicking on “Add site” in the top navigation bar. You’ll then need to select a plan.

Cloudflare will then scan for DNS records automatically, and add them to the DNS zone for your domain that’s held with cloudflare.

Once the zone has been scanned and created the required nameservers are then displayed at the bottom of the page, and you’d need to set these against your domain with the party that holds your domain registration:

You can find Cloudflare’s documentation covering the above here.

DNS lookup overhead – summary

• Use a CND provider’s DNS and nameservers to reduce the DNS lookup overhead.

In Conclusion.

• There are many components that can have a negative effect on TTFB and server response times.
• Addressing only one component will have less effect compared to address as many as you can.
• You won’t always be able to take steps to address all the involved components.
• The type of hosting you choose to use can have an effect on TTFB and server response times. You may have to pay more to gain hosting with improved performance.
• Reducing the amount of code being operated in your WordPress can help with server response times.
• Reducing the number of database queries your site runs can help with server response times.
• Compressing page output can help with TTFB and server response times.
• Using a recent version of PHP can help with server response times.
• Using a good caching plugin in yoru WordPress can help with server response times.
• TLS 1.2 and above can help with TTFB and server response times.
• Using HTTP/3 can help with TTFB and server response times.
• Using hosting that’s geographically close to your target audience can help with TTFB and server response times.
• Using CDN provider’s DNS and nameservers can help with TTFB and server response times.
• The more of the above that you can carry out, the more improvement you’ll see with TTFB and server response times.