WebPageTest is a common tool that is used to examine site performance. It can generate a beautifully detailed waterfall with 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 prioritized according to importance for user experience. Assets that are more important for page-loading 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 a long TTFB. This is normal browser behavior when using HTTP2.
There are two main tips for reducing TTFB in this case:
- Rearrange assets that are not crucial to page-loading that appear on the top of the page, so JS and CSS links should be moved towards 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.