Variable Wordpress time to first byte - a hosting problem??

Web Performance Discuss Test Results
1

My time to first byte varies a lot, sometimes “A”, mostly “F”. My SEO guy says the "F"s are really bad with Google.

I’ve attached results of a half dozen tests I did today.

Obviously I can optimise all sorts of stuff, but the really basic thing is, do I need to change my hosts.

Based on this information, in particular the TTFB, do I have a hosting problem? Are there any killer questions I should be asking my hosts? (who are in general good.)

Or do I need to do some optimisation before I can be sure of that?

Many thanks

Andy
Bristol UK

2

Usually a hosting or application problem. More dev work on the theme and plugins can hide slow hosting issues and fast hosting can hide complex server code issues. You can try disabling plugins to see if there is one that is egregiously bad but the easiest fix is usually to run on good hosting (preferably with fast database servers - SSDs are usually a good sign).

If you are on shared hosting that is probably it. If you are on a VPS or a dedicated server then it might be worth spending some more time investigating.

3

Hi Andy 3142,

TTFB is affected by:
1.) The time it takes for the request to propagate through the network to the web server;
2.) The time it takes for the web server to process a request and generate a response;
3.) The time it takes for the response to propagate back through the network to the user’s browser.

Ergo, since you’re not using a CDN (content delivery network), your site’s Time to First Byte will be highly dependent on the location elected for testing (and your hosting, obviously).

I ran the following tests…

London: http://www.webpagetest.org/result/150128_8V_N36/
Manchester: http://www.webpagetest.org/result/150128_3W_N3M/

…and, as you can see, there are a couple of anomalous results. To my eye, these anomalies scream “shared hosting”. That said, important metrics such as TTFB, Start Render and First Paint are all pretty consistent.

A couple of notes:
1.) Your business appears to be local. Therefore, I wouldn’t worry too much about test results outside of its sphere of influence;
2.) However, from an optimization perspective, the site is something of a hot mess and there is definite room for user experience improvement (at least) within the site’s afore mentioned sphere of influence.

Chief amongst these optimization issues:
1.) Image compression
2.) Browser caching
3.) Reduction of HTTP requests via minification/concatenation of .js and CSS files

Further, a well-tuned VPS or dedicated server is always the best case scenario for any website, but may or may not be overkill for you relative to numerous variables (e.g. how much business does the website generate for you, how exactly is the website purposed, etc), the values of which you will have calculate.

As Patrick alludes to, some Dev work can “hide” (I would call it “fix” as the net result is the same, tomato-tomahto) shared hosting issues and may indeed be something to look into.

Best,
AJ
Managing Partner
WpFASTER

4

Dear AJ,

Thanks for that helpful post and for taking the time to run the two tests. We’ve had a “positive confusion factor” at work here. The engineer at my hosts, 34SP, kindly and unexpectedly tweaked by WP W3 Total Cache plugin, and greatly improved results. He said:

"> The W3 Total Cache plugin is very good, but does need some careful configuration. I have made some changes to it,

that vastly improve site load speeds including the painful TTFB, which was being caused by cached database queries to disk.

I would advise against caching database queries to disk on any shared hosting servers.

It might work on a dedicated server, but , to be honest, MySQL caches in RAM and disk just slows things down for these.

Cheers "

I think he did this after I posted, but before you tested. So we were testing different situations.

Anyhow I ** THINK ** that’s what happened - I never saw TTFBs anywhere near as low as yours. And in that case, Yes, the remaining anomalies are due to a shared server and as such are OK in the circumstances.

I am checking into your “hot mess” suggestions urgently, and thank you for these. I knew there were things I had to look into but no clear idea which.

Cheers

Andy

Andy

5

[quote=“Andy3142, post:4, topic:9217”]
Dear AJ,

Thanks for that helpful post and for taking the time to run the two tests. We’ve had a “positive confusion factor” at work here. The engineer at my hosts, 34SP, kindly and unexpectedly tweaked by WP W3 Total Cache plugin, and greatly improved results. He said:

"> The W3 Total Cache plugin is very good, but does need some careful configuration. I have made some changes to it,

that vastly improve site load speeds including the painful TTFB, which was being caused by cached database queries to disk.

I would advise against caching database queries to disk on any shared hosting servers.

It might work on a dedicated server, but , to be honest, MySQL caches in RAM and disk just slows things down for these.

Cheers "[/quote]

Right he is (generally speaking).

You might still try object caching, however, and see what sort of mileage you get out of that.

I must say, that’s pretty impressive you have a host that will dive into W3TC like that for you… I don’t actually think I’ve ever heard of a host doing such a thing. I’ll spread the good news of 34SP :slight_smile:

That seems likely.

I see you’ve been working! WebPageTest Test - Running web page performance and optimization tests...

