Пользователь
0,0
рейтинг
13 января 2013 в 16:55

Разработка → Прогрессивный JPEG: новый best practice перевод

Сравнение скорости загрузки прогрессивного и последовательного jpeg
С точки зрения пропускной способности канала, изображения — обжоры. В среднем, они занимают наибольший (62%) средний трафик сайтов и чаще всего их передача является узким местом. Загружаясь, изображения рвут страницу, расталкивая другие элементы вокруг и вызывая неуклюжую перерисовку (прим. перев.: от этого, конечно, можно избавиться определенной версткой, но тогда нужно хардкодить или ограничивать размеры картинок). Загрузка изображения на странице воспринимается или как «тик, тик, тик, тик, тик, готово», или же сначала вообще ничего нет, а потом внезапно «бум!» и оно появляется ниоткуда. Все понимают, что подразумевается под «тик, тик, готово» и «бум» и всех нас это немного раздражает, потому что мы чувствуем, сколько времени наших прелестных и коротких жизней потеряно в ожидании загрузки картинок.


Упущенная возможность


Фотографии — главный виновник медленного рендеринга. Они являются наиболее часто запрашиваемым типом изображений и в среднем весят больше остальных. В них миллионы цветов и количество бит на пиксель продолжает увеличиваться. Они красивы и мы не хотим компромиссов на качестве.

Оптимизированные для веба фото — это jpeg, а jpeg делится на два типа: базовый последовательный (baseline) и прогрессивный (progressive). Последовательный jpeg — это один скан изображения сверху вниз в полном разрешении, а прогрессивный jpeg — это серия сканов улучшающегося качества. Так они и рендерятся — последовательный jpeg отрисовывается сверху вниз («тик, тик, тик, …»), а прогрессивный быстро размечает свою территорию и затем совершенствуется (по крайней мере так задумано).

Прогрессивный jpeg лучше, потому что он быстрее. Появляться быстрее — значит быть быстрее, а воспринимаемая скорость важнее фактической скорости. Даже если мы экономим на предоставляемом контенте, прогрессивный jpeg дает как можно больше, как можно скорее. Он помогает нам в сложной задаче предоставления больших и красивых фотографий.

В локальном эксперименте — иллюстрация в начале поста — на задушенном канале, 80-килобайтный прогрессивный jpeg появляется на странице раньше, чем 5-килобайтный последовательный jpeg (то же самое изображение, уменьшенное в размере) в Firefox под Windows, что должно произвести впечатление. Конечно, на первом проходе прогрессивный jpeg имеет низкое разрешение, но он содержит столько же информации, сколько и маленькое изображение, или даже больше. А если масштаб страницы уменьшен, например, на мобильном устройстве, то низкое разрешение даже не заметно. Адаптивные изображения работают на нас прямо сейчас (прим. перев.: отсылка к responsive web design)!

По существу, прогрессивный jpeg лучше. Так какой же самый распространенный тип jpeg в сети? Угадали: последовательный, и с очень большим отрывом. В выборке из тысячи изображений, 92.6% — последовательные.

Не беспокойтесь, нам всего лишь нужно объявить, что прогрессивный jpeg — это best practice и затащить остальной мир к нам на борт. Но чтобы сделать такое объявление, нужно быть в нем уверенным. А для этого сначала необходимо понять, как сегодня обстоят дела с поддержкой прогрессивного jpeg браузерами.


Проверка реальностью №1


Прогрессивные jpeg отрисовываются во всех браузерах, об этом не стоит переживать. Нас волнует то, как они отрисовываются.

Поведение прогрессивных jpeg в браузерах
Браузер (конкретная версия) Отрисовка прогрессивных jpeg переднего плана (foreground) Отрисовка прогрессивных jpeg заднего плана (background)
Chrome (v 25.0.1323.1 dev Mac, 23.0.1271.97 m Win) прогрессивно (очень быстро!) прогрессивно (очень быстро!)
Firefox (v 15.0.1 Mac, 12.0 Win) прогрессивно (очень быстро!) мгновенно после загрузки файла (медленно)
Internet Explorer 8 мгновенно после загрузки файла (медленно) мгновенно после загрузки файла (медленно)
Internet Explorer 9 прогрессивно (очень быстро!) мгновенно после загрузки файла (медленно)
Safari (v 6.0 Desktop, v 6.0 Mobile) мгновенно после загрузки файла (медленно) мгновенно после загрузки файла (медленно)
Opera (v 11.60) UPD: прогрессивно (очень быстро!) (proof) мгновенно после загрузки файла (медленно)

