Issue link: https://read.uberflip.com/i/1146286
Best Case: Scripts at the Bottom | 49 In both Internet Explorer and Firefox, the browser starts by downloading the first image from host1 and host2. Next, the script from host1 is downloaded. Here's where the unexpected behavior occurs. While the script is being downloaded (exag- gerated to 10 seconds to illustrate the point), the second image from host1 and host2 are blocked from downloading. Not until the script is finished loading are the remaining components in the page downloaded. Worst Case: Scripts at the Top At this point, the effects that scripts can have on web pages are clear: • Content below the script is blocked from rendering. • Components below the script are blocked from being downloaded. If scripts are put at the top of the page, as they usually are, everything in the page is below the script, and the entire page is blocked from rendering and downloading until the script is loaded. Try out the following example. Scripts at the Top http://stevesouders.com/hpws/js-top.php Because this entire page is blocked from rendering, it results in the blank white screen phenomenon described in Chapter 5. Progressive rendering is critical for a good user experience, but slow scripts delay the feedback users crave. Also, the reduction of parallelized downloads delays how quickly images are displayed in the page. Figure 6-5 shows how the components in the page are downloaded later than desired. Best Case: Scripts at the Bottom The best place to put scripts is at the bottom of the page. The page contents aren't blocked from rendering, and the viewable components in the page are downloaded as early as possible. Figure 6-6 shows how the long request for the script has less of an effect on the page when it is placed at the bottom. You can see this by visiting the following example. Figure 6-5. Script at the top blocks the entire page html script component component component component