YouTube

Figure 17-25. http://www.youtube.com
YouTube's home page (http://www.youtube.com) isn't very heavy, but it has a low YSlow grade and ends up in the bottom half of response times. Figure 17-26 shows that there isn't very much parallelization at the beginning and end. Increasing the level of parallelization in these areas would make the greatest improvement to response times.

Figure 17-26. YouTube HTTP requests
In the beginning of the page load, the main hurdle to parallelization is the six scripts downloaded back-to-back. As explained in Chapter 8, scripts block all other downloads, no matter what their hostnames are. Additionally, the scripts aren't minified. Combining these six scripts into a single script and minifying them would decrease the download time. Also, if any of these scripts could be downloaded later in the page, the initial part of the page would be downloaded and rendered sooner.
At the end of the page, decreased parallelization results from downloading 15 images from a single hostname (img.youtube.com). YouTube only uses four unique hostnames in their page. It would be worth the cost of an extra DNS lookup to split these 15 downloads across two hostnames and double the amount of simultaneous downloads.
Sadly, not a single component has a far future Expires header ...