Перевод статьи State of the Web: Top Image Optimization Strategies с сайта dougsillars.com для css-live.ru, с разрешения автора — Дага Силларса

Изображения — ключевая часть веба. Красивые образы так и манят посетителя всё глубже в историю, которую пытается донести ваша страница — будь то новости, развлечения или электронная коммерция. Но при всей важности картинок, их большой размер может (потенциально) замедлить загрузку страниц, и пользователи в итоге просто уйдут с сайта. На самом деле, HTTP-архив показывает, что средний мобильный сайт на ~50% состоит из картинок (по объему в килобайтах).

На протяжении нескольких лет этот процент был относительно постоянным, но тем не менее сайты увеличиваются, а значит, размер изображений — тоже. Фактически, по сравнению с предыдущим годом видно, что изображения на мобильных устройствах увеличились в размере на 8%, хотя их число уменьшилось на 2.6%.

(верхний ряд — медианное значение общего размера изображений на десктопных и мобильных страницах, нижний ряд — медианное число запросов к изображениям на десктопных и мобильных страницах соответственно, стрелки вверх/вниз и проценты под каждым значением показывают увеличение/уменьшение по сравнению с прошлым годом)

Это означает, что изображения на мобильных сайтах со временем становятся больше.

Каким образом можно уменьшить размер изображения?

