If you’ve been following the rant in the SEO blogosphere, you are probably aware of the recent study that tested the impact of pagespeed metrics on SEO performance. The study was first published by Zoompf’s CEO Mark Isham on the Moz community blog. Its goal was to demystify Google’s (News - Alert) definition of “page speed” by pinpointing the specific factors that impact SEO performance.

To accomplish their goal, the researchers observed 100,000 webpages and 2,000 search queries, looking for a correlation between Google rankings and over 40 various performance-related metrics. They came back with a somewhat surprising conclusion. Their data showed that none of the front-end metrics had any direct effect on Google’s indexing decisions. In fact, the only performance factor that seemed to matter was the pages' Time to First Byte (TTFB):

“The back-end performance of a website directly impacts search engine ranking…Website owners should explore ways to improve their TTFB.”  

This isn’t the first time that TTFB benefits are being mentioned. Pre-dating this report, the value of TTFB was already mentioned by several industry experts, including Ilya Grigorik, a developer advocate on Google’s ‘Make the Web Fast’ team who wrote: 

"It's not only the time that matters, but also what's in those first few bytes… Of course it doesn't matter if you flush your '200 OK' after 1ms vs. 1s… But if you know what you're doing and craft the response right, then it can make a huge difference.”

So what does this all mean for CDN users? Mark Isham’s study concludes with this suggestion:

“Website owners should explore ways to improve their TTFB. This includes using CDNs.”

Unfortunately, this isn’t the correct answer, or at least not an entire one. Fact is, nine out of 10 CDNs will actually contribute to the delay – not promote a solution. To understand why this is true and how (if at all) CDNs can be used to improve your TTFB, I want to introduce you to Time to First Byte biggest delay factor: the often overlooked processing time of dynamic HTML.      

How Dynamic HTML Affects TTFBSimply put, TTBF measures the time it takes for the first response to arrive from the server. And so, in order to understand what impacts this response, one should ask: What resources will my server send first?

Obviously the response header is the first in that line, but – as Ilya points out - receiving it will mean nothing in terms of browser parsing, and it is really nothing more than a “show-off” statistic.

Looking beyond that, the first meaningful response is always the webpage’s HTML component and its total rendering time, which is composed of:

1. Processing (Waiting) time – The time it takes to generate the dynamic HTML on the webserver.
2. Network (Receiving) time – The time it takes for the compiled HTML to reach the browser.

(Click to enlarge)

The network time for HTML is inconsequential, as these are usually very lightweight resources. However, the processing time for dynamically generated HTML can be extremely high - to the point that it can significantly impact TTFB as well as overall performance. The stats below are taken from an internal study that we performed at Incapsula in which we sampled one billion requests to our CDN and looking at the results you can clearly see that:

The average load time for HTML resources is 10 times higher than it is for (typically much larger) images and almost 4 times higher than it is for JavaScript files. 

(Click to enlarge)

Considering this further, this outcome is actually very logical. With today’s widely accessible high-speed networking infrastructures, it isn`t the transfer time slowing down our browsers but rather the compute time spent in generating it. Or, in other words, the time it takes for the webserver to compile the HTML content, before it's even ready to be sent.

From a user’s point-of-view this is the “empty white screen” delay - the single event that impacts user experience more than any other performance related factor.

It’s no wonder that Google used this for its UX-focused algorithms. TTFB is just another term for “How fast can you have your HTML ready for rendering?”In the era of speed-of-light network communication, there is no better place to look for bottlenecks in your content delivery.

So How Can CDNs Improve SEO?

Dynamically generated content and CDNs were never the best of friends. After all, with processing time being 99% of the overall “problem,” CDN-based proxy delivery can’t really provide an effective solution.

In fact, bare-bone CDNs, which rely heavily on caching header directives, are likely to cause more harm than good, as they actually increase the overall load time by providing an additional connection point between the origin server and browser.

Various compression methods, which are now being introduced by modern CDNs, are also ineffective. While these can further reduce networking time by delivering a tightly packaged version of your content, they too will have no impact on the time it takes to generate the HTML.

By far, the best way a CDN can be used to improve delivery of dynamic HTML is by intelligently caching it, thus removing the need for processing on the origin webserver.

(Click to enlarge)

Think about it - if you are using any kind of database driven CMS, your homepage is dynamically re-generated time and time again for each user. Same goes for all of your blog posts, your contact pages, your “About us” and etc… Yet how many of these are actually updated and how often? Wouldn’t it be much easier - and much more TTFB-friendly - to classify the HTML components of these pages as static and have them delivered directly from the CDN, with no processing and from the nearest possible location?

The takeaway: CDNs won’t improve your SEO rankings unless they can effectively cache your initial page HTML to improve the Time to First Byte.