In terms of bandwidth, images - gluttons. On average, they take the highest ( 62% ) average traffic sites and they are likely to transfer bottleneck. Loaded, images torn page, pushing other elements around and causing awkward repaint (graphic.: Of course, you can get rid of a certain layout, but then you hardkodit or limit the size of images). Loading images on the page, or is perceived as a "tick, tick, tick, tick, tick, done," or nothing at all at first, and then all of a sudden "boom," and it appears out of nowhere. Everyone understands what is meant by "tick, tick, done" and "boom" and all of us, it's a bit annoying because we feel, how much time our lovely and short lives lost waiting to upload pictures.
Missed opportunity
Photos - the main culprit of slow rendering. They are the most frequently requested type of image , and the average weigh more than others . They are millions of colors and the number of bits per pixel continues to increase. They are beautiful and we do not want to compromise on quality.
Optimized for the web photo - this jpeg, jpeg and is divided into two types: basic serial (baseline) and progressive (progressive). Serial jpeg - this one scan image from top to bottom at full resolution and progressive jpeg - a series of scans improves quality. So they are rendered - serial jpeg drawn down ("tick, tick, tick, ..."), and progressive quickly sets his territory and then perfection (at least as intended).
Progressive jpeg is better because it's faster. The fast - is to be faster and the perceived speed is more important than the actual speed. Even if we save on providing content, progressive jpeg gives as much as possible as soon as possible. It helps us to provide more complex problem, and beautiful photos.
In a local experiment - an illustration at the beginning of Lent - strangled by the channel, 80-Kbyte progressive jpeg appears on the page before the 5-Kbyte serial jpeg (same image, reduced in size) in Firefox under Windows, which should make an impression. Of course, in the first pass progressive jpeg low resolution, but it contains the same information as you and a small image, or even more. And if the page scale is reduced, for example, on a mobile device, the lower resolution is not even noticeable. Adaptive image working for us right now (graphic.: Sending a responsive Web Design )!
Essentially, progressive jpeg better. So what is the most common type of jpeg online? You guessed it: sequential, and with a very wide margin. In a sample of thousands of images, 92.6% - consistent.
Do not worry, we only need to declare that the progressive jpeg - this is best practice, and to drag the rest of the world for us to board. But to make such a declaration, you have to be confident in it. And to do this you first need to understand how things work with a progressive jpeg browsers.
Reality Check № 1
Progressive jpeg rendered in all browsers, so do not worry. We are concerned about the way they are drawn.
Progressive jpeg behavior in browsers
| Browser (specific version) | Drawing progressive jpeg foreground (foreground) | Drawing progressive jpeg background (background) |
|---|---|---|
| Chrome (v 25.0.1323.1 dev Mac, 23.0.1271.97 m Win) | progressive (very quick!) | progressive (very quick!) |
| Firefox (v 15.0.1 Mac, 12.0 Win) | progressive (very quick!) | immediately after loading (slow) |
| Internet Explorer 8 | immediately after loading (slow) | immediately after loading (slow) |
| Internet Explorer 9 | progressive (very quick!) | immediately after loading (slow) |
| Safari (v 6.0 Desktop, v 6.0 Mobile) | immediately after loading (slow) | immediately after loading (slow) |
| Opera (v 11.60) | UPD: progressive (very quickly!) ( Proof ) | immediately after loading (slow) |
Disappointing results, but in general, the share of the browser market with progressive rendering progressive jpeg goes up. Support so far is about 65% (Chrome + Firefox + IE9).
Unfortunately, the browser that is not progressive jpeg are rendering progressively render them all at once after loading the image is complete, which, in fact, makes them less progressive. They are slower than sequential jpeg. Despite the fact that the sequential rendering is not as fast and smooth as a progressive, at least it gives something, while we're waiting, and "tick, tick" is an indicator for download (good thing). Do not underestimate the confidence felt by people seeing that something is happening.
Choosing a progressive jpeg we provide most users a great experience and a minority - a very significant minority - the worst experience. But choose the serial jpeg because it is more suitable in the minority views - terrible compromise. Need to offer users the best and look to the future.
Reality Check number 2
You may ask, "But will not the progressive jpeg weigh more than usual? We do not pay for the "layers"? '. With other types of multilayer nekotoroymi images - pay, but not with the jpeg. Progressive jpeg is usually several kilobytes less than his own serial version. Stoyan Stefanov, in a plot to convert 10,000 random sequential jpeg to progressive , discovered a valuable rule of thumb: the files bigger than 10KB, most likely, will weigh less in the progressive form.
Convince would be easier if we could say that the progressive jpeg always weigh less, and so they should always be used. Stoyan us this helps. He says, "One more observation on the rule 10K: in those cases where serial jpeg less weight, it is smaller with a small difference. When less progressive, it is usually much less. So to say that you should always use a progressive and will be better - this is normal. "
Just that and I wanted to hear! Give to us in each sequential jpeg missed opportunity in file size and perceived loading speed. The choice of the progressive option besproigryshen and must always be the default selection. And just when all the progressive jpeg, if you want further optimized, it will be possible to save a few bytes, and only on the small image.
The reason that the sequential jpeg most prevalent in the network, is, of course, is that image optimization tools create them by default. However, all viewed me - Photoshop, Fireworks, ImageMagick, jpegtran - have the ability to save and in the progressive form. So, to give progressive jpeg, need to consciously modify your optimization process images.
For example, Smushit can translate sequential jpeg to progressive. Smushit, incidentally, can be run from the command line and integrated into the process of optimizing images.
How do you know that your progressive jpeg? Here are a few ways to identify the type of jpeg:
- ImageMagick - from the command line, run:
identify -verbose mystery.jpg | grep InterlaceThe output will be either "Interlace: JPEG", or "Interlace: None." - Photoshop - Open the file. Select File -> Save for Web & Devices. If a progressive jpeg, then select Progressive will be marked.
- Any browser - Serial jpeg will be loaded from the top down, and advanced to behave differently. If the file is loaded too quickly, you may need limiting bandwidth. I use ipfw under Mac'om.
Reality Check № 3
According to this FAQ on JPEG compression , each progressive pass rendering CPU load by about the same, as far as drawing a sequential jpeg. It's not important for desktop PCs, but perhaps has implications for mobile devices.
Extra computing - a drawback, but not a stumbling block. The photographs on weak hardware - a difficult task regardless of this. I'm in the know, because I write application gallery with infinite scrolling and it falls on iPad'e. When processing large numbers of images on mobile platforms challenges arise in any case.
As seen in the table, the mobile Safari does not draw progressive jpeg progressive and probably because they stress the CPU. Progressive jpeg is not a new format images. Therefore, consciously and without any reason not to support the progressive jpeg - not an option for the browser, even mobile. Let's hope that soon the mobile browsers will deal with progressive rendering, but the reasons for the current lack of support make sense. It's a shame, because just on mobile devices increase in speed and economy in the size of files that provides progressive jpeg, would come in handy. It was mentioned above that he seems to be a solution for adaptive image at the moment. In fact, it might be so, but the time is not ripe.
Looking to the future
A month ago, Google jumped on board with their service Mod_Pagespeed , making
convert_jpeg_to_progressive main filter . SPDY is also not lagging behind, translating a 10Kb jpeg to progressive by default , according to the rule of thumb was standing. Browsers that support incremental mapping of this will seem a lot faster. As can be seen from the table above, which includes Google Chrome, Google these actions make sense.
I will not say that if it 'no-cause-evil-do-web faster "Google chose
progressive jpeg as best practice, then we must all the more. But this is more proof.
And most importantly, it shows that a progressive jpeg - format, which
was kind of a freezer for a decade - begins his comeback. Not all current browsers implement progressive rendering progressive jpeg. Despite this, the ones that sell - really benefit from this. And besides, we have savings in file size. Today, it is the best option and should use it. Progressive jpeg - this is the future, not the past.
Articles
0 commentaires:
Enregistrer un commentaire