Есть множество стратегий оптимизации изображений, помогающих ускорить их загрузку так, чтобы качество не пострадало (подробную справку можно найти в замечательном «Руководстве по основам оптимизации изображений» Эдди Османи:  https://images.guide/). В этой статье я сфокусируюсь на четырёх стратегиях оптимизации: ленивая загрузка (англ. Lazy Loading, сокращенно LL), оптимизация изображений (англ. Image Optimization,  сокращенно IO), отзывчивые изображения (англ. Responsive Images,  сокращенно RI) и формат изображений (англ. Image Format, сокращенно IF). Не удивительно, что все эти четыре лучшие практики включены в сервис для проверки сайтов Lighthouse от Chrome, и эти проверки доступны в HTTP-архиве — дающем нам подробные сведения об этих оптимизациях.

Определения Lighthouse

При виде данных важно понимать, что они означают на самом деле. Тесты проверяют:

• Ленивая загрузка (LL): Lighthouse определяет изображения, которые находятся «вне экрана». Если эти изображения загрузились до начала интерактивности страницы, тест считается проваленным. Тест успешен, если изображения вне экрана запрашиваются прежде чем страница станет интерактивной. Если отложить загрузку изображений, то страница быстрее станет интерактивной.
• Оптимизация изображений (IO): Проверяет все JPEG-картинки (и только JPEG) на странице, меньше ли их качество 85% или нет. Если изображения укладываются в 85%, то тест успешен. Google предлагает 85% в виде хорошего компромисса качества изображения и его размера.
• Отзывчивые изображения (RI): Lighthouse вычисляет размер отрисованного изображения, сравнивая его с загруженным. Если изображение на экране более чем на 25 Кб «легче», чем загруженное, тест считается проваленным. Цель здесь — чтобы размер изображений подходил тому устройству, которое запрашивает файлы (никаких огромных картинок для больших ретиновых мониторов на маленьком смартфоне)
• Формат изображения (IF): Lighthouse проверяет, сэкономит ли формат следующего поколения (JPEG2000, WebP) более 8 Кб на любом из данных изображений. Поскольку все мобильные тесты в HTTP-Archive запускаются на эмуляции Chrome, выбранным форматом будет WebP.

Сбор данных

HTTP-архив собирает результаты WebPageTest для 500 000 самых популярных сайтов раз в две недели, включая данные Lighthouse (по мобильным запускам). Можно запросить эту информацию с помощью BigQuery и приступить к анализу.

SELECT
url,
integer(JSON_EXTRACT(report, “$.audits.offscreen-images.score”)) offscreenScore,
integer(JSON_EXTRACT(report, “$.audits.offscreen-images.extendedInfo.value.wastedMs”)) wastedms,
integer(JSON_EXTRACT(report, “$.audits.offscreen-images.extendedInfo.value.wastedKb”)) wastedkb,
JSON_EXTRACT(report, “$.audits.offscreen-images.extendedInfo.value.results”) wastedresults,
integer(JSON_EXTRACT(report, “$.audits.uses-optimized-images.score”)) optimagesScore,
integer(JSON_EXTRACT(report, “$.audits.uses-optimized-images.extendedInfo.value.wastedMs”)) optimgwastedms,
integer(JSON_EXTRACT(report, “$.audits.uses-optimized-images.extendedInfo.value.wastedKb”)) optimgwastedkb,
JSON_EXTRACT(report, “$.audits.uses-optimized-images.extendedInfo.value.results”) optimgwastedresults,
integer(JSON_EXTRACT(report, “$.audits.uses-responsive-images.score”)) repimagesScore,
integer(JSON_EXTRACT(report, “$.audits.uses-responsive-images.extendedInfo.value.wastedMs”)) respimgwastedms,
integer(JSON_EXTRACT(report, “$.audits.uses-responsive-images.extendedInfo.value.wastedKb”)) respimgwastedkb,
JSON_EXTRACT(report, “$.audits.uses-responsive-images.extendedInfo.value.results”) respimgwastedresults,
integer(JSON_EXTRACT(report, “$.audits.uses-webp-images.score”)) webpimagesScore,
integer(JSON_EXTRACT(report, “$.audits.uses-webp-images.extendedInfo.value.wastedMs”)) webpimgwastedms,
integer(JSON_EXTRACT(report, “$.audits.uses-webp-images.extendedInfo.value.wastedKb”)) webpimgwastedkb,
JSON_EXTRACT(report, “$.audits.uses-webp-images.extendedInfo.value.results”) webpimgwastedresults,

FROM
[httparchive:lighthouse.2018_03_15_mobile]

А теперь разберём смысл этих строк:

integer(JSON_EXTRACT(report, “$.audits.offscreen-images.score”)) offscreenScore

Поскольку в колонке ‘report’ («отчёт») данные в JSON-формате, результаты все будут строками. Поскольку нам нужно работать  с результатами в виде чисел, я обернул параметр integer(), чтобы привести их к значениям. JSON_EXTRACT берёт отчет и извлекает атрибут вложенного элемента ‘audits -> offscreen-images -> score’

Примечание: запуск этого запроса расходует 131 Гб из вашего месячного лимита бесплатных запросов в 1 Тб. Пол Кальвано сделал несколько тестовых выборок меньшего размера, на которых можно оптимизировать запросы, прежде чем «натравливать» их на большие объемы данных. Сразу после оптимизации запроса сохраните его в таблице, чтобы можно было уточнить и запустить ещё запросы, не выбиваясь за ваш лимит BigQuery. Моя таблица весила 5.8 Кб — намного меньший размер выборки, чтобы гонять на ней запросы.

Оптимизации изображений

Каждая из этих четырех оптимизаций оценивается, возможные оценки 0 (плохо), 65 (средне), 90 и 100 (хорошо). Результат каждой проверки можно узнать отдельно.

Интересно отметить, что для всех проверок свыше 75% сайтов получают оценку либо 0, либо 100. Также ясно, что оптимизированные изображения (43% получили оценку 100) и отзывчивые изображения (57% получили оценку 100) применяются гораздо чаще ленивой загрузки (22%) или формата изображения (16%).

У 70% сайтов (310 тыс.) есть хотя бы одна оптимизация изображений с оценкой 100. Это значит, что (к сожалению) у 30% (130 тыс.) нет ни одной оценки 100.

Какова цена ошибки?

В отчёте Lighthouse цена каждой ошибки оценивается двумя метриками: затраты в Кб (избыточные данные, отправленные по сети) и миллисекунды (затраты на загрузку ресурса в сравнении с оптимизированной версией). Ограничившись сайтами, провалившими (с оценкой 0) каждую из проверок, рассчитаем для них медианные значения возможного улучшения:

Эти улучшения поистине впечатляют!. На этой диаграмме видно, что типичное ускорение для 3G-сети будет между 2.7 и 4.1 с. Конечно, на более медленных сетях улучшение скорости будет гораздо заметнее (экономия Кб будет одинакова в любых сетях).

Распределение оптимизаций

Оптимизации изображений для вашего сайта могут суммироваться, что означает, что реализация более одной оптимизации приведёт к большей экономии. Можно узнать количество сайтов, применивших множественные оптимизации (и получивших 100 для каждой оптимизации).

30% веба проходят ноль тестов для изображений из четырех. Свыше 70% веба проваливают проверку двух или более тестов (с оценкой 100 лишь в 2 и менее тестах).

Можно увидеть разбивку этих тестов по типам:

Доли сайтов со 100 баллами по видам проверок Lighthouse

Из сайтов с оптимизациями самые частые пересечения — это оптимизированные и отзывчивые изображения (с ленивой загрузкой и WebP или без них). Интересно, что самый популярный сектор этой диаграммы — 21% сайтов, прошедшие только проверку на отзывчивые изображения. Может это из-за стремления делать сайты с подходом «сначала мобильные»?

Вторыми по популярности идут отзывчивые и оптимизированные (11%), за которыми следуют оптимизированные изображения (только). На эти три сектора приходится > 40% мобильного веба. Следующая наиболее распространённая реализация — прохождение всех четырех проверок с 8%.

Это вытекает из диаграммы выше, показывающей, что отзывчивые и оптимизированные — самые распространенные, а ленивая загрузка и формат изображений используются нечасто. Также на ней видно, что ленивая загрузка и подбор формата изображения в основном оказываются 3-й или 4-й оптимизацией (в пересечениях нескольких секторов), что указывает, что это добавочные оптимизации, которые делают в последнюю очередь.

Сайты с множественными оптимизациями

Данные в HTTP-архиве позволяют рассчитать типичный потенциал экономии на основании количества пройденных тестов.

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

Объединяя данные из двух предыдущих разделов, получаем:

(прим. перев.: passcount — количество пройденных проверок Lighthouse, medianKB — медианное значение потенциальной экономии трафика, medianms — медианное значение потенциального ускорения)

31% веба не проходит все четыре теста изображений в Lighthouse. Исправление этих ошибок может дать возможность ускорить эти сайты на 7 секунд (и 1.1 Мб) за счёт оптимизации изображений. Свыше 70% веба не проходят 2 или более теста, что указывает на возможность ускорения как минимум на 1.3 с (и экономии свыше 168 Кб).

Сравнение с фактическим временем загрузки

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

(прим. перев.: столбцы таблицы — количество пройденных проверок Lighthouse, процент сайтов, прошедших столько тестов, и медианные значения возможного выигрыша во времени полной загрузки, «весе» изображений и «весе» всей страницы соответственно)

Эта таблица показывает, на сколько процентов улучшится время загрузки и вес страниц в Кб для сайтов, проходящих разное число проверок Lighthouse. Например, у сайта, «провалившего» все четыре проверки (это 31,23% от всех сайтов) медианное ускорение загрузки составит 26%, а уменьшение «веса» картинок — ~60%. Для сайтов, прошедших три проверки (которым осталось исправить всего одну недоработку), медианное ускорение загрузки составит 2,5%, а уменьшение размера картинок — 25%.

Можете также сравнить время загрузки сайтов, прошедших все четыре проверки (8% веба) с сайтами, которые их все «провалили» (10% сайтов).

(прим. перев.: первая строка таблицы — сайты с 4 проверками на 100 баллов, вторая — сайты с 4 проверками на 0 баллов. Столбцы таблицы: количество сайтов, медианный размер страницы в Кб, медианный «вес» изображений в Кб, медианное время полной загрузки в секундах)

Тут сравнение может быть не совсем честным, поскольку, как мы видим, сайты с четырьмя пройденными тестами весьма легковесные, а сайты, «провалившие» все проверки, огромны (страницы по 4,3 Мб на мобильнике!). Однако, медианное время загрузки сайта со всеми рекомендованным оптимизациями на 30 секунд (!?!) быстрее, чем медианное время загрузки сайта, не прошедшего ни одной проверки.

Заключение

Изображения занимают львиную долю времени загрузки и трафика в мобильном вебе. Lighthouse проверяет 4 лучших практики для изображений, и только 8% проходят все из них (и 10.4% не проходят все 4!). Медианные значения экономии от этих оптимизаций составляют от 2.7-4.1 секунд и 400-600 Кб трафика. Чем больше оптимизаций, тем сайты быстрее и тем меньше данных им нужно.

Когда важна каждая (милли-) секунда, ясно, что оптимизация изображений — крайне эффективный способ ускорить сайт, и его можно использовать гораздо лучше.

Чтобы протестировать свой сайт в Lighthouse, используйте WebPageTest или инструменты разработчика в Chrome. Узнайте, где окажется ваш сайт на этой шкале!

Спасибо Рику Вискоми за вычитку и отличные комментарии.

P.S. Это тоже может быть интересно:

• Псевдокласс :has() — не только «родительский селектор»
• CSS-выражения от контейнера для дизайнеров
• Каскадные слои уже почти стандарт!