Time to first byte - Fine tuning?

Andrewkar

Andrewkar

...
BuSo Pro
Joined
Nov 6, 2014
Messages
402
Likes
217
Degree
1
Hey guys,

I'm working on a WP website, I managed to speed up load time from 5s to 2.5s and it looks like I'm running out of ideas. Website is hosted at Siteground, they have their own cashing solution, but WP Fastest cache plugin gives a bit better results so I stick with it. Images are optimized, java and css combined, most of unnecessary plugins are out. Still waiting for decision on Sheroholic plugin, it's a true resource hog, but owner might want to keep it. Time to first byte is 0.323s and I know it could be better (according to Google 0.200 would be OK, and this article from MOZ is interesting as well ) but is there anything that I could do to improve this score? I know it's mostly related to hosting, but maybe there are some other options I don't know about? I would love to make it at least 0.200s is this possible without moving to another host? Ohh and BTW, owner of the site bought one year hosting package so he won't be liking my idea about moving site somewhere else. Any ropes appreciated.

EDIT: Would using CDN improve TTFB if I have cache plugin already installed?
 
Thanks built, I'm going to test it.
 
A CDN will definitely help. I always use cloudflare or incapsular (https://www.incapsula.com ) The added bonus is additional security, Plus instant value add to your clients.
Minify plugin will help too. Combining and compressing your css and js files.

Image compressing too. Multiple plugins available for this.
 
I thought the TTFB entirely hinged on the server? Using a CDN is just offloading this to another server. If this is true then caching won't help unless it's on a CDN. I went from shared hosting to a VPS on a much better server by a company that seemed to care about performance and it made a big difference. Maybe Siteground has an upgrade option so you're not wasting your 12 month agreement? I'd ask them if this would help or if there's anything they can do for you for this.
 
Are you sure that speed is as much of an issue as you think it is?

Or are you just on a chase deeper and deeper into the rabbit hole?
 
Speed is worth investing time in imo.

Not only does it help give you some edge on SE algos it also reduces bounce rate. Most people will back out of a loading page after a second or two.

With some rss heavy sites in the past I've used a script that loads only Above The page fold and loads as you scroll.

Not ideal in many cases and some were buggy, maybe worth a look if you're at a sticking point.
 
I'm not disputing that speed is good.
Running after the 0.123seconds to first byte might not be time well spent, though.
(from the OP .200 is goal, 0.323 is now)

Looking at the article he linked, I see this:
51f83ddf236916.23144183.png


So he is already faster (or as fast) as the median time to first byte as the evaluated 2000 rank 1 websites which seem to be at approximately 0.38s

And while I agree with the speed=good mantra, here is what the article says:

Our data shows there is no correlation between "page load time" (either document complete or fully rendered) and ranking on Google's search results page. This is true not only for generic searches (one or two keywords) but also for "long tail" searches (4 or 5 keywords) as well. We did not see websites with faster page load times ranking higher than websites with slower page load times in any consistent fashion. If Page Load Time is a factor in search engine rankings, it is being lost in the noise of other factors.
Click to expand...
(second emphasis mine)

So where does this leave us?

As I said I agree that speed is good, yet the data seems to disagree.
My take away is: Make a site fast, even very fast, but know when you are just wasting time. At the extreme ends of performance, that can be a LOT of time).
Time that would better be spent creating content, marketing, improving your site, traffic leaking, link building, ....
 
Last edited:
I would say that a slow loading site, even though not necessarily affecting ranking directly, will impact other metrics such as bounce rate or click-backs which Google will see as more important.

And if it makes you feel any better, my TTFB is 2.8 seconds (no CDN)
 
doublethinker said:
2.5 seconds is good for a fully fleshed out website and this is without CDN. Have you considered leveling out your clients expectations (or your own)?
Click to expand...
These are my expectations, they have no idea about this things, but I want this website to be faster than at least 90% of other sites (according to pingdom, thinkwithgoogle etc.). I'm going to connect CDN today and will see how it goes.
Tao said:
I would say that a slow loading site, even though not necessarily affecting ranking directly, will impact other metrics such as bounce rate or click-backs which Google will see as more important.

And if it makes you feel any better, my TTFB is 2.8 seconds (no CDN)
Click to expand...

It doesn't :smile: I just want it to be as fast as I can make it.
 
I've had a large scale site (think multi-million page with TONS of traffic) in production with major parts of the site at under 80ms load time in production for well over a year. To say I'm a fiend for speed would be an understatement.

