When testing my site speed on pingdom I see an alert:
This page makes 59 parallelizable requests to daks2k3a4ib2z.cloudfront.net. Increase download parallelization by distributing these requests across multiple hostnames:
What does this mean? Also, is there a way resolve this? Any insight is super appreciated!
For HTTP/1 and HTTP/1.1 connections, for a single hostname, a browser is only able to download one file at a time. For some sites, (with lots of large images for example) it’s possible to get marginal page speed improvements by splitting the images accross multiple hostnames so the browser would be able to download some portion of the assets in parallel.
However HTTP/2 supports multiplexing so the browser can download multiple files in parallel. With HTTP/2, having images spread accross multiple hostnames can actually be slower, since there is additional overhead from having to connect to multiple servers.
We serve all site assets with HTTP/2 - so you should be seeing images being loaded in parallel already.
The tool you’re using there appears to be out of date since it doesn’t take HTTP 2 into account.
Hope that helps answer your question, let me know if you have any more questions about it!
Hey Nathan,
I was actually curious if Webflow was hosting with HTTP/2. It makes huge improvements in page load performance.
I did a test on a couple webflow sites, including webflow.com, and it appears that http/2 is not working. See here: https://tools.keycdn.com/http2-test
Can you confirm?
Hey eric594
Currently the HTML itself is not served via HTTP/2, but all published assets (js, css, images) are.
The biggest improvements in page load performance are where a large number of assets need to be downloaded - with HTTP/2 they now can be downloaded in parallel where previously they would have been downloaded sequentially.
The initial page load of the HTML must occur before any additional assets will be downloaded (since it is what defines the additional assets) - so the additional benefit of HTTP/2 for the HTML itself is tiny in comparison to the assets.
However having said that, we still would like to serve all pages via HTTP/2, and once it’s possible for us to we will do so. At this point we are waiting for support from Fastly for HTTP/2.
Using the tool you linked, here is an example URL you can test for HTTP/2 support: https://daks2k3a4ib2z.cloudfront.net/58000b7f7105d4e052bb5194/css/nathan-s-supercool-site-62181f.webflow.d566752b6.css
Nathan,
You can see none of the assets are delivered in parralel here for Webflow: https://tools.pingdom.com/#!/eKfN47/https://webflow.com/ (See the ascending waterfall)
So it doesn’t matter if the CDN is delivering individual assets in HTTP/2. Nobody is seeing any performance benefit from this until the whole page is delivered with HTTP/2 so the assets can be downloaded in parallel. Look at the top suggestion where it says “Parallelize downloads across hostnames”. There 86 parallelizable requests on https://webflow.com!
Amazon Cloudfront now supports HTTP/2. Fastly also has HTTP/2 if you guys sign-up for the Limited Availability program. But frankly, there is such a huge performance boost from HTTP/2 that you would better off ditching Fastly and delivering the whole page in HTTP/2 with just Amazon Cloudfront.
HTTP/2 it’s practically at our fingertips! Please get it fully supported!
^^ So this answers the original posters questions. Webflow needs to properly implement HTTP/2.
And the pingdom tool (https://tools.pingdom.com) is perfectly capable of taking HTTP/2 into account. You can see the assets being downloaded in parallel in the waterfall for a legitimate HTTP/2 website, like https://www.blogger.com for example.
So it doesn’t matter if the CDN is delivering individual assets in HTTP/2. Nobody is seeing any performance benefit from this until the whole page is delivered with HTTP/2 so the assets can be downloaded in parallel.
I don’t follow - why do you say that? I may be misunderstanding you, but the benefits of HTTP/2 will be realized regardless of which protocol serves the initial HTML page load. Assets loaded from the CDN still will be loaded in parallel.
I built a quick site to demonstrate this:
http://http2-test-site.webflow.io
If you reload the page a few times doing a hard refresh to avoid the cache (ctrl+f5 on pc/linux or cmd+shift+r on mac) you can see the assets being loaded over http/2 will load significantly faster.
Additionally, I created seperate http/2 and http/1.1 only pages. Here is how they are each loaded in chrome:
The page with http/2 assets loads in 110ms while the page with http/1.1 assets loads in 350ms. Both of these pages themselves are http/1.1 however - demonstrating how the protocol of the initial page load is much less important than the protocol which the assets are served with.
Nathan,
That’s interesting. When you look at the pingdom waterfall for webflow.com this assets start to apppear in a slope rather than a straight line, suggesting that they are downloading one after another, rather than downloading in parrellel.
I can see from you example that the http/2 assets are loading much faster, however, when you run the http/2 only site through pingdom you don’t see the solid block of assets coming in. Rather, they are staggered suggesting they are coming in one after another.
So I’m really not sure what is happening here. Maybe the Chrome browser handles things differently than the pingdom tool.
I don’t know what the pingdom tool is doing either since they unfortunately don’t give much detailed information.
I think this is a better tool if you really want to dig into performance: https://www.webpagetest.org/result/161018_CY_1EBT/1/details/#waterfall_view_step1
The waterfall is much more descriptive:
and when you click on a single line it will give you the complete information about the request (for example, which protocol it was loaded with):
Yes, that looks more like HTTP/2!
Great to see!