Результаты разочаровывающие, но в целом, доля рынка браузеров с прогрессивной отрисовкой прогрессивных jpeg идет вверх. Поддержка пока что составляет около 65% (Chrome + Firefox + IE9).

К сожалению, браузеры, которые не рендерят прогрессивные jpeg прогрессивно, отрисовывают их сразу целиком после того, как загрузка изображения завершена, что, по сути, делает их менее прогрессивными. Они становятся медленнее, чем последовательные jpeg. Несмотря на то, что последовательная отрисовка не такая быстрая и плавная, как прогрессивная, она по крайней мере дает хоть что-то, пока мы ждем, и «тик, тик» является своего рода индикатором загрузки (хорошей вещью). Нельзя недооценивать уверенность, которую чувствуют пользователи видя, что что-то происходит.

Выбирая прогрессивный jpeg мы обеспечиваем большинству пользователей отличные впечатления и меньшинству — весьма значимому меньшинству — худшие впечатления. Но выбирать последовательный jpeg потому, что он больше подходит в меньшинстве просмотров — ужасный компромисс. Нужно предлагать пользователям лучшее и смотреть в будущее.


Проверка реальностью №2


Вы можете спросить «А не будут ли прогрессивные jpeg весить больше, чем обычные? Не платим ли мы за “слои”?». С некотороыми другими типами многослойных изображений — платим, но не с jpeg. Прогрессивный jpeg обычно на несколько килобайт меньше, чем его же последовательная версия. Стоян Стефанов в процессе построения графика конвертации 10000 случайных последовательных jpeg в прогрессивные, открыл ценное практическое правило: файлы больше 10Кб, чаще всего, будут весить меньше в прогрессивном варианте.

Убеждать стало бы проще, если бы можно было сказать, что прогрессивные jpeg всегда весят меньше, так что их и нужно всегда использовать. Стоян нам в этом помогает. Он говорит: «Еще одно наблюдение по поводу правила 10Кб: в тех случаях, когда вес последовательного jpeg меньше, он меньше с небольшой разницей. А когда меньше прогрессивный, то он обычно меньше намного. Так что говорить, что нужно всегда использовать прогрессивный и станет лучше — это нормально».

Как раз то, что и хотелось услышать! На каждом отдаваемом нами последовательном jpeg были упущены возможности в размере файла и воспринимаемой скорости загрузки. Выбор прогрессивного варианта беспроигрышен и всегда должен быть выбором по умолчанию. А уже когда все jpeg прогрессивны, если хочется дальше оптимизировать, то сэкономить можно будет считанные байты и только на самых маленьких изображениях.

Причиной того, что последовательные jpeg наиболее распространены в сети, является, без сомнения, то, что инструменты оптимизации изображений создают их по умолчанию. Однако, все просмотренные мною — Photoshop, Fireworks, ImageMagick, jpegtran — имеют возможность сохранения и в прогрессивном варианте. Таким образом, чтобы отдавать прогрессивные jpeg, нужно сознательно модифицировать свой процесс оптимизации изображений.

Например, Smushit может переводить последовательные jpeg в прогрессивные. Smushit, кстати, можно запускать из командной строки и интегрировать в процесс оптимизации изображений.

Как узнать, что ваши jpeg прогрессивные? Вот несколько способов идентификации типа jpeg:
  1. ImageMagick — из командной строки запустите: identify -verbose mystery.jpg | grep Interlace На выходе будет или “Interlace: JPEG”, или “Interlace: None.”
  2. Photoshop — Откройте файл. Выберите File -> Save for Web & Devices. Если это прогрессивный jpeg, то флажок Progressive будет отмечен.
  3. Любой браузер — Последовательные jpeg будут загружаться сверху вниз, а прогрессивные будут вести себя по-другому. Если файл загружается слишком быстро, может понадобиться ограничение пропускной способности канала. Я использую ipfw под Mac’ом.


Проверка реальностью №3


Согласно этому FAQ по сжатию jpeg, каждый прогрессивный проход отрисовки нагружает ЦПУ примерно на столько же, на сколько отрисовка целого последовательного jpeg. Это неважно для настольных ПК, но возможно имеет значение для мобильных устройств.

Лишние вычисления — недостаток, но не камень преткновения. Предоставление фотографий на слабом аппаратном обеспечении — сложная задача вне зависимости от этого. Я в курсе дела, потому что пишу приложение-фотогалерею с бесконечным скроллингом и оно падает на iPad’e. При обработке большого количества изображений на мобильных платформах сложные задачи возникнут в любом случае.

