Фотография товара должна показывать фактуру, а обложка статьи не должна мешать чтению на телефоне. Поэтому оптимизация изображений начинается с вопроса, какую информацию нужно сохранить. WebP и AVIF помогают уменьшать объём файлов, но не дают одинакового результата для любой картинки. Это уже применяемые веб-технологии, а не новинка октября 2026 года. Разберём, как выбирать их для сайта и проверять результат без обещаний фиксированного ускорения.
Что умеют WebP и AVIF
WebP поддерживает сжатие с потерями и без потерь, прозрачность и анимацию. В первом случае часть информации отбрасывается ради меньшего файла. Во втором изображение кодируется без потери пиксельных данных в рамках этого преобразования. Если исходная фотография уже испорчена сильным сжатием JPEG, сохранение в WebP без потерь не вернёт исчезнувшие детали. Возможности формата описаны в документации WebP.
AVIF использует кодирование AV1 и поддерживает, в частности, прозрачность, повышенную глубину цвета и HDR. Для фотографий стоит проверить, даст ли он меньший файл при приемлемом внешнем виде. Но сам выбор AVIF не улучшает исходник, а HDR требует согласованной подготовки и проверки отображения. Техническая основа формата закреплена в спецификации AVIF.
Для проекта нет обязательного победителя. WebP может оказаться удобнее в существующей системе загрузки фотографий, AVIF полезно испытать на тяжёлых изображениях. Поддержку нужно проверять не только в браузерах посетителей, но и в CMS: принимает ли она файл, создаёт ли миниатюры, сохраняет ли прозрачность. Расширение файла само по себе ничего не конвертирует.
Выбирайте формат по содержимому
Для фотографии товара сравните WebP и AVIF при одинаковых размерах в пикселях. Рассмотрите ткань, волосы, мелкие надписи и границы предметов: уменьшение файла не должно скрывать свойства товара. Для скриншота или схемы с мелким текстом отдельно проверьте PNG и WebP без потерь. Здесь читаемость обозначений важнее экономии нескольких байтов.
У прозрачной картинки проверьте края на светлой и тёмной подложке. Если прозрачность нужна и в резервной растровой версии, используйте PNG: JPEG её не поддерживает. Для простого логотипа или пиктограммы при наличии подходящего векторного оригинала рассмотрите SVG. Переводить такой оригинал в растр только ради нового формата не требуется.
Такой выбор соответствует подходу руководства web.dev по форматам: учитывать содержание и требуемые свойства. Не переносите одно значение качества на весь каталог. Число в настройках разных кодировщиков не означает одинаковую видимую детализацию.
Размер картинки важен не меньше расширения
Если фотография показывается небольшой карточкой, не стоит без проверки отдавать для неё огромный оригинал. Сначала определите размеры блоков на телефоне и компьютере, затем подготовьте несколько вариантов. Учитывайте экраны с высокой плотностью пикселей: ширина блока в CSS и необходимое число пикселей изображения могут различаться.
Атрибут srcset перечисляет доступные варианты, а sizes при использовании дескрипторов ширины помогает сообщить браузеру ожидаемую ширину изображения в макете. Браузер выбирает ресурс с учётом условий просмотра. Принцип объяснён в документации по адаптивным изображениям. Важно, чтобы sizes соответствовал реальной вёрстке, а не был скопирован из чужого примера.
Как браузер выбирает формат и зачем нужна резервная версия
В HTML элемент picture объединяет варианты одного изображения: альтернативы указывают через source, а в конце оставляют img с резервной версией. Её называют fallback. Практическая схема для фотографии: сначала source с type="image/avif", затем source с type="image/webp", после них img с JPEG. Это описание структуры, а не готовый код для установки: адреса, размеры и варианты нужно подготовить под конкретный сайт.
Браузер рассматривает подходящие source по порядку, учитывая заявленный тип и другие условия. Если подходящего варианта нет, используется img. Описание и пример есть в документации picture. Alt задаётся у img и должен описывать смысл изображения, а не перечислять ключевые слова.
Резервную версию на случай неподдерживаемого формата нельзя считать страховкой от любой ошибки. Если браузер выбрал AVIF, но файл по его адресу отсутствует, не следует рассчитывать на автоматический переход к JPEG. Поэтому перед запуском проверяют каждый адрес и каждый подготовленный файл. Порядок выбора и обработка ошибок описаны в стандарте HTML.
Почему маленький файл не гарантирует быстрый экран
Посетителю важно, когда изображение появилось, а не только сколько оно весит. Ожидание ответа сервера, позднее обнаружение ресурса и задержка отрисовки могут перекрыть пользу сжатия. Поэтому показатель LCP, связанный с появлением самого крупного видимого элемента, проверяют на странице целиком. Для основного LCP-изображения не следует применять отложенную загрузку loading="lazy". Подробнее об этих зависимостях сказано в руководстве по оптимизации LCP.
У изображений также задают корректные width и height, чтобы браузер мог заранее учесть пропорции и зарезервировать место. Это помогает избежать скачков макета во время загрузки. Назначение атрибутов приведено в документации img. Настройку размеров согласуют с адаптивными стилями, а не используют как замену им.
Как принять результат без массового риска
- Выберите небольшой набор разных изображений: обложку, фотографию товара, прозрачную графику и скриншот.
- Сохраните оригиналы. Для каждого теста запишите размеры, формат, настройки и объём полученного файла.
- Сравните изображения в реальном размере показа и отдельно рассмотрите важные детали. Проверьте оттенки и края прозрачности.
- На тестовой странице убедитесь, какой файл действительно загружен. Проверьте телефон, компьютер и нужные проекту старые браузеры или встроенные просмотрщики.
- Измерьте страницу до и после в одинаковых условиях. Не делайте вывод по единственному запуску и не подменяйте проверку качества оценкой скорости.
- Только после приёмки переносите подходящую схему на другие разделы. Заранее определите способ возврата к прежним файлам.
После приёмки сохраните оригиналы, выбранную схему форматов, таблицу размеров и объёмов файлов, а также сравнение страницы до и после. По этому комплекту можно проверить результат и повторить настройку для следующей группы изображений.
Для нового проекта требования к изображениям стоит включить в разработку сайта. На действующем сайте схема загрузки может потребовать доработки, а эффект оценивается вместе с другими задачами по ускорению сайта.
Нужна помощь с изображениями для сайта? Напишите нам в MAX, Telegram или WhatsApp, либо на mail@olimp.ltd. Также можно оставить заявку на сайте. Пришлите адрес сайта и 2–3 характерные страницы. Если исходные изображения доступны и вы вправе ими поделиться, приложите их; конфиденциальные материалы отправлять не нужно. Начать полезнее с конкретных файлов и условий просмотра, чем с обещания уменьшить весь сайт на заданный процент.
Материал носит информационный характер. Подходящая схема определяется после проверки исходников, платформы и требований проекта; конкретные показатели скорости и оценки сервисов тестирования не гарантируются.
Автор: Милюков Михаил Андреевич.
