С точки зрения пропускной способности канала, изображения - обжоры. В среднем, они занимают наибольший (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 браузерами.
Поведение прогрессивных 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 прогрессивно, отрисовывают их сразу целиком после того, как загрузка изображения завершена, что, по сути, делает их менее прогрессивными. Они становятся медленнее, чем последовательные jpeg. Несмотря на то, что последовательная отрисовка не такая быстрая и плавная, как прогрессивная, она по крайней мере дает хоть что-то, пока мы ждем, и «тик, тик» является своего рода индикатором загрузки (хорошей вещью). Нельзя недооценивать уверенность, которую чувствуют пользователи видя, что что-то происходит.
Выбирая прогрессивный jpeg мы обеспечиваем большинству пользователей отличные впечатления и меньшинству - весьма значимому меньшинству - худшие впечатления. Но выбирать последовательный jpeg потому, что он больше подходит в меньшинстве просмотров - ужасный компромисс. Нужно предлагать пользователям лучшее и смотреть в будущее.
Убеждать стало бы проще, если бы можно было сказать, что прогрессивные jpeg всегда весят меньше, так что их и нужно всегда использовать. Стоян нам в этом помогает. Он говорит: «Еще одно наблюдение по поводу правила 10Кб: в тех случаях, когда вес последовательного jpeg меньше, он меньше с небольшой разницей. А когда меньше прогрессивный, то он обычно меньше намного. Так что говорить, что нужно всегда использовать прогрессивный и станет лучше - это нормально».
Как раз то, что и хотелось услышать! На каждом отдаваемом нами последовательном jpeg были упущены возможности в размере файла и воспринимаемой скорости загрузки. Выбор прогрессивного варианта беспроигрышен и всегда должен быть выбором по умолчанию. А уже когда все jpeg прогрессивны, если хочется дальше оптимизировать, то сэкономить можно будет считанные байты и только на самых маленьких изображениях.
Причиной того, что последовательные jpeg наиболее распространены в сети, является, без сомнения, то, что инструменты оптимизации изображений создают их по умолчанию. Однако, все просмотренные мною - Photoshop, Fireworks, ImageMagick, jpegtran - имеют возможность сохранения и в прогрессивном варианте. Таким образом, чтобы отдавать прогрессивные jpeg, нужно сознательно модифицировать свой процесс оптимизации изображений.
Например, Smushit может переводить последовательные jpeg в прогрессивные. Smushit, кстати, можно запускать из командной строки и интегрировать в процесс оптимизации изображений.
Как узнать, что ваши jpeg прогрессивные? Вот несколько способов идентификации типа jpeg:
Лишние вычисления - недостаток, но не камень преткновения. Предоставление фотографий на слабом аппаратном обеспечении - сложная задача вне зависимости от этого. Я в курсе дела, потому что пишу приложение-фотогалерею с бесконечным скроллингом и оно падает на iPad’e. При обработке большого количества изображений на мобильных платформах сложные задачи возникнут в любом случае.
Как видно в таблице, мобильный Safari не отрисовывает прогрессивные jpeg прогрессивно и вероятно потому, что они нагружают ЦПУ. Прогрессивый jpeg не является новым форматом изображений. Следовательно, осознанно и без причин не поддерживать прогрессивный jpeg - не вариант для браузеров, даже для мобильных. Будем надеяться, что скоро мобильные браузеры станут справляться с прогрессивным рендерингом, но причины текущего отсутствия поддержки имеют смысл. Очень обидно, потому что как раз на мобильных устройствах прирост скорости и экономия в размерах файлов, которые предоставляет прогрессивный jpeg, пришлись бы очень кстати. Выше было упомянуто, что он как бы является решением для адаптивных изображений на данный момент. На самом деле он мог бы быть таковым, но время еще не пришло.
Не все текущие браузеры реализуют прогрессивный рендеринг прогрессивных jpeg. Несмотря на это, те, что реализуют - действительно в выигрыше из-за этого. И к тому же, мы получаем экономию в размерах файлов. Сегодня это лучший вариант и стоит им пользоваться. Прогрессивный jpeg - это будущее, а не прошлое.
Теги: Добавить метки
Нарезной батон. Подходит к борщу на ужин
В Школе редакторов есть преподаватель - Николай Товеровский. Жена часто просит его купить хлеб к ужину . На этом примере он объясняет разницу между “делать” и “сделать”.
Ты можешь спасти мир по дороге в магазин, оказаться в Индии, найти последний уцелевший батон, отвоевать его у злобных инопланетян, но если в итоге он окажется чёрствым или плесневым, значит, ты не выполнил задание. Делал, но не сделал.
Метод прогрессивного джипега - это способ делать и сделать одновременно. Его автор, Артемий Лебедев, описал суть метода одной картинкой:
Картинка из параграфа 167 Ководства студии Артемия Лебедева
По Лебедеву , надо стремиться к тому, чтобы в любой момент времени задание было готово на 100%. Вопрос лишь в степени детализации. Если есть время и возможность - добивайся совершенства сколько тебе влезет. Не хватает ресурсов на доработку - не беда, задание уже выполнено, то есть сделано.
Метод зацепил, но я никак не могла найти ему применение. Борщ готовится постепенно, прогружаясь как обычный джипег, и есть его можно только при 100% готовности. Ворота во дворе не хотят открываться до тех пор, пока я не откидаю от них 100% снега. Собаку нужно помыть двумя шампунями, вытереть полотенцем, расчесать и на 100% высушить феном, - только тогда она становится чистой.
Я страдала, но не прекращала попытки. На моё счастье, началась учёба в Школе редакторов. Первое же практическое задание дало возможность попрактиковаться в методе прогрессивного джипега.
Задание из курса “Управление и результаты”. Надо нарисовать двух осьминожек. Ножки осьминожек - мои навыки. У одной осьминожки ножек немного и они коротенькие - это я сегодня. У второй ножек больше и они длиннее - это я через год.
Для вдохновения нам дали две картинки:
У осьминожки дизайнера короткие ножки-умения
Другое дело - осьминожка артдиректора. Даже взгляд изменился
Тут надо признаться, что у меня есть диплом художника-оформителя четвёртого разряда, но рисовать в компьютере я не умею. От слова вообще.
Чтобы прекратить панику и успокоиться, посмотрела мультик. Если есть 10 минут, гляньте, не пожалеете.
Потом пошла советоваться с дочерьми. Они у меня богини фотошопа и всё такое. Старшая посоветовала не париться, нарисовать на бумаге красками, потом сфотать да и всё. Младшая сказала: “Напиши, что надо, сколько щупалец, какой длины, я тебе нарисую”. Но я решила, что уже большая и должна делать свои уроки сама.
Первая стадия, 20%
Пошла в Гугл-документы и создала таблицу. Выписала в столбец все навыки, которые у меня есть, добавила к ним те, что хочу развить к концу года, придумала шкалу роста, раскрасила ячейки в разные цвета и получила осьминожку без головы. Потратила 30 минут.
Задание выполнено. Но степень проработки оставляет желать лучшего
Обрадовалась, загрузила в школьную папку “Результаты заданий” и съела кусок торта в награду.
Вторая стадия, 60%
Решила приделать осьминожке какую-никакую голову. Покопалась в инструментах Гугл-таблиц, нашла рисование. Стандартных фигур вполне хватило, чтобы у осьминожки появились голова, глаз и рот.
Это всё ещё таблица, но согласитесь, она похожа на осьминожку
Думала, что на этом закончу, но заботливый однокурсник написал, что лучше сделать скриншот. Скрин получился неряшливый, пришлось его почистить от лишних деталей. На весь этап потратила около часа.
Скриншот ещё больше похож на осьминожку
Третья стадия, 97%
Продолжаем начатый разговор об оптимизации изображений. Оптимизировать (сжимать) мы можем не только сторонние изображения, с которыми что-то сделали или те изображения авторами которых мы являемся, но и просто открывать их в Фотошоп с одной лишь целью - оптимизации.
Это могут быть, например, памятные фотографии с праздника или отдыха, которые мы хотим хранить на диске самого компьютера или съёмных носителях (флэш-накопители, жёсткие внешние диски).
Разговор об оптимизации ни в коем случае не является призывом, вернувшись из отпуска или каникул бросаться оптимизировать (сжимать) фотоснимки (графические данные). Но, может быть и есть смысл в том, чтобы эти самые снимки в процессе оптимизации поучаствовали. Разумно ли создавать и пополнять электронный фотоальбом фотографиями, размер которых при переводе в физические меры длины исчисляется метрами? В общем, давайте над этим поразмыслим, когда появится для этого настроение.
Фотошоп является программой, удовлетворяющей потребности в обработке и создании изображений различной степени сложности. В Фотошоп как и во многих других программах, да и в компьютерных программах вообще, многие процессы происходят самостоятельно. Но мы как пользователи можем вносить некоторые корректировки в эти самые процессы, что бесспорно удобно.
Итак, изображение в Фотошоп готово к сохранению в формате отличном от формата Фотошоп, то есть оптимизации. Если во вкладке «Файл» верхнего меню мы выберем опцию «Сохранить», то, допустим это наше творение, сохранится в формате PSD, то есть файл будет «фотошоповским». Но выбрав другую опцию, которая присутствует в подавляющем большинстве компьютерных программ и именуется «Сохранить как», то в этом случае у нас появляется возможность выбора, - каким типом файла быть нашему творению за пределами Фотошоп:
Сделав выбор из перечня типов, предлагаемого редактором, формат файла поименованный JPG, мы имеем возможность отрегулировать уровень сжатия (оптимизации) в специальном техническом окошке, которое появится в автоматическом режиме, стоит только выбрать этот самый формат (тип) JPG:
Это окошко откроется перед нами с уже установленными самим Фотошоп настройками. Мы можем, ничего не предпринимая, с ними согласиться нажатием кнопки «Ок». И при таких наших действиях мы можем «спать спокойно» (юмор), процедура оптимизации прошла успешно. А можем в процессе оптимизации и поучаствовать. Давайте увеличим масштаб видимости до 200%, закрыв предварительно открытое окошко регулировки уровня сжатия:
(Расположение кнопки выбора масштаба для версий CS4, CS5).
Теперь нам снова придётся пройти путь до появления окошка регулировки уровня сжатия (оптимизации). Если мы увидим для себя полезность оптимизации изображений, становясь при этом главными действующими лицами процесса (регулируем собственноручно), то в будущем масштабировать изображения будем в первую очередь с целью избежать повторных действий.
Изменение масштаба видимости было произведено для того, чтобы лучше видеть, что происходит с изображением, когда мы меняем настройки. Можем процент масштаба сделать ещё больше, а можем и вовсе этого не делать.
Итак, окно настроек перед глазами и мы можем преступать к сжатию изображения:
Для того чтобы видеть как меняется объём файла (изображения) нам нужно, щелчком левой кнопки мыши, поставить галочку в пустом квадратике рядом с надписью «Просмотр». После чего, всё теми же щелчками мыши, выбирать поочерёдно то одну то другую разновидность формата (Базовый стандартный, Базовый оптимизированный, Прогрессивный), дополнительно изменяя и количество шагов (3,4,5):
При всём том, что мы делаем, нам не следует забывать и о самом изображении. Ведь эти регулировки ради него. Поэтому мы не концентрируем всё своё внимание лишь на показателе объёма, а смотрим и на изменения, которые происходят с изображением.
Наши действия по выбору формата оптимизации (сжатия) могут быть дополнены изменением и других параметров изображения:
И опять у нас есть возможность на одном из нескольких параметров остановить свой выбор: Это может быть Низкий, Средний или Высокий, а может и Наилучший. Достаточно одного щелчка кнопкой мышки и варианты к нашим услугам. Мы можем и не раскрывать перечень вариантов, а просто подвигать ползунок - это будет тем же самым выбором из перечня вариантов параметра:
Следя за изменениями изображения и объёма файла, в то время, когда меняем параметры изображения и разновидность формата, мы прекращаем регулировку в тот момент, когда сочтём нужным. То есть тогда, когда по нашему мнению и объём файла достаточно уменьшился и видимой потери качества картинки не произошло. Ну и далее жмём кнопку «Ок», в этом же окошке.
Если откатиться в своих действиях назад и остановиться на том моменте, когда окошко регулировки уровня сжатия только открылось, и посмотреть на слои, то мы увидим, что они объединились в один общий слой, чего не происходит с многослойным изображением, остающимся файлом типа PSD.
Все файлы имеют свою кодировку (код) и именно по коду они и распознаются различными программами и операционными системами. То есть у файлов-изображений свой код, а у файлов-текстов свой, ну и так далее. Эти коды различными программами и операционными системами воспринимаются не одинаково, по этим самым причинам мы можем видеть незначительные отклонения в отображении значений параметров.
Например, мы сжали (оптимизировали) изображение и его объём в Фотошоп таков:
Оптимизированный файл JPG (изображение) я сохраню на рабочем столе компьютера. При наведении курсора на значок файла ОС Windows покажет несколько другое значение.
В последнее время часто встречаются статьи о том, как не показывать пользователям пустое место на странице, пока там не загрузилось изображение. Подобную технологию можно встретить на сайтах и в приложениях Medium и Facebook .
Когда я первый раз писал о загрузке изображений на Medium , мне было интересно реконструировать используемую этим ресурсом технологию. Я увидел её в действии, когда подключился к медленному интернету в самолёте. Первоначальная загрузка изображения с низкой детализацией и переход к конечному изображению после отложенной загрузки - отличная идея.
Быстрый рендеринг всегда лучше медленного. Главное — вывести на экран хоть что-то, пусть это и не готовый контент.
Но уверены ли мы в этом? Изучив комментарии на Reddit , я нашёл много интересных (в том числе и негативных) комментариев. Вот два из них:
«Кто и когда решил, что если показывать сначала картинку низкого качества, загрузка будет казаться более быстрой? По мне, так все эти эффекты только отвлекают и выглядят ужасно. Загрузка уж точно не кажется более быстрой. Я все равно не могу понять, что на изображении, пока оно не загрузилось, есть там размытая заглушка или нет».
-
dwb
,
Hacker
News
Я решил найти научные исследования, которые могли бы подтвердить или опровергнуть позитивное восприятие таких приёмов. Но я не смог найти ни одного, которое бы подтверждало, что размытые изображения повышают «субъективную» скорость загрузки. В этот момент я вспомнил о прогрессивном JPEG .
Уже давно существует встроенная в изображения «технология прогрессивной загрузки». Хороший пример - прогрессивный JPEG .
Прогрессивный JPEG часто называют одним из лучших форматов изображений. Особенно для сайтов, на которые заходит большое количество пользователей с медленным подключением. Энн Робсон написала пост в поддержку прогрессивного JPEG ещё пять лет назад, подытожив его преимущества:
«Изображения в прогрессивном JPEG лучше, потому что они быстрее. Субъективная скорость важнее, чем настоящая скорость . Даже если мы загрузим на сайт слишком много изображений, то с помощью прогрессивного JPEG можно отобразить намного больше информации».
Прогрессивный JPEG кодирует изображения, разбивая их на несколько сканов. Первый скан выводит изображение с низкой степенью детализации, которая повышается, когда загружаются дополнительные сканы. Альтернатива прогрессивному - «базовый » режим, когда изображение загружается последовательно сверху вниз.
Базовое кодирование JPEG — изображения
Прогрессивное кодирование JPEG — изображения
Кодировка JPEG позволяет создавать и свои собственные скрипты сканирования. С их помощью можно сделать изображения, закодированные в гибридном режиме , совмещающем в себе свойства прогрессивного и базового JPEG .
С точки зрения пользователя, методы прогрессивной загрузки, такие как Blur-up и SQIP , похожи на прогрессивный JPEG : сначала браузер показывает изображение с низкой детализацией, а после загрузки заменяет его оригинальным.
Что интересно, большинство JPEG-файлов используют базовый режим. Прогрессивные JPEG-изображения составляют максимум 7% от всех файлов JPEG . Если прогрессивная кодировка субъективно ускоряет загрузку, почему прогрессивный JPEG не получил большего распространения?
Мне удалось найти только одно исследование по теме, озаглавленное «Прогрессивный рендеринг изображений: добро или зло?»
«Однако, как и в случае с прогрессивным JPEG , подобный двухступенчатый рендеринг, в рамках которого размытое изображение внезапно становится резким, затрудняет восприятие. Поэтому мозгу приходится напрягаться, чтобы понять, что изображено на картинке».
Согласно результатам этого исследования, людям сложнее воспринимать прогрессивные JPEG , хотя на первый взгляд они и должны улучшать опыт пользователей.
Недавно я упомянул об этом исследовании в дискуссии, посвящённой LQIP («изображениям-заглушкам низкой детализации», от английского Low-Quality Image Placeholders ). Сразу в нескольких ответах прозвучали сомнения в научной строгости исследования :
Многие ставили под сомнение состоятельность этой работы. Она идёт вразрез со всеми общепринятыми представлениями о пользе прогрессивного рендеринга, и пока что никто не представил второго исследования с похожими результатами. Нужно больше данных.
Ограниченное и спорное исследование. Чтобы делать какие-либо выводы, нужны большие объёмы данных.
Получается, что на данный момент существует только одно исследование, и то воспринятое с изрядной долей скепсиса. Возникает вопрос: можно ли измерить субъективную скорость загрузки с помощью существующих инструментов?
Представим две следующих раскадровки, записанных с некого сайта:
Схема загрузки одного и того же сайта.
Пользователь субъективно воспринимает версию B как загружающуюся быстрее, чем версия A . Это происходит из-за того, что отдельные части страницы в версии B загружаются быстрее, чем в версии А.
В некотором роде это похоже на ситуацию с прогрессивными изображениями, только в более крупном масштабе - загрузить контент как можно быстрее, пусть и неокончательную его версию.
Чтобы оценить, как быстро загружается страница, сегодня используются такие показатели, как индекс скорости (Speed Index ). Он измеряет процент того, насколько визуально закончена загрузка страницы. Чем ниже результат, тем лучше:
Формула индекса скорости
Изначально Speed Index измерял прогресс, сравнивая изменения в гистограммах каждого из основных цветов (красного, зелёного и синего ). Этот метод называется «средняя разница гистограмм ». Он помогает избежать ошибок, когда все элементы страницы могут одновременно сдвигаться на несколько пикселей в процессе загрузки. Подробно ознакомиться с работой алгоритма Speed Index можно в разделе документации, посвящённом измерению визуального прогресса .
Я решил испытать, как работает с заглушками низкой детализации тест WebPagetest :
Раскадровка, демонстрирующая степень визуальной завершённости в процентах.
Мы видим, что изображение загружается между 8 и 10 секундами. Размытая заглушка увеличивает процент завершённости с 75 до 83. Загрузка окончательной версии изображения доводит эту цифру до 93%.
Получается, что, согласно алгоритму Speed Index , заглушка вносит свой вклад в визуальную завершённость страницы. Видно и то, что заглушка не воспринимается как завершённая зона.
Speed Index - не единственный способ измерения скорости рендеринга страницы. В инструментах разработчика Chrome есть возможность запустить проверку производительности. Зайдите в меню Audits → Perform an audit → Run audit .
После выполнения проверка выдаёт вот такой отчёт:
Обратите внимание на размытую заглушку, которая затем превращается в финальное изображение.
Один из показателей проверки называется “Perceptual Speed Index ” («Субъективный индекс скорости ») и показывает значение 4,245. Что он означает? Возможно, это то же самое, что и Speed Index из теста WebPagetest ?
Подход Speed Index с измерением схожести пикселей (та самая «средняя разница гистограмм ») имеет свои недостатки. К примеру, он не учитывает визуальную схожесть фигур, цветов и объектов.
Четыре разных фигуры с одинаковым количеством чёрных и белых пикселей.
В большинстве случаев это не сильно повлияет на оценку визуальной завершённости - на практике Speed Index и Perceptual Speed Index в значительной степени совпадают.
«В ходе масштабных исследований (с использованием собранных WebPagetest видеозаписей более чем 500 страниц из мобильного рейтинга Alexa ) мы увидели, что SI и PSI демонстрируют линейную корреляцию с коэффициентом 0,91», - Измерение скорости загрузки видимой части страницы при помощи P erceptual Speed Index (PSI )
В документации к инструментам Google Lighthouse сказано, что PSI измеряется при помощи модуля Speedline . Он рассчитывает субъективный индекс скорости исходя из тех же принципов, что и обычный индекс скорости. Но при этом учитывает видимый прогресс загрузки, используя SSIM , а не разницу гистограмм.
SSIM («структурное сходство », от английского Structural Similarity ) используется для измерения сходства двух изображений. Этот метод моделирует восприятие изображений человеческим глазом и учитывает, насколько похожи фигуры, цвета и объекты. Но на этом применение SSIM не ограничивается. Интересно использование структурного сходства при оптимизации сжатия изображений. Например, кодировка cjpeg-dssim использует максимальную степень сжатия jpeg и создаёт изображение с SSIM , близким к оригинальному.
В примере, приведенном ниже, показаны SVG-изображения , созданные в Primitive и проверенные в Image SSIM JS . Чем больше фигур мы используем, тем ближе оценка к изначальному изображению, где SSIM = 1 .
От автора: прогрессивные изображения на HTTP2 быстрее отрисовываются на экране, что повышает восприятие производительности. Используйте сканирующие слои JPEG изображений для показа понятного контента при отправке всего лишь 25% от самого изображения. Для максимального увеличения производительности ключевых изображений используйте HTTP2 Server Push для сканирующих слоев JPEG.
Изображения очень важны: они завлекают нас, бесят, побуждают к чему-либо. Интернет в известной нам форме зависит от изображений. Изображения составляют ~65% от общего веса страницы, а также они сильно связаны со временем загрузки страницы и индексом скорости. Если коротко, изображения очень тяжелые и все замедляют.
Сжатие – лучший способ исправления отрицательного эффекта от загрузки изображений. С помощью сервисов типа ImageOptim от Kornel Lesiński, который использует замечательные библиотеки mozjpeg и pngquant, можно уменьшить вес изображений без визуальных потерь качества. Благодаря библиотекам типа DSSIM мы можем тестировать качество изображений на разных уровнях сжатия.
Плохая новость заключается в том, что даже после сжатия изображений в среднем на ~29% с помощью описанных выше инструментов, а также при использовании других форматов типа WebP, изображения все равно остаются самыми большими файлами на сайте. Ближайший собрат в этом отношении – JS. Нужно найти способ, как быстрее поставлять эти компоненты, чтобы быстрее завлекать пользователя.
Частично вопрос производительности решается с помощью HTTP2. Одно из главных преимуществ данного протокола – многоканальная передача – способность обрабатывать несколько запросов и ответов за раз, используя одно TCP соединение.
Многоканальная передача ускоряет загрузку файлов с сайта. В зависимости от структуры сайта можно выставить приоритет ресурсов при многоканальной передаче: если критическому CSS поставить высокий приоритет, он будет загружаться быстрее через HTTP2. Кроме того, подгружая еще не запрошенные файлы через HTTP2 Server Push, при правильном подходе можно серьезно улучшить восприятие производительности. Более подробно на эту тему чуть ниже.
При загрузке изображений через многоканальную передачу данных появляется интересный побочный эффект: с точки зрения восприятия производительности отдельные типы изображений загружаются значительно быстрее из-за того, что первичная информация об изображении загружается параллельно через многоканальную передачу данных HTTP2. К таким типам можно отнести прогрессивный JPEG и чересстрочный PNG.
Прогрессивные и чересстрочные изображения похожи на слоеный пирог: информация в них хранится не в едином потоке, который отрисовывает изображения от верхнего левого угла до правого нижнего, а в форме стека, где каждый слой дополняет уже предоставленную ранее информацию. Отдельные слои весят намного меньше конечного файла.
Загрузка файлов с сайта через HTTP2 Multiplexing начинается одновременно, и первичные, легковесные слои прогрессивных и чересстрочных изображений начнут отрисовываться намного быстрее, чем последовательно закодированные изображения. Последовательно закодированные изображения отрисовываются наподобие жалюзи: стока за строкой, пока не загрузится все изображение.
Джон Меллор из Google в 2012 году уже говорил о восприятии производительности и индексе скорости при загрузке сканирующих слоев прогрессивных JPEG изображений через HTTP2 Multiplexing. Он экспериментировал с протоколом SPDY, предшественником HTTP2. Сегодня мы можем продвинуть еще дальше его открытие и заставить прогрессивные изображения загружаться еще быстрее.
По умолчанию в прогрессивных JPEG изображениях 10 сканирующих слоев. То есть для загрузки изображения с исходным качеством проходит 10 итераций с загрузкой слоев с информацией. Первый слой JPEG изображений всегда имеет высокую пикселизацию и зачастую выполнен в черно-белом варианте для экономии на цветовых каналах. Хотите узнать, как выглядят все слои? Воспользуйтесь инструментом jsk от Frédéric Kayser, в котором прогрессивное изображение можно разбить на отдельные слои.
Почему именно 10 слоев? Это значение по умолчанию во всех стандартных кодировках JPEG. Так достигается идеальный баланс между размером каждого слоя и качеством, а также данное значение помогает достичь наименьшего веса конечного файла путем оптимизации через таблицы Хаффмана .
Современные тенденции и подходы в веб-разработке
Узнайте алгоритм быстрого роста с нуля в сайтостроении
В отличие от PNG изображений, где для создания черессточных слоев используется фиксированный метод кодировки Adam7, JPEG кодировки можно расширить директивами: флаг «-scans» для кодировок JPEG. С mozjpeg флаги можно использовать следующим образом: «cjpeg -quality 75 -scans customscans.txt -outfile output.jpg input.jpg». Кодеры JPEG принимают текстовые файлы с вашими командами для создания слоев.
Каждая строка в сканирующих файлах задает новый сканирующий слой. Каждый слой хранит много информации о цветовом канале, индексе матрицы и потерях.
В сканирующем файле есть три канала – яркость (Y), синий (Cb) и красный (Cr) под номерами 0, 1 и 2 соответственно. Индекс матрицы в файле начинается с 0 и идет до 63, покрывая блок в 64 пикселя (кодировка JPEG имеет блок 8х8).
Наша цель – как можно быстрее показать осмысленное изображение, чтобы наш сайт отрисовывался быстрее. Наш первый сканирующий слой должен быть легким, но в то же время осмысленным, что приведет к резкому скачку восприятия производительности визуального качества.
Первый представленный слой в сканирующем файле обеспечивает нас подходящими цветами. Второй слой – это уже приемлемое превью изображения. На третьем и четвертом слое находится необходимая информация о цвете: красный канал расположен перед синим, так как красный канал намного важнее для повышения визуального качества, например, при показывании лиц. Последний пятый слой дает нам конечное изображение с прорисовкой мелких деталей. Эти улучшения выливаются в примерный рост индекса скорости на 6%, что в свою очередь влияет на восприятие производительности.
Скрипт сканирования выше – лишь один пример настройки кодировки прогрессивных JPEG изображений: используя этот подход, можно воссоздать технику LQIP от Guy Podjarny в прогрессивных изображениях JPEG, как показал Jon Sneyers.
Для еще более быстрой загрузки изображений в HTTP есть еще один инструмент — Server Push. На серверах с поддержкой HTTP2 есть возможность помечать отдельные слои прогрессивных JPEG изображений высоким приоритетом, что заставит сервер передать эти слои в Push-кэш браузера пользователя еще до самого запроса на изображение. Браузеры могут выстраивать структуру страницы и отрисовывать первичные слои изображения из кэша, ускоряя тем самым для пользователей воспринимаемую отрисовку изображений.
Более подробно изучить HTTP2 Server Push можно в замечательной статье в разделе Performance Advent Calendar .
Данную технику стоит использовать только для выстраивания стратегии: выясните, какие изображения в первую очередь влияют на привлечение пользователей на странице, например, баннеры, пробуждающие определенные эмоции, или изображения с обзором на товар, и используйте Server Push для загрузки первичных слоев этих JPEG изображений. Так вы привлечете пользователей, что выльется в повышение конверсии без ущерба общей загрузки сайта.
Благодаря многоканальной передаче через HTTP2, прогрессивные и чересстрочные изображения отрисовываются гораздо быстрее.
Управление созданием прогрессивных JPEG изображений может дать пользователю лучший визуальный опыт.
HTTP2 Server Push может улучшить восприятие производительности важных изображений.
