Как оптимизировать изображения для сайта: WebP, размеры, сжатие и lazy loading

Часть 4 из 6 · Серия «Скорость сайта без магии»

В третьей части мы разобрали, что LCP отмечает появление самого крупного элемента на экране. В подавляющем большинстве случаев этот элемент — картинка: фотография товара, баннер на главной, обложка статьи.

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

Рычагов всего четыре:

1. размеры     — не грузить больше, чем показываем
2. формат      — хранить эффективнее
3. сжатие      — убрать лишние килобайты
4. очерёдность — грузить нужное раньше ненужного

Разберём каждый и закончим правилом, которое чаще всего нарушают: почему отложенную загрузку нельзя включать для главной картинки первого экрана.

Рычаг 1. Размеры: самый частый и самый крупный выигрыш

Начинать нужно не с формата и не с плагинов, а со скучного вопроса: какого размера файл и в каком размере он показывается?

Типичная картина на сайтах, куда фотографии загружает не разработчик:

Файл:     3800 × 2500 пикселей, 1,8 МБ
Показан:  600 × 395 пикселей
Итог:     браузер скачал в разы больше, чем нужно,
          распаковал и уменьшил — за счёт посетителя

Никакой WebP не спасёт картинку, которая в шесть раз шире своего места. Сначала приведите габариты в порядок, и только потом занимайтесь форматом и сжатием.

Практическое правило: изображение должно быть примерно вдвое больше того места, где показывается, — запас нужен для экранов с высокой плотностью пикселей. Картинка в блоке шириной 600 пикселей вполне живёт в файле 1200 пикселей, а не 3800.

Если места разные на телефоне и на компьютере, современный способ — отдать браузеру набор вариантов через атрибут srcset и позволить ему выбрать подходящий. Большинство CMS и конструкторов делают это самостоятельно: WordPress создаёт несколько размеров при загрузке, конструкторы вроде Tilda отдают свои варианты автоматически. Проверить, работает ли это у вас, проще всего по отчёту о скорости: там видно, какой файл реально скачал браузер.

Рычаг 2. Формат: чем WebP полезен для сайта

Старые форматы хранят изображение расточительно. Современные — эффективнее, при сопоставимом на глаз качестве.

• WebP — рабочий выбор по умолчанию. Поддерживается всеми актуальными браузерами, умеет и фотографии, и прозрачность, и анимацию. Именно WebP для сайта обычно означает самый простой способ уменьшить вес без разговоров о качестве.
• AVIF — сжимает ещё сильнее, но кодирование медленнее, а поддержка чуть моложе. Разумно использовать как дополнительный вариант, оставляя WebP или JPEG запасным.
• JPEG и PNG — не «плохие», а просто менее эффективные. PNG по-прежнему уместен там, где нужна честная прозрачность и мало цветов.
• SVG — для логотипов, иконок и простой графики. Векторный файл не зависит от плотности экрана и обычно весит килобайты.

Технически несколько форматов подключают через элемент picture: браузер сам берёт первый, который понимает.

<picture>
  <source srcset="tovar.avif" type="image/avif">
  <source srcset="tovar.webp" type="image/webp">
  <img src="tovar.jpg" alt="Кресло «Осло», вид спереди" width="1200" height="800">
</picture>

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

Рычаг 3. Сжатие: где заканчивается разумное

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

Ключевая мысль: разница между «качество 100» и «качество 80» почти не видна глазом, а разница в весе заметна сильно. Обратное тоже верно: ниже некоторого предела появляются «мыло», грязь на однотонных фонах и ореолы вокруг текста.

Как поступать на практике:

1. сжимать копию, а не единственный оригинал;
2. смотреть результат на реальном экране, а не в предпросмотре редактора;
3. проверять самые сложные картинки — с градиентами, мелким текстом и логотипом;
4. для фотографий брать сжатие с потерями, для скриншотов интерфейса — быть осторожнее.

Инструмент подойдёт почти любой. Если нужен сайт для сжатия изображения на разовую задачу, годится любой онлайн-сервис, работающий в браузере. Для постоянной работы удобнее автоматизация: плагин CMS, который жмёт файл при загрузке, или шаг в сборке проекта. Ручное сжатие через сайт хорошо для разбора завала, но плохо как процесс: рано или поздно кто-нибудь загрузит исходник с телефона напрямую.

Отдельно: не сжимайте повторно уже сжатое. Каждый новый проход с потерями ухудшает картинку, а веса почти не отнимает.

Рычаг 4. Lazy loading: грузить не всё сразу

Отложенная загрузка, она же lazy load изображений, — самый известный приём и самый часто применяемый неверно.

Идея простая. Браузеру говорят: эту картинку скачивать не надо, пока посетитель до неё не долистал.

<img src="foto.webp" alt="Кресло в интерьере"
     width="1200" height="800" loading="lazy">

Что это даёт: страница с длинным каталогом или галереей не тратит соединение и процессор на десятки картинок, которых человек, возможно, вообще не увидит. Атрибут loading="lazy" понимают все актуальные браузеры, отдельная библиотека для этого давно не нужна.

Заодно обратите внимание на width и height в примере. Заданные размеры позволяют браузеру заранее зарезервировать место — это прямо влияет на сдвиги вёрстки, о которых шла речь в третьей части.

Главное правило: не откладывать то, что видно сразу

