От автора: прочитайте любой блог о производительности или посетите любой доклад о производительности, и все посоветуют вам, что оптимизация изображений — это лучшее место для начала. Используя автоматизированные сервисы, вы можете получить изображения меньшего размера за относительно короткий промежуток времени. И все мы знаем, что меньшие изображения дадут нам лучшую производительность — или нет?
Потратив последние пару лет на ситуации, когда клиенты стремятся оптимизировать изображения, но затем не видят изменений в производительности, я решил поделиться несколькими примерами того, как лучше всего справиться с проблемой, если это произойдет с вами.
Оптимизация фотографий — это все равно что покупать быструю машину: если у вас нет хороших чистых дорог для движения, вы не доберетесь куда-нибудь быстрее. Часто остальная часть веб-сайта похожа на заброшенную автомагистраль, и выгода от дополнительной мощности уходит впустую. Ниже приведены несколько советов о том, как очистить трафик.
Случай 1
Логотипы и меню компании были размыты для защиты конфиденциальности этих субъектов
На вышеупомянутом веб-сайте количество байтов изображений было уменьшено с 1 МБ до 500 КБ (50%), но в производительности не было никаких изменений.
При углубленном изучении этого сайта выяснилось, что основная проблема заключалась в том, что почти все изображения на сайте загружались с использованием JavaScript.
Удаление отложенной загрузки для основного изображения товара стало серьезным улучшением. Хотя я не могу точно вспомнить, что было сделано с оставшимися изображениями, я всегда предлагал бы проверить, присутствуют ли они на экране во время начальной загрузки, а если нет, подумать об отложенной загрузке, будь то использование JS или встроенная отложенная загрузка.
Мы также отложили один или два скрипта и предварительно загрузили некоторые шрифты для этого сайта, улучшенные результаты показаны ниже.
Случай 2
Результаты вышеприведенного проекта по оптимизации изображений были не такими уж плохими:
Изображения уменьшены с 2,4 МБ до 1 МБ (на 55% меньше)
Визуально производительность улучшилась на 2 секунды
Однако при первом обращении клиент сказал нам, что производительность и пользовательский опыт недостаточно улучшились. Из вышеприведенной диаграммы видно, что основной шаблон рендеринга был похожим до и после. Пустая темная область отображается через 2 секунды (как показано ниже), а затем сдвигается вниз, когда 2 основных изображения начали загружаться через 3 секунды.
Посмотрев более подробно этот сайт, мы обнаружили, что всплывающее меню содержало скрытые изображения на каждой вкладке меню, и все они загружались в верхней части страницы с самым высоким приоритетом.
Отложенная загрузка этих скрытых изображений, а также некоторая реорганизация CSS и JavaScript в заголовке страницы позволили загружать основные изображения раньше и улучшить взаимодействие с пользователем. Основные изображения теперь начинают загружаться на целую секунду быстрее, и темно-серое пространство больше не отображается в области просмотра.
Несмотря на все вышеперечисленные оптимизации и некоторую предварительную загрузку шрифта, начальное время рендеринга, по-видимому, было замерло где-то на отметке в 1,5 секунды. Этот клиент использовал Optimizely, который откладывал рендеринг. Удаление Optimizely сократило время до начала рендеринга до менее, чем 1 секунды. Я не собираюсь рассуждать на темы, правильно ли или неправильно использовать инструменты A / B-тестирования на стороне клиента, это совсем другой вопрос. Я скажу, что если вы тщательно измеряете эффект от оптимизации чего-либо такого большого, как изображения, убедитесь, что вам известны все технологии, влияющие на результат, а затем решите, хотите ли вы включить или выключить их во время тестирования.
Случай 3
На первый взгляд этот сайт выглядит потрясающе, как подтверждают следующие статистические данные:
~ 5 МБ изображений уменьшено до ~ 400 КБ (сокращение на 92%)
Полное отображение от 7 до 4 секунд
Время до начала рендеринга сокращено на 2 секунды
Несмотря на эти улучшения, первое отображение hero-изображения осталось относительно неизменным. Копая глубже, мы обнаружили, что hero-изображение было загружено как фоновое изображение, что задерживало его загрузку. Замена этого на элемент <img/> улучшило время рендеринга, и оно стало соответствовать приведенным ниже показателям.
Мы также нашли пару скриптов, которые были загружены в нижней части разметки, предназначенной исторически для последней загрузки. Предварительный парсер браузера обрабатывал их и загружал перед изображениями, поэтому мы добавили в скрипты defer.
Дальнейший анализ
Проработав описанные выше и другие подобные кейсы, я подумал, есть ли какие-либо высокоуровневые шаблоны, которые мы могли бы использовать для прогнозирования этой проблемы, возникающей до оптимизации изображений.
Я просмотрел более 20 сайтов клиентов, на которых мы недавно оптимизировали изображения, пропустил их через webpagetest.org и оценил по процентному улучшению SpeedIndex. Они были разделены по 16 наборам критериев, сгруппированных по статистике страниц, статистике изображений, статистике JavaScript и методам загрузки. Критерии включали такие вещи, как:
Процент байтов изображения на странице
Процент изображений по сравнению с JavaScript
Фактические байты изображения
Были ли изображения размещены на одном домене
Использовалось ли A / B-тестирование
После оценки сайтов по 16 критериям оказалось, что скорее всего показатель SpeedIndex значительно улучшится, если ваш сайт придерживается следующих бюджетов:
43% или более от общего количества объектов страницы — изображения
Менее 30 TCP-соединений (например, не слишком много сторонних ресурсов)
Меньше 400 КБ JavaScript
JavaScript составляет менее 45% байтов от размера изображений
После оптимизации изображений экономится не менее 50% байтов ИЛИ не менее 1 МБ *
* Этот критерий необходимо будет измерить после оптимизации изображений, однако WebPageTest показывает некоторую потенциальную экономию при анализе всех изображений.
Если ваш сайт не соответствует двум или более из этих критериев, я бы посоветовал вам взяться за другие узкие места производительности, которые необходимо исправить, прежде чем приступать к работе с изображениями.
Заключение
Я люблю оптимизировать изображения, думаю, это один из самых простых для оптимизации аспектов. Однако, прежде чем оптимизировать изображения, вы должны иметь реалистичные ожидания относительно того, чего вы хотите достичь. Оптимизация производительности — это больше, чем сокращение количества байтов. Есть много аспектов скорости загрузки веб-страницы, и часто устранение одного узкого места просто выявляет другое.
При разработке проекта оптимизации изображений я рекомендую следующее:
Четко определять, как вы измеряете воздействие
Выберите визуальную метрику (Speedindex, Отображение основного контента и т. д.)
Используйте правильный инструмент, WPT хорош для выборочных проверок и отладки, RUM понадобится, чтобы увидеть влияние в реальной среде.
Проверьте соответствие критериям, приведенным выше, если ваш сайт не соответствует этим требованиям, правильно установите ожидания
Убедитесь, что изображения в окне просмотра загружаются как можно быстрее
Правильно управляйте отложенной загрузкой
Используйте теги (включая адаптивные изображения), а не фоновые изображения CSS
Отложите любые скрипты для загрузки после критических изображений
Подумайте о роли инструментов A/B-тестирования во время вашей оценки
Автор: Michael Gooding
Источник: https://calendar.perfplanet.com
Редакция: Команда webformyself.