Как видно в таблице, мобильный Safari не отрисовывает прогрессивные jpeg прогрессивно и вероятно потому, что они нагружают ЦПУ. Прогрессивый jpeg не является новым форматом изображений. Следовательно, осознанно и без причин не поддерживать прогрессивный jpeg — не вариант для браузеров, даже для мобильных. Будем надеяться, что скоро мобильные браузеры станут справляться с прогрессивным рендерингом, но причины текущего отсутствия поддержки имеют смысл. Очень обидно, потому что как раз на мобильных устройствах прирост скорости и экономия в размерах файлов, которые предоставляет прогрессивный jpeg, пришлись бы очень кстати. Выше было упомянуто, что он как бы является решением для адаптивных изображений на данный момент. На самом деле он мог бы быть таковым, но время еще не пришло.


Глядя в будущее


Месяц назад, Google запрыгнул на борт со своим сервисом Mod_Pagespeed, сделав convert_jpeg_to_progressive основным фильтром. SPDY тоже не отстает, переводя jpeg более 10Кб в прогрессивные по умолчанию, согласно практическому правилу Стояна. Браузеры, поддерживающие инкрементальное отображение, от этого станут казаться намного быстрее. Как видно из таблицы выше, включающей Google Chrome, такие действия Google имеют смысл. Я не стану говорить, что если уж «не-причиняй-зла-делай-веб-быстрее» Гугл выбрал progressive jpeg как best practice, то и мы должны тем более. Но это лишнее подтверждение. И самое главное, это показывает, что прогрессивный jpeg — формат, который был в своего рода морозилке на протяжении десятилетия — начинает свое возвращение.

