[Translated] Load picture using parallel streams progressive

Pictures progressive rendering and HTTP / 2 multiplexing technology has been around for some time, but now we will combine the two in a new way so as to play a greater power. Cloudflare use of progressive streaming, image loading time can be cut by half, and the browser can begin to render pages faster .

Establish HTTP / 1.1 server connection no power to decide the order to send resources to the client; the response as a whole can not be divided and accurate in order to send the browser request. HTTP / 2 improvement in this regard is the addition of a multiplexer and priority, so that the server can decide what time to select transmission data and transmitted. We use these new HTTP / 2 function, send pictures by prioritizing the most important segment data, to improve the perceived loading speed progressive images.

This feature is compatible with all major browsers, and does not require any changes to the page marked, easy to use. Participate in the Beta registration, so that your website can use this feature it!

What is progressive rendering picture?

General picture is loaded in strict accordance with the order from top to bottom. If the browser has received only half of the picture file, then it will only show the top half of the picture. Arrangement of the contents of progressive pictures are not from top to bottom, but by the level of detail from low to high ranking. Even if the browser received only part of the data, it can also show the whole picture, but there is loss of clarity. As more data is received successfully, the picture will become clearer.

This feature is useful for JPEG format, since the display image preview only 10-15% of the data, and when 50% of the data is loaded, the picture looks almost the entire file arrives as clear. Progressive JPEG image data and the general picture is consistent, but in a way easier to use sorted, progressive rendering does not increase the size of the file. This is possible because the JPEG images are not stored as pixels. It uses frequency coefficients to represent the image, like a set of predefined styles, can be mixed in any order can reconstruct original thought. JPEG internal structure is very interesting, you can from my permormance.now () conference presentations to learn more.

The end result is an image with half the time seems almost no difference between a loaded and no cost. Full page visual effects, and can be put to use more quickly. The rest of the image data will soon arrive, and notice any default in the browser's image before upgrading to a complete definition of quality.

HTTP / 2 progressive flow

But that there is a problem. The site will be more than a picture (sometimes even hundreds of pictures). When the server in a primitive way to transfer pictures one by one, progressive rendering much help, because in general the picture is still loaded in order:

All data received half of the picture (but did not receive any of the remaining half of the picture data) does not look as half of the data received all the pictures.

And there is another problem: when a browser of the unknown image size when it layout with placeholders, and then loaded on each time the relayout FIG. This will make the process of loading the page in the beating, this is very abrupt, allowing users to feel distracted, bored.

Our progressive flow of new features to significantly improve this situation: we can send a one-time parallel all the pictures. So that the browser can get all the information as soon as possible the size of the picture, and then you can draw on large amounts of data without waiting for a preview of all pictures, but the big picture is not delayed loading styles, scripts, and other important resources.

Parallel streams progressive image loading concept as old and HTTP / 2 itself, but it requires special handling network server base member, so far not been large-scale application of this technology.

When we improve HTTP / 2 priority , we realize that it can also be used to improve this feature. Image files as a whole is neither a high priority nor is it a low priority. Each file different priorities, priority is given to us to dynamically adjust the desired behavior:

  • Picture containing the picture size of the head very high priority, because the browser needs to know the size of the page layout as soon as possible. Pictures head is small, and it does not hurt to send data earlier than the other.

Known image sizes make layout stable

  • Image preview show the required minimum amount of image data has medium priority (We have the complete picture is not loaded as early as possible to reserve space, but also for scripts, fonts, and other resources leaving sufficient bandwidth).

Half of the data looks good enough

  • The rest of the image data is a low priority. The browser can accept it when it does not matter to improve picture quality, because the page has been fully available.

  • To understand the exact amount of data to be transmitted at each stage, you need to understand the structure of an image file, but allows the network server to parse image response, and the hard-coded behavior-based format, will look very strange on the protocol level. And this issue as a priority to deal with dynamic change, we can elegantly split off from the underlying network coding and image format information. We can use Worker or image processing tools to analyze images in line, and a corresponding change in the guidance server HTTP / 2 priority.

Picture benefits of parallel streams that it does not add any overhead. We continue to send the same data, the same amount of data, we are just in a smarter way to send it. This technique takes advantage of the existing network standards, it is compatible across all browsers.

Waterfall

The following are the WebPageTest waterfall obtained, shows a comparison of normal HTTP / 2 response and progressive flow. In both cases the same document, same amount of data transmitted, the total page load time is also consistent (within the measurement error). FIG blue fragment data is being transmitted, green indicates request waiting.

