В каталоге фотография занимает небольшую область, а браузер скачивает оригинал шириной несколько тысяч пикселей. На быстром соединении это почти незаметно, но десятки таких карточек создают лишнюю передачу данных. Проблему нельзя подтвердить одним сравнением «ширина файла больше ширины блока»: экран высокой плотности действительно может требовать более подробного изображения.
Нужно сопоставить отображаемый размер, выбранный источник и фактическую сетевую загрузку в конкретном сценарии. Ниже — проверка учебной карточки каталога шириной 280 CSS-пикселей. Эти размеры иллюстрируют метод и не являются результатами измерения действующего магазина.
Измерьте место фотографии в интерфейсе
Откройте каталог на контрольной ширине окна и измерьте область изображения. Отдельно запишите ширину всей карточки, внутренние отступы и ширину самой фотографии: значение для sizes должно описывать место картинки, а не случайный размер родительской колонки.
Повторите измерение на телефоне и широком экране. Карточки могут менять количество колонок, а фотография — занимать почти всю ширину в мобильном варианте. Один фиксированный размер, выбранный по настольному макету, способен дать слишком маленькое изображение на узком экране с одной колонкой.
Посмотрите правила обрезки. При object-fit: cover часть кадра скрыта, но исходник всё равно загружается. Это не делает лишнюю площадь бесплатной. Однако подготовка другого кадрирования — отдельное редакторское решение: уменьшение файла не должно случайно обрезать важные детали товара.
Зафиксируйте выбранный ресурс и плотность экрана
В инспекторе найдите элемент img и посмотрите его источник после выбора браузером. При наличии srcset этот адрес может отличаться от src. Запишите также плотность пикселей устройства и размер окна. Без этих условий сравнение двух прогонов теряет смысл.
Ширина 280 CSS-пикселей при плотности 2 означает ориентир около 560 физических пикселей для соответствующего отображения. Это не предписание всегда создавать файл ровно такого размера: выбор зависит от доступных вариантов, устройства и поведения браузера. Но оно объясняет, почему изображение шириной 560 не обязательно избыточно для блока 280.
Проверьте фактический файл из выбранного URL. Название small.jpg не доказывает маленькие размеры, а параметр width=600 не гарантирует, что сервис преобразования применил его. Сохраните размеры декодированного изображения и убедитесь, что по ссылке не возвращается неизменённый оригинал.
Сравните байты и качество на одном товаре
Во вкладке сети запишите переданный размер, размер ресурса и состояние кеша. Эти значения могут различаться: повторное открытие иногда использует сохранённый файл и почти не передаёт данные. Для оценки первоначальной загрузки нужны одинаковые условия без влияния ранее полученного изображения.
Учебная таблица показывает, какие сведения стоит собрать:
| Сценарий | Область фото | Плотность | Выбранный файл | Что обсуждаем |
|---|---|---|---|---|
| Каталог на компьютере | 280 CSS px | 1 | Оригинал 2400 px | Нужен ли столь большой источник |
| Тот же каталог | 280 CSS px | 2 | Вариант 640 px | Качество и разумный запас |
| Одна колонка телефона | 350 CSS px | 2 | Вариант 320 px | Не потеряна ли резкость |
Сравнивайте один и тот же товар и кадр. Если новый файл другой по содержанию или значительно хуже качеством, уменьшение байтов ещё не доказывает успешную оптимизацию. Для каталога важно сохранить возможность различить детали, цвет и форму продукта.
Проверьте смысл srcset и sizes
При описателях ширины в srcset указывают доступные размеры вариантов, а sizes сообщает ожидаемую ширину отображения в разных условиях. Ошибка вроде постоянного 100vw для небольшой карточки может направлять браузер к слишком крупному ресурсу. Проверяйте правило по реальному макету, а не по значению из чужого примера.
Допустим, на широком экране карточка занимает четверть рабочей области, а на телефоне — всю колонку. В условии должны учитываться контейнер, промежутки и точки переключения. Если заявленные размеры вариантов не соответствуют файлам, сначала исправьте их генерацию: неверный список не позволит осмысленно выбирать источник.
Описание атрибутов и поведения элемента доступно в документации MDN по img. Используйте её при реализации, но подтверждайте итог в браузере. Наличие srcset в HTML само по себе не доказывает, что набор размеров полезен для вашего каталога.
Подготовьте варианты без изменения галереи
Разделите файл для сетки каталога и изображение увеличенного просмотра. Маленькая карточка может использовать оптимизированный вариант, а галерея — более подробный. Не заменяйте все оригиналы одним маленьким файлом: покупатель, открывший крупный просмотр, должен по-прежнему рассмотреть товар.
Проверьте генератор миниатюр для новых и старых записей. Изменение настройки CMS иногда влияет только на будущие загрузки, а существующие товары продолжают получать прежние файлы. Решите, нужна ли повторная генерация, как она будет выполняться и как сохранятся исходники.
Сжатие и изменение размеров оценивайте отдельно. Новый формат не исправляет неверный размер карточки, а меньшая ширина не гарантирует хорошую передачу деталей. Практика подготовки вариантов рассмотрена в руководстве по изменению размеров, способы уменьшения веса — в инструкции по сжатию.
Повторите измерение с контролем окружения
Используйте те же размеры окна, плотность экрана и сетевые условия. Сделайте новое открытие после обновления файлов и очистки нужных слоёв кеша. Сравните выбранные источники и передачу данных, а не только общий балл одного лабораторного запуска.
Проверьте первую видимую строку карточек и элементы ниже по странице. Время запроса может отличаться из-за отложенной загрузки, но это не объясняет выбор слишком большого файла. Если изображение уже находится на первом экране, отдельно оцените задержку его обнаружения и загрузки.
При ошибке одного варианта проверьте резервный источник. Новый список размеров не должен приводить к сломанной фотографии на другом устройстве. Добавьте в выборку товар с вертикальным фото и товар с мелкими деталями: одинаковая настройка качества может давать разный практический результат.
Примите изменение по двум результатам
Технический результат — браузер получает подходящие варианты, запросы успешны, размеры согласованы с местом отображения. Пользовательский — товар остаётся узнаваемым, увеличенный просмотр работает, переключение вариантов не меняет фото на неверное. Оба результата нужны для завершения задачи.
Запишите контрольные условия и фактически выбранные файлы в отчёт разработчика. Не утверждайте, что уменьшение картинки автоматически улучшило все Web Vitals или поисковые позиции. Для метрик нужна отдельная серия наблюдений, а для влияния на поиск — более широкий анализ.
Техническая проверка страницы поможет собрать дополнительные сведения о ресурсах после публикации. Но решение о качестве фотографии принимают по изображению в действующем интерфейсе. Оптимизация завершена, когда размер загрузки обоснован сценарием и экономия не разрушила назначение фото товара.