WebPageTest is a common tool that is used by many to examine site performance. It can generate a beautifully detailed waterfall with great information on each request.
If you are using this tool to determine the speed of loading for your assets (and specifically your images) you might be seeing an image similar to the one below, which shows a relatively long time to first byte (TTFB):
This can be seen in most cases when using https and specifically http2, which Cloudinary uses by default to deliver assets.
When HTTP/1.1 is used, the browser will open multiple connections where each one requests a single asset. HTTP2 opens a single connection to a domain, and that connection transfers all the requests for assets
In addition, when using HTTP2 different assets are being prioritized according to importance, in terms of user experience. So assets that are more important for page loadings like JS and CSS will be prioritized higher than those that are less important, like images.
When these priorities are honored, the browser gets the least important images last, although the connection has already been established which shows as long TTFB.
This is the normal browser behavior and is something that is expected when using HTTP2, which as mentioned earlier, is used as default by Cloudinary when delivering assets.
There are two main things that can be done to reduce TTFB in this case:
- Re-arrange assets that are not crucial to page loading that appear on the top of the page, so JS and CSS would appear at the bottom of the page.
- Use the preconnect link relation. What the preconnect link relation does (particularly when applying it to the HTTP header responses) is that it enables the browser to do the HTTP/TLS handshake as soon as possible. This means that the browser gets to do the HTTP/TLS handshake before other components start their activity. This moves the handshake time (which is a time which blocks other activity from being performed) to the margins when the browser isn't yet doing anything and readies the connections for handling request/responses as fast as possible.
Comments
4 comments
Hi
This doesn't seem right. Using preconnect allows the browser to peform dns lookup, connect and ssl. It doesn't explain the poor time to first byte. We've done exactly what was suggested and I can see that it has resolved the three items, but I'm still getting very poor time to first byte, anywhere between 150 and 400ms. This is a real shame as Cloudinary is a great solution, but if I can't resolve this it's back to hosting images on the AWS server with below 50ms ttfb.
Hi Paul,
There are different ways to measure TTFB and different causes of that measurement showing delays; the preconnect option is intended to account for potential delays caused by the DNS and/or SSL lookup and negotiation.
With the 'webspeedtest' example above, the primary sources of delays shown in their TTFB metric are usually due to the shared HTTP/2 connection being used (so images requested later may be queued behind those requested earlier), or a delay in the browser dispatching the request for the image due to its position on the page, the relative priority when the browser is requesting page elements, or due to Javascript processing delaying the dispatch while other tasks complete
Regarding your site specifically, I see you have an existing support ticket and I'll follow up there shortly
Regards,
Stephen
Hi Paul,
I am curious if your problem was resolved to your satisfaction and how it was resolved or if you ended up going back to AWS?
Thanks
Hi Frederic,
If there is anything Cloudinary can help you on this, I will be happy to assist you on this.
I suggest you to open a ticket to here, and please provide as detail information as possible so we can look into it.
Regards,
Erwin Lukas
Please sign in to leave a comment.