Can Fastly help improve time to first byte on a web page?
Looking at a waterfall for www.fastly.com on webpagetest.org (results here: http://www.webpagetest.org/result/140813_JQ_674214b2dede6102267759c26221b19a/) fastly’s TTFB (Time To First Byte) is quite low, leading to fast start render times. How can Fastly help decrease TTFB on web pages?
-
For web pages, TTFB (like what's measured on webpagetest.org) is how quickly the first byte of the page is received by the client. This is generally dictated by how quickly the base HTML of the page is served. So, the faster the HTML arrives at the client, the better.
The best way to do this is to cache the base HTML on Fastly. This will distribute the HTML and when accessing a page, clients will get the HTML from a Fastly cache close to them. That's why www.fastly.com has such good TTFB.
The problem is that most HTML is considered "dynamic." Content management systems often mark HTML pages as non-cacheable (through
cache-controlheaders) or web admins purposely make HTML non-cacheable in order to avoid serving stale content.Fastly's instant purging techniques can help this. HTML objects can be marked as cacheable and cached at the edge, just like normal static objects. When they change, a purge command can be issued to purge the object from Fastly's caches, forcing a re-fetch when the page is requested next. This is done instantly, so no stale content will be served.
There's a good write-up of this here including links to other Fastly resources that can help with making dynamic content caching easier.
Not all HTML objects are cacheable, so some will still need to go all the way to origin. But, lots of HTML can be cached when instant purging provides a quick and dynamic (pun intended!) way to invalidate it from the cache when things change.
Please sign in to leave a comment.
Comments
1 comment