А теперь ограничение, ради которого стоило всё это читать.

Документация web.dev формулирует его прямо: не откладывайте загрузку изображений, которые попадают в первый экран, и особенно LCP-изображения.

Логика очевидна, как только её произнесёшь. Отложенная загрузка означает «начни качать позже». Для картинки внизу страницы это выигрыш. Для главной фотографии первого экрана это чистая потеря: вы своими руками отодвинули момент, который метрика LCP и измеряет.

Так выглядит типичная ошибка:

Было:  главное фото грузится сразу        → LCP 2,9 с
Стало: включили lazy loading «на всё»     → LCP 4,4 с
Отчёт: «отложенная загрузка внедрена» ✔
Факт:  посетитель ждёт дольше

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

Правильная схема:

первый экран        → обычная загрузка (loading="eager" или без атрибута)
                      + при желании fetchpriority="high" для главной картинки
ниже первого экрана → loading="lazy"

Атрибут fetchpriority="high" подсказывает браузеру, что этот файл важнее остальных, и его стоит запросить раньше. Браузеры, которые его не понимают, просто проигнорируют — навредить он не может.

Как понять, какая картинка главная

Не на глаз, а по отчёту. В результатах проверки скорости есть LCP-элемент — именно тот объект, по которому считается метрика. Это и есть картинка, которую нельзя откладывать.

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

Порядок работ

Изображений на сайте обычно много, и хочется «привести в порядок всё». Это хороший способ потратить неделю без измеримого результата.

Разумная последовательность:

1. одна важная страница
2. её LCP-изображение: размеры → формат → сжатие
3. проверка: обычная загрузка, не lazy
4. повторный замер
5. остальные картинки первого экрана
6. lazy loading изображений для всего, что ниже
7. автоматизация: конвертация и сжатие при загрузке

Пункт 7 важнее, чем кажется. Разовая чистка держится ровно до того дня, когда контент-менеджер загрузит в карточку товара фотографию прямо с телефона.

Чего делать не стоит

Конвертировать всё скопом без резервной копии

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

Включать «оптимизацию изображений» сразу в двух местах

Плагин CMS, модуль хостинга и сервис доставки контента могут конвертировать одни и те же файлы одновременно. Результат — двойное сжатие, странные артефакты и невозможность понять, кто из них главный.

Гнаться за килобайтами на неглавных картинках

Иконка в подвале весом 8 КБ не влияет ни на что. Время, потраченное на её оптимизацию, лучше вложить в одну фотографию первого экрана.

Терять alt

Оптимизация не повод оставлять картинки без описания. Атрибут alt нужен незрячим посетителям и поисковым системам, а стоит он одну строку.

Чек-лист по изображениям

[ ] известно LCP-изображение страницы
[ ] его габариты соответствуют месту показа (с запасом ×2)
[ ] формат современный (WebP, при необходимости AVIF)
[ ] сжатие проверено глазами на реальном экране
[ ] на главной картинке НЕТ loading="lazy"
[ ] у изображений заданы width и height
[ ] lazy loading включён для всего ниже первого экрана
[ ] конвертация и сжатие автоматизированы при загрузке
[ ] alt заполнен

Проверка в Turbo

Turbo при разборе страницы показывает, какие конкретные файлы стоят за найденной проблемой, — то есть отвечает на вопрос «какие именно картинки», а не ограничивается советом «оптимизируйте изображения». Рекомендации даются с учётом определённой платформы сайта, а у каждой карточки есть пометка, правится это в админке или потребуется специалист.

Порядок тот же, что и раньше: сохранить отчёт до правок, сделать одно изменение, проверить ещё раз и сравнить два отчёта между собой.

Короткие ответы на частые вопросы

Что даёт WebP для сайта и нужно ли переводить все картинки?

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

Как работает lazy loading изображений?

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

Почему нельзя ставить lazy load на главное изображение?

Потому что отложенная загрузка означает «начать качать позже», а главная картинка первого экрана — это обычно и есть LCP-элемент, по которому измеряется скорость появления содержимого. Отложив её, вы ухудшаете ровно ту метрику, которую собирались улучшить. Документация web.dev рекомендует оставлять изображениям первого экрана обычную загрузку.

С чего начать оптимизацию изображений для сайта?

С одной важной страницы и её главного изображения: сначала привести габариты к месту показа, затем перевести в современный формат, затем сжать и повторить замер. Массовую конвертацию всего архива лучше оставить на потом — она долгая, а эффект даёт та картинка, которую посетитель видит первой.

Какой сайт для сжатия изображения выбрать?

Для разовой задачи подойдёт практически любой онлайн-сервис, работающий прямо в браузере, — разница между ними невелика. Важнее другое: сжимайте копию, а не единственный оригинал, и проверяйте результат на реальном экране. Для постоянной работы удобнее не сайт, а автоматическое сжатие при загрузке файла в CMS.

Что дальше

Изображения — самый весомый, но не единственный груз страницы. Даже идеально подготовленная фотография не поможет, если браузер не начинает рисовать страницу, ожидая стили и шрифты.

В пятой части разберём вторую половину веса: как CSS и JavaScript задерживают первый экран, что такое критические стили, почему шрифты заставляют текст мигать и сколько на самом деле стоят чат, аналитика и рекламные скрипты.

Посмотреть, какие именно изображения тормозят вашу страницу, можно бесплатно на turbo.siteko.net.