Considering that, these have been my observations:
  • Most ranking factors are coefficients that are highly variable, even down to the keyword / niche level
    • What this means is what matters for a given keyword / niche may be entirely different from the next keyword / niche
    • What this also means is that, often, focusing on achieving specific numbers or specific arbitrary "values" for a given factor is an extremely nearsighted focus that can be detrimental
  • Sometimes other ranking factors make speed irrelevant
  • Sometimes good is good enough
    • Like I said, I've had massive numbers of pages, some extremely high traffic, at under 80ms in production
    • What I've found is that, at least in certain niches, once you reach a certain point, there's nothing to be gained from going faster, particularly if other ranking factors are lacking.
    • What I've also found is, in certain niches, the overall speed is not as important as stability of speed.
    • What I mean by this is, significant fluctuations in speed appears as if it can cause at least Googlebot (possibly also Bingbot) to throttle down crawl rate. I would suspect it's a risk mitigation scheme, and spikes in load time may be seen as a possible indicator that their crawl rate is adversely affecting site performance. Most sites probably won't experience this, but it seems large scale, high traffic sites might.

A few years ago, at least in certain niches, speed appeared to be much more important. This makes sense, especially considering it is an easier measured and factored variable in associating with UX, and therefore manipulating rankings with. Since then, in multiple industries I've seen it become considerably less important, especially if your site is "in the ballpark" relative to the competition. My recommendation would be, if you are in the ballpark of your competition, move past it on to higher ROI efforts like content, outreach, lead gen, etc.
 
I disagree with Moz. There is a correlation between page speed (render time it seems, not document complete) and ranking. It's small, so small that you don't really see it play out on short tail terms, but you can tweak a site's speed and watch longer tail traffic that nobody is optimized for increase within a week to a month and sometimes in a day. It's variable like all things.

But again, as @shiftymcnab and @Tao are saying, it's a correlation because other intertwined factors like pogo-sticking and CTR are at play, but it's a causative factor in moving those metrics in their positive directions. In isolation, if even possible, page speed is a small ranking factor. But it's not isolated as these fine gentlemen have pointed out.

At the end of the day I think @turbin3 is right on how to approach it. You drive up to where you're competing, but starting to see diminished returns from increasingly complex and expensive optimization. And then you stop simply because there are other activities that can still award you with full returns instead of fractional returns. The territory of diminished returns is for when all other things are equal and you need to that last drop of juice to barely edge out a competitor. But that's never the case.
 
I can tell you all about diminished returns too, that's for sure! In some cases, it can be a dangerous thing getting caught up in the game of squeezing the last drop of speed out of your site. On enterprise-level e-commerce sites, sure it could be worth millions. The average Joe-blow site? Probably not.

To what degree have I ventured down this rabbit hole? Imagine running deep analysis on traffic logs and assessing the speed improvements and bandwidth usage reduction in stripping BYTES out of HTTP headers... After all, bytes can add up when you're talking about a few hundred billion visits per annum. In the end, it wasn't actually worth it relative to the time involved, but was certainly a fun exercise.

As far as speed improvements, cover the basics of compression (gzip, image compression, etc.), caching, resource usage (eliminate or optimize inefficient JS, CSS and other resources), and much beyond that I would probably move on to other areas.

I would look at speed a bit more from the standpoint of UX and what might be perceived as only remotely bearable vs. a downright pleasant user experience. Things like eliminating FOUT, improving render time, progressively updating individual page components independently of the page (a lot of cool possibilities with that using modern JS frameworks like React, Angular, Ember, Vue, etc.), even as simple as adding a damn loading spinner to give the user feedback. With things like HTTP/2 and the improved ability to load a larger number of resource files simultaneously, a lot of the traditional recommendations you'll still see out there (including some I've written) are not necessarily the best use of time for everyone in all cases anymore.
 
I have personally gone down this rabbit hole deeeeeeeeeeeeeeeeeeeeeeeeeeeeeep.
(Huge client site)

While it is extremely fascinating, we've seen NO impact after a certain point.
Not on CTR, not on bounce rate, not on ranking.

Yes, a slow page sucks, but after the "good", there is not a lot to be gained.
 
Cheers guys for your valuable comments! Of course I got the point that it's just not worth it to invest time into something that have no impact on $ however, in this case speed issue is important. Competition is faster and better optimised. Unfortunately owner of the site didn't want to turn on CDN. But I made little experiment and main problem is their WP theme (bloated as hell), and then bunch of social media plugins, plus shared hosting plan that is not designed to serve this kind of website I believe. Anyways, thank you guys.
 
You must log in or register to reply here.
Back