Optimize JS and css to download Web images faster

Article Introduction: my focus on JS and CSS is also how to download pictures faster. The picture is visually visible to the user. They don't focus on JS or CSS. Indeed, JS and CSS will affect the display of the content of the picture, especially the display of the image will affect the way (such as Picture Carousel, CSS background map and media inquiries). But I think JS and CSS are just the way to show pictures. In the process of loading a page

Most of my performance tuning efforts are focused on JavaScript and CSS, from the early move Scripts to the bottom and put stylesheets in the top rule. To emphasize the importance of these rules, I even said, "JS and CSS are the most important parts of the page."

A few months later, I realized it was wrong. The picture is the most important part of the page.

My focus on JS and CSS is also how to download pictures faster. The picture is visually visible to the user. They don't focus on JS or CSS. Indeed, JS and CSS will affect the display of the content of the picture, especially the display of the image will affect the way (such as Picture Carousel, CSS background map and media inquiries). But I think JS and CSS are just the way to show pictures. In the process of loading the page, you should first show the pictures and text first, rather than trying to ensure that JS and css faster download complete.

My goal of optimizing JS and CSS is to make the page render as soon as possible.

the time to start rendering is too late

With the idea of focusing on rendering time, I queried the HTTP archive to see when our pages started rendering. Here are some of the measured values:

• TTFB, the time the first HTML document packet arrived
• Time to start rendering
• When the page onload triggers

From the measured values of the world's fastest 300,000 addresses, I extracted 50% and 90% parts of them. As shown below, there are no rendering actions for the first one-third periods of time that the page is loaded.

Table 1. Each point in time during page loading
	TTFB	started rendering	onload
50th percentile	610 MS	2227 ms	6229 ms
90th percentile	1780 MS	5112 ms	15969 ms

Pre-loading

The fact that the page waits for rendering is one-third of the total page load time is unexpected. The data on the HTTP archive shows that the page takes 32% to 36% of the time to wait for the render to begin. But it takes only 10% of the time to get the first byte. As a result, browsers have received data for 22% to 26% of the time, but have not done any rendering. During this time, browsers are usually downloading parsing scripts and styles-both of which hinder the rendering of the page.

Once, the browser is idle in this time period (from receiving the first byte to rendering the start). This is because in the old browser, the download of a script blocks all other resources, such as ie6&7. The browser manufacturer realizes that although the browser needs to wait for the script download to complete before building the DOM, there is no reason to block concurrent downloads of other resources on the page. After the IE8 of 2009, the browser preloaded requests for additional resources. Research shows that preload makes the page load speed 20% faster. Today, all major browsers support preload. In these browser data, I show the earliest supported versions of each major browser.

(Incidentally, I think preload is the most effective way to improve performance.) Imagine that a script download in your current browser will block other resources, and the page's performance will be so much worse than the size of the script on the page.

pre-loading and response pictures

And then we're going back to Jason Grigsby's tweet:

I have to admit a little. I tried to push the response picture and was increasingly inclined to encourage developers to use JS to block preload.

Jason's "responsive picture" is a technique that uses a script to generate a picture. Usually this technique is used to achieve the resolution adaptation of the picture. One example is Picturefill. When you think of "preload" and "response picture"--preload will load the src of the picture in advance, but the response-style picture technology usually has no SRC, or just has a 1x1 alternative picture. There is a conflict between the two technologies. Here are some trade-offs:

• Do not use response pictures so that the browser can use preload to download pictures as quickly as possible, but the picture may be much larger than the size required, and will take longer to download (more traffic)
• With a response picture, because no preload is used, it means that the picture will be downloaded after the script is downloaded, and the IMG tag is already created.

Then Jason said in the latter tweet:

What makes me uncomfortable is that most of the conclusions have not been tested. Just some theory, not data.

I don't have data to compare these two ways, but the time it takes to start rendering in HTTP archive is One-third of the total load time, which also explains some of the problems. It seems that the rendering is blocked by the script, which means that the IMG tag has not been created yet. Then after 1/3 o ' hour, the IMG tag will be parsed, then JS and CSS will execute and start downloading the required pictures.

I think it's too late to initialize the picture request during the page load, and the rendering time of the page is really delayed when the preload effect is used. Again, I have no data to compare these two technologies. At the same time, I'm not sure how to use preload in markup-tech response pictures. (Jason has a blog post with relevant content, the real conflict behind <picture> and @srcset)

Ideally, we used markup to solve the conflict between preload and response pictures. Until then, I was still concerned that the use of such technologies in the development community would allow response pictures to pay the cost of preload failure. I want the browser to enhance the preload effect, so now and in the future the site will be able to take full advantage of the preload features.