Picture performance optimization "Go" in page load

Most of my performance optimizations are focused on JavaScript and CSS, from the early move Scripts to the bottom and put stylesheets at 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.

I focus on JS and CSS and how to download pictures faster. Images are visible to the user. They are not interested in JS and CSS. Indeed, JS and CSS will affect the display of the image content, especially the way the image is displayed (compared to the slice carousel, CSS background, and media query). 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, rather than try to ensure that JS and css faster download complete.

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

Time to start rendering is too late

Looking at the idea of rendering time, I queried HTTP archive to see when our page started rendering. Here are some of the measured values:

• TTFB, the time when the first HTML document packet arrived
• Time to start rendering
• The time the page onload was triggered

From the measured values of the world's fastest 300,000 addresses, I extracted 50% and 90% parts. As shown below, there are no rendering actions in the first One-third time period of page load.

Table 1. Various points of time during page loading
	TTFB	start rendering	onload
50th percentile	610 MS	2227 ms	6229 ms
90th percentile	1780 MS	5112 ms	15969 ms

Pre-load

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 indicates that the page took 32% to 36% of the time to wait for the rendering to begin. But it only takes 10% of the time to get the first byte. Therefore, the browser in the 22% to 26% of the time period, although the data has been accepted, but do not make any rendering. During this time, browsers usually download parsing scripts and styles-both of which hinder page rendering.

Once, the browser was idle during this time period (from the reception to the first byte to the start of the rendering). This is because in the old browser, the download of a script blocks all other downloads of resources, such as ie6&7. The browser maker realizes that while the browser needs to wait for the script download to complete before it can build the DOM, there is no reason to block parallel downloads of other resources on the page. After the IE8 in 2009, the browser preloaded requests for additional resources. Research shows that preload makes pages load faster by 20%. Pre-loading is supported by all major browsers today. In these browser data, I showed that each major browser supported the pre-loaded version at the earliest.

(Incidentally, I think preloading is the most effective way to improve performance.) Imagine the current browser script download will block other resources, face the page so large number of scripts, page performance will be bad to what extent.

Preloaded and responsive pictures

Then we go back to Jason Grigsby's tweet:

I have to admit a little. I'm trying to push the responsive picture, and I'm increasingly inclined to encourage developers to use JS to block preloading.

Jason refers to the "responsive picture" is a technique that uses a script to generate images. This technique is often used to achieve image resolution adaptation. An example is Picturefill. When you think about "preloaded" and "responsive Pictures"-preload will load the src of the image ahead of time, but the responsive picture technology usually doesn't have SRC, or just a 1x1 alternative image. There is a conflict between the two technologies. Here are some tradeoffs:

• Do not use responsive images so your browser can download images as quickly as possible with preload, but images may be much larger than needed and take longer to download (consuming more traffic)
• With a responsive picture, because the preload is not used, it means that the image will be downloaded after the script is downloaded and the IMG tag has been created.

Then Jason said in a later tweet:

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

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

I think it is too late to initialize the picture request during the page load, and the rendering time of the page has indeed been postponed, relative to the pre-loaded effect. Again, I have no data to compare these two technologies. At the same time, I'm not sure how to use preload in markup technology's responsive images. (Jason has a blog post with relevant content, the real conflict behind <picture> and @srcset)

Ideally, we used markup to solve the conflict between preloaded and responsive images. Until then, I was still worried about the cost of using this technology in the development community to make the responsive picture pay for the preload. I want the browser to enhance the preload, so now and in the future the site will be able to take advantage of preloaded features.

Picture performance optimization "Go" in page load