Mobile app version of vmapp.org
Login or Join
Smith883

: Why SPDY-enabled pages are not loading faster? I've just enabled the SPDY module on nginx, as explanained on the SPDY module site. I expected a speed enhacement on my site, but I haven't noticed

@Smith883

Posted in: #Nginx #PageSpeed #Performance

I've just enabled the SPDY module on nginx, as explanained on the SPDY module site. I expected a speed enhacement on my site, but I haven't noticed it.

Using Firefox 25 and Firebug, I tried to take a look at the site loading to try to find out what's going on. This is what I got:

Without SPDY:



With SPDY:



The total page load is the same, but without SPDY all the resources seem to be requested and served sequentially, and with SPDY all at the same time.

But with SPDY there's that emptiness just there, where the navigator seems to be doing nothing. I got similar results on another SPDY-enabled websites.

The Wikipedia says that


The goal of SPDY is to reduce web page load time. This is achieved by prioritizing and multiplexing the transfer of web page subresources so that only one connection per client is required


What happens? Is that normal? If the transfer is multiplexed shouldn't the resources be fetched faster?

Please notice that on subsequent requests the pageload was way better for SPDY, but there's still that emptiness doing apparently nothing.

I've deleted the cache between every request, jsut in case.

10.01% popularity Vote Up Vote Down


Login to follow query

More posts by @Smith883

1 Comments

Sorted by latest first Latest Oldest Best

 

@Samaraweera270

Yes, this is normal and working as it should.

In the first screenshot, the grey bar segment corresponds to the receiving time, and the olive segment corresponds to the connecting time (as can be confirmed here and here).

In the second screenshot, both of these segments are missing (i.e., the receiving and connecting time are null). This is because SPDY fetched all the resources and opened up multiple connections to the client browser in just one step. Hence the longer purple segment, which is the waiting stage, for the first resource as the sever module does its work.

The onload time, which you're likely referring to as the "total page load", does not include the receiving time, as you can see by adding up the times next to each bar in the first screenshot (totaling to much more than 2.5 seconds). The onload time totals the colored segments (in this case: olive, purple, and green, which equals connecting, waiting, and events respectively). This amounts to roughly the same time with and without SPDY initially because the content of the page is the same.

However as you stated, subsequent requests for the page will be much faster because the resources will have been cached in memory (thus reducing the waiting stage), so the onload time will be less and the page will appear noticeably faster.

Update:

Due to the differences in monitor colors, the "grey" bar may correspond to blocking; the user would be able to match the colors by hovering over each bar with a colored legend. blocking also makes sense because without SPDY, the connections with the client browser would be serial and not in parallel as with it - hence those would absent with SPDY.

The "emptiness doing apparently nothing" is due to the browser loading resources like JavaScript (e.g., js_WrioUyd64_) which takes time for it to process. This would not be improved by SPDY because that is client-side, not server-side.

10% popularity Vote Up Vote Down


Back to top | Use Dark Theme