Не все текущие браузеры реализуют прогрессивный рендеринг прогрессивных jpeg. Несмотря на это, те, что реализуют — действительно в выигрыше из-за этого. И к тому же, мы получаем экономию в размерах файлов. Сегодня это лучший вариант и стоит им пользоваться. Прогрессивный jpeg — это будущее, а не прошлое.
Перевод: Ann Robson
Дмитрий Мизин @Falco
карма
16,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (88)

  • +21
    Я один как дурак сидел ждал, пока прогрузится «progressive 78.3K»? =\\
  • +8
    Очень плохой перевод.
    • +4
      Будьте конкретнее, пожалуйста. Предложите, где перевести лучше — я исправлю.
      • +6
        Тяжелый стиль изложения у Вас. Прочитав первый абзац, сразу становится понятно, что это именно перевод.
        Если давать какие-то конкретные советы, то придется разбирать почти каждое предложение.

        Лично я, переводя тексты, даю тексту «настояться» пару часов, а потом перечитываю и редактирую. Как-то так.
        • +2
          Первый абзац во всем тексте был самым сложным для перевода. Настояться тексту дал ночь, с утра перечитывал, правил, где в голову приходили варианты лучше. Советы как раз по первому абзацу были бы кстати.
      • +1
        От себя добавлю: нужно очень аккуратно обращаться с идиомами, особенно если они в техническом тексте используются. Подстрочный перевод ни в коем случае нельзя делать.
        • 0
          Что именно вы имеете ввиду в этом тексте?
          • +3
            Помимо знания значения иностранных слов, для перевода важно еще и хорошо знать свой родной язык. Ваш текст выглядит как будто его писал плохо владеющий русским языком человек. Разбирать можно каждое предложение, как уже было сказано. Про идиомы: "… чаще всего являются бутылочным горлом" — это калька с английского bottleneck. В русской речи используется фраза «узкое место/слабое место/слабое звено» в зависимости от контекста. Бутылочное горлышко — это порождение машинного перевода.
            • +2
              Так я сначала и написал. Но «большие изображение — узкое место» как-то не звучало, да и ru.wikipedia.org/wiki/%D0%91%D1%83%D1%82%D1%8B%D0%BB%D0%BE%D1%87%D0%BD%D0%BE%D0%B5_%D0%B3%D0%BE%D1%80%D0%BB%D0%BE вот, собственно. Калька, но даже со своей собственной статьей в википедии.
              • +3
                Статьи в википедии пишут обычные люди. В том числе и безграмотные. IT жаргон пестрит примерами бездумного копирования. «Бутылочное горло» пока не настолько распространенный и общеупотребительный термин, чтобы поощрять его использование. Идиомы не переводятся «в лоб». И их значение не подставляется строго по месту старого. Вся сложность в переводе идиом, это как раз частая необходимость полной перестройки фразы.
                • 0
                  По поводу статей, жаргона и идиом все справедливо и понятно. С чем я не согласен, так это с тем, что термин недостаточно распространен. Это субъективно. Мне он показался подходящим. Во всяком случае, он устранял неестественное впечатление от того, что большой размер является узким местом.
                  Предложите вариант лучше, я исправлю.
                  Ну и да, дисклеймер: я не профессиональный переводчик. На отличное качество перевода и не претендую. Старался перевести так, чтобы смысл был понятен.
                  • +2
                    Вот так, к примеру: "… их передача является узким местом". Ваш вариант звучит искусственно и тоже не имеет смысла. Если и использовать кальку с английского — то не сами изображения являются «бутылочным горлом», а задача их пересылки клиенту.

                    Добавлю про свиней: надо очень хорошо было над этим подумать. В американском английском слово pig еще является грубоватым названием обжоры. И это значение подходит по тексту. В русском языке свиньей, в первую очередь, называют неряху.
                    • +1
                      В оригинале было не pig, а hog.
                      Бутылочное горло исправил на ваш вариант, спасибо. Свиней тоже заменил на обжор. Когда писал изначально думал еще о коровах и слонах :).
                • 0
                  Вполне себе общеупотребительный термин, особенно при описывании ситуации на дорогах и причин пробок. Но я согласен, что «узкое место» лучше, ибо короче и проще произносится.
              • 0
                Не слушайте дураков. Оставьте «best practice», верните «bottleneck», и другие англицизмы, давно и прочно вошедшие в жаргон айтишников.
          • +1
            Например, по-русски говорят «узкое место», а не «бутылочное горло».
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Поглядел. Предлагаете сменить «best practice» на «лучшая практика»? По-моему общеупотребим и понятен английский вариант, а «лучшая практика» ну очень уж редко употребляется.
          • 0
            Не сменить, а перевести. Это же перевод, верно?
            • +2
              Это перевод, но на мой комментарий это замечание не отвечает. Как мне кажется, понятнее текущий вариант. Потому что на русском варианте в данном случае все равно взгляд споткнется. По крайней мере у меня при виде «лучшая практика» было бы что-то вроде «а, так это best practice имеется ввиду». Английский термин этот общеупотребим в ИТ. Как аналогии, на ум сразу приходят Generic'и, Assert'ы, Commit'ы, стартапы и прочее.
              • 0
                Понятнее английский быть не может, ибо большинство английского не знает. Хабр не исключение.
                • 0
                  Я не согласен. По аналогии, вы хотите сказать, что в приведенных случаях понятнее было бы использовать Обобщения, Утверждения, Фиксации и Запуски? По-моему как раз в таком случае большинство не поймет о чем речь. Знание определенных терминов английского языка — само собой в ИТ, а это как раз ИТ ресурс. Поэтому я и посчитал, что оставить best practice — понятнее.
                  • 0
                    Мне непонятно и то, и то. Ну может кроме коммита. Жаргонизм кстати вполне допустим в профессиональной среде, а вот написание на иностранном языке прекрасно переводимых фраз — нет. Это не перевод, это калька.
                    • 0
                      Все аналоги, которые я привел, точно так же «прекрасно переводимы», только в переведенном варианте объективно менее понятны большинству. Дальше уже субъективно, но по поводу жаргонизма, мне лично приятнее читать в русском тексте commit, assert и т.д., нежели коммит, ассерт. По-моему, в этом вопросе нет единственно правильного ответа. Мне определенно и осознанно больше нравится текущий вариант. И не кажется калькой.
                      • 0
                        У вас задвиг на «менее понятности». Откуда вы взяли объективность? Вы проводили исследование?
                        • 0
                          Если хотите, уберите из предыдущего коммента слово «объективно». Исследование я не проводил, но то, что описал, верно для меня и всех моих знакомых в ИТ, с которыми я хоть сколько-нибудь общался употребляя приведенными в пример терминами. Это все звучит понятно. Куда понятнее, чем фиксации и запуски.
                          По поводу «задвига», разве есть что-то плохое в приоритезировании понятности?
                          • 0
                            Плохо то, что вы делаете менее понятным для большинства, как я сказал выше.
                            • 0
                              Так выше же, в следующем комменте, я на это и ответил. Ну не повторять же сейчас весь диалог заново.
                              • 0
                                Не ответили. Незнание языков большинством объективно. Ваши душевные терзания субъективны.
                                • 0
                                  По-моему диалог становится бессмысленным. Я же писал по поводу незнания языка уже:
                                  Знание определенных терминов английского языка — само собой в ИТ, а это как раз ИТ ресурс.

                                  Если вы считаете, что в том примере использование «commit» и «assert» вместо «фиксация» и «утверждение» — мои душевные терзания, а не объективная понятность, то конструктивного диалога дальше точно никакого не выйдет.
                                  • 0
                                    Не переводите тему. Мы о «best practice» говорим. Проблем с переводом нет, кроме надуманных вами.
                                    • 0
                                      Я не перевожу тему, я привел вам аналогии, в которых абсолютно так же нет проблем с переводом. Именно такие аналогии привели меня к решению оставить «best practice» как есть. Вы не согласны с этим вариантом и аналогии вас не убеждают, это я понял. Но ответных доводов, убеждающих меня в обратном вы тоже не привели. По-моему дальше это обсуждать бессмысленно.
                                      • 0
                                        Это не аналогии, хотя бы потому что там термины, а тут нет. Это же перевод? Или вы писали сочинение по мотивам? Тогда вольности допустимы.
                                        • 0
                                          Не понимаю, чем «best practice» не подходит под определение термина. Это же термин, ничуть не меньше чем приведенные аналоги.
                                          • 0
                                            Потому что не термин. Потому что общее, не описывает конкретную сферу, и не нейтрально.
                                            • 0
                                              Это уже демагогия. Я воспринимаю это словосочетание термином. Весьма специфичным, применительно к нашей конкретной сфере. Нейтральным.
                                              Я не буду больше в этой ветке отвечать, т.к. не вижу смысла. Ничего конструктивного все равно не выходит.
                                              • 0
                                                Ха-ха, как быстро вы навешиваете ярлыки и называете не устраивающие вас аргументы «демагогией». Восприятие несовершенно, просто прислушайтесь к тому, что вам умные люди говорят.
                • +1
                  Поддерживаю Falco, мне например тоже понятнее «best practice». В it-статьях на французском, немецком языках, этот термин тоже обычно не переводят.

                  «Понятнее английский быть не может, ибо большинство английского не знает.»
                  А вы откуда знаете сколько языков знает большинство хабрапользователей?

                  И да, я не представляю человека который работает в данной области и не знает базового английского.
                  • 0
                    То есть вы бы ни в какую не поняли «лучшая практика»?
                    Про знание иностранных языков есть статистика. Большинство не знает ни одного. Кто-то учил в школе не английский, а немецкий. Кто-то может и знает базовый английский, но на перевод придётся затрить определённые усилия. И т. д.
                    Да и просто глаза ломают все эти перескакивания. Это неуважение к читателю.
                    • 0
                      «То есть вы бы ни в какую не поняли «лучшая практика»?»
                      У словосочетания best practice есть своя специфика, которая теряется при переводе. Я бы конечно понял, но в пересчете на мозговые «такты» — для соединения «лучшая практика» с его английским аналогом и спецификой которую оно в себе несет — их бы потребовалось больше.

                      «Про знание иностранных языков есть статистика. Большинство не знает ни одного. Кто-то учил в школе не английский, а немецкий.»
                      Я не про всю страну, а про хабр. Думаю здесь совсем другая картина.

                      «Это неуважение к читателю.»
                      Всем не угодишь. К тому-же надо делать скидку на айтишный жаргон, можно конечно переводить используя исконно русские слова и выражения, но думаю Мицгол не потерпит конкуренции :)
                      • 0
                        И что же это за непереводимая специфика?
                        На хабре процентное соотношение может немного отличается, но не принципиально.
                        Всем не угодишь, но хотя бы большинству следовало бы.
                        • 0
                          Подобной славянофилии место исключительно в провинциальных вузах, где преподы материал адаптируют из англоязычных источников.

                          Может еще монитор называть «смотрило», а то, глядишь, не поймут деревенские?
                          • 0
                            Так зачем переводить? Можно было вообще на английском оставить!
                            • 0
                              Не надо передергивать. Если вы не знаете как переводиться best practice (переведет школьник начальных классов), то у вас славянофилия в крайней форме. Вполне допустимо к месту использовать понятные большинству иноязычные словосочетания для стилизации текста. Sapienti sat.
                              • –1
                                Если вы не знаете как переводиться best practice (переведет школьник начальных классов)…
                                Боже мой, какая феерическая чушь: автор вот не справился с переводом. У него «славянофилия в крайней форме»?
                                Вполне допустимо к месту использовать понятные большинству иноязычные словосочетания для стилизации текста.
                                Может быть, но только не в переводе.
                                Sapienti sat.
                                У вас кроме латинских фраз доводов нет? Не надейтесь, на умного вы не смахиваете.
                                • 0
                                  Боже мой, какая феерическая чушь: автор вот не справился с переводом. У него «славянофилия в крайней форме»?

                                  Мы тут вас обсуждаем, а не автора статьи. Потрудитесь вникнуть в суть, прежде чем писать.
                                  Может быть, но только не в переводе.

                                  Вы тут не устанавливаете правила.
                                  У вас кроме латинских фраз доводов нет? Не надейтесь, на умного вы не смахиваете.

                                  Поясняю для альтернативно одаренных — это был пример употребления иноязычной фразы в контексте.

                                  На этом разговор закончен. Метать бисер перед свиньями не собираюсь.
                                  • 0
                                    Меня обсуждать нечего, не я публиковал «перевод».
                                    Правила я не устанавливаю, я на них указываю.
                                    Это чушь, а не примеры.
                        • 0
                          Специфика в том что данный термин повсеместно используется в англо-говорящих интернетах для обозначения рекомендации для работы с чем-либо. Также он крайне часто используется в неанглийских интернетах — просто так повелось, большая часть разработчиков к нему привыкла. Поэтому обычно разработчику понятнее английское словосочетание, чем аналог из родного языка.

                          «На хабре процентное соотношение может немного отличается, но не принципиально.»
                          Повторюсь, хабр это it ресурс, что это за «немного»? И процентное соотношение айтишников тоже немного отличается от среднего по стране? Вы в курсе что без знания английского в it по большему счету искать нечего?
                          • –3
                            Также он крайне часто используется в неанглийских интернетах — просто так повелось…
                            Из-за таких же кривых переводов. Вы ещё «Силиконовую долину» вспомните. Впрочем это уже сомнительное утверждение, есть пруф?
                            Поэтому обычно разработчику понятнее английское словосочетание, чем аналог из родного языка.
                            Лол, что?! Полная чушь. Правильная сформулированная фраза на русском по-любому будет лучше понятна большинству.
                            Вы в курсе что без знания английского в it по большему счету искать нечего?
                            Тогда зачем эти переводы? Пусть все в оригинале читают.
                  • 0
                    Верно, если переводить на русский получится что-то вроде «наилучший способ, призванный стать единственно верным». Коряво, может можно лучше, но намного короче и лаконичнее вряд ли можно перевести. Так что лучше «best practice».
          • 0
            Я не стал бы заменять «best practice» на «лучшая практика» хотя бы потомý, что «лучшая» может означать и «better» (а не только «best») в зависимости от предубеждённости читателя.

            Однако я мог бы, наверное, заменить «best practice» на «наилучшая практика» в этом предложении, чего и Вам советую.
      • +1
        Вы переводите слова. А нужно переводить смысл.

        Где плохо? Везде. Я видел много переводов и сам занимаюсь переводами и вижу. Первый признак плохого перевода — слово «это» в начале строки, как следствие перевода предложений, начинающихся с it.
  • +14
    2013-й год, а мы все еще сидим на древнем JPEG-е.
    Печально.
    • 0
      Для Web'а — это нормально, а вот для фотографии нет. Связано это, скорее всего с устройствами отображения.
    • +2
      Угу. Хочу Jpeg2000. Но прошло 12 лет, а воз и ныне там…
      • +1
        WebP, JPEG XR
      • +3
        Нынче в моде WebP. Jpeg2000 не получил шанса из-за не полностью свободной лицензии. Вот она, жадность.
        • +1
          Вы что-то путаете, Jpeg2000 свободный, с традиционно прилагающимися к открытым стандартам обещаниями не давить патентами. У него есть проприетарные реализации, но и минимум две открытые есть.
          • 0
            У j2k, помнится, арифметический кодер не свободный. Насчет поддержки альтернативных реализаций в пределах стандарта не уверен.
    • 0
      h265 still images (HEVC) обещает быть на 43-61% эффективнее JPEG, и на десятки процентов эффективнее всяких Jpeg200, XR, WebP. Финальная спецификация всего стандарта h265 будет принята уже в феврале.
      en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Main_Still_Picture
      Я был бы раз увидеть поддержку именно этого формата в Chrome и других браузерах.
      Причём это Main Profile, через несколько лет значит должен быть ещё более лучший High Profile.
      • 0
        Я так понимаю, что речь о сжатии с потерями, раз сравнивается с тем же JPEG. В таком случае интересно, какие настройки сжатия J2K использовали при тестировании (по сути выбор фильтра DWT и были ли применены доп действия, типа отсечения zero-trees или как оно там называется). Это я к тому, что DWT с потерями со всем наворотами позволяет сжимать очень и ОЧЕНЬ сильно, и как-то даже не верится что разница в десятки процентов.
  • +7
    В общем, много правильных вещей, но все равно ощущение, что текст написан в 1999-м году…
  • +6
    Существует проект JPGCrush (для *nix), который преобразует изображения из последовательного jpeg в прогрессивный, причем с высокой степенью сжатия, при этом он не изменяет качество изображения. Для работы необходим JPEGTran.
    Я его реализовал в своем проекте Image Catalyst (для Windows), также он есть в проекте ImageOptim (для OS X).

    Такой вопрос, а нет ли готовой версии PageSpeowed Optimization Libraries для windows?
  • +2
    Да Image Catalyst, вещь хорошая. Я все прогоняю, через нее.

    Кстати, не всегда лучше использовать прогрессивные. Самое не целевое использование — это конвертация подобного изображения в base64. Возможно, есть и другие случаи, если кто-то знает, то буду признателен, если озвучите.
    • +3
      Фотографии документов или чего-то подобного тоже не имеют плюсов в прогрессивности, так как прогрессивность всё равно не даст прочитать что-либо до загрузки достаточной чёткости, в то время как в линейном варианте их можно уже читать по мере загрузки. Это лишь один из примеров, который пришёл в голову первым.
      • +4
        Для текстов есть PNG.
        • +1
          Для печатных — да, но если это скан рукописного текста, на старой промасленной бумаге, то соотношение вес/качество наверняка будет лучше у jpg. Не всегда ж всё так категорично, зачастую приходится действовать по ситуации, а не по однозначным правилам типа «для текстов – png».
          • 0
            Действительно; я как-то не подумал о рукописях.
  • +1
    Я не понял, при чем здесь SPDY.
    Ссылка рассказывает также о mod_pagespeed
  • +1
    Opera (v 11.60) / мгновенно после загрузки файла (медленно) / мгновенно после загрузки файла (медленно)

    Ложь. В Опере при отображении в теге IMG картинка грузится прогрессивно.

    Можете проверить сами: madeira.cc.hokudai.ac.jp/RD/jovi/info96/html/progressive.html (картинка должна грузиться медленно)
    • +1
      Проверил. Действительно, загружается прогрессивно. Значит автор оригинального материала ошиблась.
      Поправил пост, спасибо.
    • 0
      Работает в 12.12/Linux. Может недавно появилось, статья то явно старая судя по представленному соотношению браузеров.
      • 0
        Я сейчас проверял на 10.60/Windows. Статья от 28 декабря 2012 года. Возможно, у автора 10.60 была под Mac'ом, это проверить не могу.
        • 0
          В 12.12 под маком тоже прогрессивно загружается, и так было даже на более старых версиях. Удивился, когда увидел «медленно».
          А вот в случае использования прогрессивной графики в качестве фона, действительно, грузится «медленно», отображаясь лишь по окончанию загрузки.
  • 0
    Мне тут мысль пришла после прочтения заголовка (надеялся, что об этом пост).

    Мысль следующая: известно, что изображения, уменьшенные через CSS заставляют тупить браузер (через атрибуты, судя по всему, тоже, но их никто не использует сегодня). Часто на сайте используется ряд миниатюр одного изображения, включая само изображение, например:
    1. Оригинальное загруженное, скажем, 1500 на 1500 пикс, открывающееся по ссылке
    2. Сжатое изображение, используемое на странице (фото товара, например) — 700 на 700
    3. Средняя миниатюра (скажем, выводится в списке товаров определенной категории) — 400 на 400
    4. Малая миниатюра (допустим, выводится в общем списке товаров и в «похожих» товарах) — 150 на 150

    Допустим, при генерации картинки, до загрузки, редактор сохранил оригинальную картинку с четырьмя слоями, примерно соответствующим размерам, описанным выше.

    Было бы очень неплохо, вместо серверной конвертации картинок в 4 формата, просто сообщать браузеру: «Дай картинку до третьего слоя» для вывода на странице товара или «дай только первый слой». При этом, если картинка до указанного слоя отсутствует в кеше, браузер запрашивает её, но прерывает загрузку когда будет получен нужный слой.

    В итоге получаем экономию трафика (грузить надо одну картинку, а не четыре) и экономию серверных ресурсов (не надо ничего уменьшать, по той же причине)

    В идеале, конечно, было бы круто указывать редактору, какими должны быть слои.
    • 0
      sprites?
    • 0
      Большинство jpg, png и других форматов имеют превью, мини-картинка в картинке, генерируемая графическим редактором. Некотрые форматы, например icns (иконки в маке) состоят из набора картинок разных размеров для соответствующего отображение в разных размерах, и могут весьма отличаться друг от друга.
      Чтобы это использовать со стороны клиента, браузеры должны сами вместо ресайза огромной картики считывать маленькую, но на это никто не пойдёт (стандарты, ожидания, прочее). Можно со стороны сервера уменьшить нагрузку, но это тоже такие крохи… Сервер мощный, он сожрёт ) В итоге всё так, как оно есть.
  • +1
    Название режет глаз. По-моему, гораздо лучше было бы: «Прогрессивный JPEG: лучшее решение»
    • +1
      Тогда уж «прогрессивный JPEG — теперь наилучшее решение», а не то «new» остаётся без перевода.
  • +2
    Благодарю за перевод этого текста, потому что я убеждён, что его кто-нибудь непременно должен был перевести и выложить на Хабрахабре (я даже сам собирался сделать это, если повезёт, завтра; так что Вы меня разгрузили).

    Текст очень полезен как практическое руководство, убеждающее веборазработчиков наконец взяться за ум и начать выкладывать JPEG в прогрессивном виде (для Chrome, для Firefox; как здесь выяснили — и для Opera; а если не в Windows XP — то и для IE). Время пришло.

    Сразу скажу, что текст этот начинает постепенно воздействовать и на браузеростроителей. Так, например, создатели Mozilla Firefox начали обдумывать возможность перехода на прогрессивное отображение фоновых иллюстраций, по примеру Chrome.
  • 0
    «Прогрессивный jpeg обычно на несколько килобайт меньше, чем его же последовательная версия» — странно, но у меня в 90% случаев наоборот — прогрессивный на 5-15% больше. Редактор Corel Paint Shop Pro, хотя вряд ли в нем причина.
    • 0
      В фотошопе обычно меньше. Jpegtran не пробовали? Тоже может уменьшить.
  • 0
    Загружаясь, изображения рвут страницу, расталкивая другие элементы вокруг и вызывая неуклюжую перерисовку (прим. перев.: от этого, конечно, можно избавиться определенной версткой

    А для чего тогда параметры height и width у тэга img?
    • +1
      И следующие слова:
      но тогда нужно хардкодить или ограничивать размеры картинок

      как раз относятся к явному заданию height и width у img или его контейнера.
      • 0
        Я решил. что под словом хардкодить подразумевается жесткое задание размеров каких-нибудь div-ов-контэйнеров. Явное заданию height и width вроде было обязательно по стандарту (хотя, вероятно я путаю с alt), да и хардкодингом я бы это не назвал: вместо задания вручную на этапе вёрстки можно подставлять эти параметры в процессе генерации страницы на сервере. При этом и генерировать-то придётся не так уж много: для подавляющего большинства картинок (как элементов вёрстки так и контэнта) размеры известны уже на этапе вёрстки.
        • +1
          Насколько я понимаю, спецификация не требует обязательного их задания. А установка их на сервере, или на клиенте, даже для статического контента в моем представлении явлется хардкодингом. Если вам придется поменять какую-нибудь картинку, то кроме изменения самого файла нужно будет еще и менять эти захардкоженные значения. А для динамического контента (фото, загружаемые пользователями / персоналом / контент-менеджерами) это и вообще проблема. Нужно будет при аплоаде и сохранении сохранять куда-то отдельно размеры файлов, чтобы потом при формировании страниц их указывать.
          В общем, это сделать можно, но это отдельная тема с отдельным геморроем, поэтому я и написал примечание в посте. Намного проще представляется решать эту проблему используя прогрессивный jpeg.
  • 0
    В PHP юзаю phpThumb для созданий превью — можно ли там задать прогрессивный тип изображения? Используется Image Magic или GD 2

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.