…You appear to have found that “Browser Cache” tab in Total Cache.

Not incidentally, you can also handle the afore mentioned minification and combination of CSS and .JS with W3TC, but that is where things get pretty tough and time consuming.

I would recommend testing those features within W3TC; then disabling them and trying Autoptimize for minification/combination purposes to see what gives you the best results (Autoptimize generally being the superior solution). Then, if you’re feeling particularly froggy, you might try the “Inline and Defer” CSS option within Autoptimize (a tutorial for which can be found here on WpFASTER).

Lastly, you can remedy those lingering image issues with EWWW Image Optimizer. Bing bang boom.

[quote]Cheers

Andy[/quote]

All the best, mate. Let me know if you need some help with any of the above.
AJ
Managing Partner
WpFASTER

6

First you need to answer this.

Are you using shared hosting? If yes, then keep in mind that you are sharing server resources with other websites and sometimes the response of server will be fast and otherwise slow.

So moving to a dedicated server, VPS or cloud server will stabilize the first byte times.

One other way to improve the first byte time is to use a CDN like Cloudflare (free), it will greatly help in improving your first byte times. I have personally tested it on my fun site.

And yes Fs are very bad for your SEO because it shows that your website is very slow and search engines hate slow websites because user experience on them is really bad.

Third option is to use proper caching on your website and compress images and minify the CSS/JS files on your website. Keep the sizes and number of requests per page as low as possible.

As for caching you can use a plugin like W3TC if you are using WordPress, there are also hosts that use advance caching mechanism to improve site speed like Varnish, HHVM, Memcache, Redis etc.

7

After optimizing 100s of sites, the biggest wins speeding up WordPress - time to first byte - revolves around optimizing the database subsystem + file system.

Here’s what I do, which usually requires a dedicated server, as most hosting companies are clueless about any of this.

  1. Ensure you’re filesystem is running ext4.

  2. Ensure the mount options nodiratime, noatime are both set. A reboot is required for these to take effect.

  3. Move /tmp off disk into memory. This is a huge win because…

a) Anytime an SQL select returns more data than can fit into memory, a temporary data table + other cruft can be created on /tmp, so really your database performance will be limited by /tmp i/o speed. If /tmp is in memory, your system will run at the speed of memory, rather than the speed of you disk.

b) Also WordPress stores session credentials on /tmp, so every logged in user moving from one page to another page, requires a credential check to ensure they can access the new page. So your page to page transition performance is limited by your /tmp i/o speed.

  1. Remove MySQL. Install MariaDB. In most WordPress cases, this can give a 30%-50%+ speed increase. MariaDB is a drop in replacement. Google for more info about MariaDB.

  2. Be sure to test your WordPress caching performance. You do this by ssh into your machine + ab (ApacheBench) against the URL you’re testing. My preference is Quick Cache, as it has only an enable/disable switch. No complex options. And it runs rings around all other caching plugins I’ve tested. With newer versions of Quick Cache + QC Pro, be sure to set = define(‘LOCALHOST’, TRUE); - in wp-config.php to enable caching for local requests.

BTW, if you test W3TC, even after futzing with options for hours, doubtful you’ll ever get close to the performance of QC.

Test with ab + find out for yourself.

  1. Next ensure that Opcache is working correctly + there’s plenty of memory available for file caching + hash/lookup key caching. On newer versions of PHP the APC code has been replaced by Opcache.

  2. Finally install XDebug + enable XDebug.scream (set to 1) + turn on full debugging in wp-config.php + track any broken code. I’ve seen some sites that generate 30M of errors for every page access. Best to fix all code, so to stop error spew.

  3. If additional tuning is required, setup XHprof + run through a single site page view + fix bottlenecks.

  4. Begin a cycle of adaptive tuning. This means tracking the output of your all your wp-debug.log files + Apache logs + syslog (database) + fix any problems that occur.

  5. Finally run mysqltuner every couple of days + retune your database subsystem based on it’s suggestions.

After the tuning above + if you’re using a solid theme, like the default themes shipped with WordPress, what you’re looking for in local speed is something on the order of…

5000+ reqs/sec throughput. This means that data comes off the disk fast + from database fast

8

Everyone, thank you very much for this!! Yes, I think 34SP have good support but maybe not completely trouble-free hosting. Right now I am starting again on a brand-new URL and right off there is a problem. This seems to be because the hosts servers don’t like the IPv6 line in the DNS record …oh dear … so anyway I’m going to track the speed step by step as I go through putting the site together and hopefully catch problems the moment they arise. I am seriously thinking of a dedicated server, though as my needs are small and simple, I hope to avoid this if I can.

Cheers

Andy

9

@Andy, I’m writing up an even more detailed step-by-step for my clients, that opt for their own admin person, rather than hiring me.