The first figure shows a typical server behavior pictures sequentially loaded. Figure looks neat, but the actual page load experience is not good - Last Photo until nearly the last to start loading.

The second map shows a picture parallel load. FIG on the blue vertical line represents the picture header after the earlier transmission, and several stages of progressive rendering. You can see the earlier data useful part of all the pictures have arrived. You may also notice that there is a one-time sending a picture, not like other pictures of the same batch is completed. That is because in the beginning of the TCP / IP connection is established we do not know the real speed of the connection, we had to sacrifice some opportunities priority to maximize connection speed.

Compared with other methods of indicators

There are other techniques are also used to provide faster image preview, such as low-quality image place (LQIP), but they have some drawbacks. They added a placeholder unnecessary data, and often interfere with preloaded scan browser, and delay loading the full picture, as the replacement to complete the picture preview dependent on JavaScript.

  • Our approach does not increase request, not to add more data. The total page load time will not be delayed.
  • Our method does not require JavaScript. It uses the native browser functionality.
  • Our method does not need to change the page markup, so the station's deployment is safe and simple.

Improve the user experience can be, for example, SpeedIndex manifested on performance indicators, as well as time to complete the vision. Please note that the general picture download process appears to be linear, but gradual flow so that it can quickly proceed until substantially complete:

Maximum use progressive rendering

Avoid JavaScript damage effects. Hide picture until the onloadevent was displayed (fade in, etc.) will make the script progressive rendering invalid. Progressive rendering traditional <img>best effect element.

Only JPEG can it?

Our application is not dependent on the format, but the gradual flow is only useful for certain file types. For example, a script or style is not feasible to use it: These resources not only render rendering or all of the two states.

Priority send a picture header (including image size) are applicable to all formats.

Benefits progressive rendering of JPEG (all browsers support) and JPEG 2000 (Safari support) is unique. GIF and PNG have staggered pattern, but these patterns accompanied by compression and bad students. WebP do not support progressive rendering. This creates a dilemma: WebP is usually smaller than the JPEG the same quality of 20% to 30%, but progressive JPEG seem to load faster by 50%. Some of the next generation of image formats support progressive rendering is better than JPEG, WebP compression ratio better, but browsers do not support these formats. At the same time you can modify Cloudflare Polish panel settings, choose between saving bandwidth WebP and perceived better performance progressive JPEG.

Custom header of the test

We also support custom HTTP headers to test, to optimize the resources of other streaming site. For example, you can let our server sends the first priority frame animated GIF, while the rest of the frame delay. Or you can HTML document <body>is loaded first before loading the <head>resources mentioned in the label.

Custom header can only be set in the Worker. Syntax is a comma-separated list of file locations, including priority and concurrency options. The entire file priority and concurrency option with the previous blog post mentioned as cf-priority header.

cf-priority-change: <offset in bytes>:<priority>/<concurrency>, ...
复制代码

For example, for this we use progressive JPEG (JavaScript fragment Worker in):

let headers = new Headers(response.headers);
headers.set("cf-priority", "30/0");
headers.set("cf-priority-change", "512:20/1, 15000:10/n");
return new Response(response.body, {headers});
复制代码

It tells the server, when a start byte 512 sent by the first 30 as the priority. 20 and then switch to priority and a degree of concurrency ( /1), 15,000 bytes sent after the last document, switch to the low priority high concurrency ( /n) the remainder of the file are transmitted.

We tried to split HTTP / 2 frame header matches the specified offset, thereby changing the priority of the transmission as soon as possible. However, the priority does not guarantee that the data on the different streams are multiplexed in strict accordance with the instructions, because the server only needs to send multiple streams simultaneously when prioritizing data applications. If some request arrives from the upstream browser cache or earlier, the server may send them immediately, rather than waiting for other requests.

Try!

You can use our Polish tools to turn your pictures into progressive JPEG. Add beta to gracefully using parallel streams.

If you find there is a translation error or other areas for improvement, welcome to Denver translation program to be modified and translations PR, also obtained the corresponding bonus points. The beginning of the article Permalink article is the MarkDown the links in this article on GitHub.


Nuggets Translation Project is a high-quality translation of technical articles Internet community, Source for the Nuggets English Share article on. Content covering Android , iOS , front-end , back-end , block chain , product , design , artificial intelligence field, etc., you want to see more high-quality translations, please continue to focus Nuggets translation program , the official micro-blog , we know almost columns .

Guess you like

Origin juejin.im/post/5d044fe3f265da1bd04eddda
Recommended