Как принять загрузку фотографий товара на мобильном сайте

Выберите экран и важные детали

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

Для учебного теста возьмём настольную лампу L-27. Владелец требует различать переключатель и форму основания, а при увеличении ещё и соединение стойки. Снимок, размеры и числа в этом руководстве придуманы. Это не результат измерений сайта клиента и не заявленная настройка SABSUS.

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

Попросите комплект файлов и описание разметки

В srcset перечисляют доступные файлы с описанием размера. При дескрипторах ширины sizes сообщает ожидаемую ширину изображения в макете; это не команда изменить CSS. Атрибуты width и height помогают заранее выделить место. web.dev: адаптивные изображения.

В задании перечислите каждый подготовленный файл, его фактические размеры и объём. Добавьте снимок согласованного кадрирования. Сотруднику должно быть понятно, какой материал проверять, даже если названия вроде final-new-2 больше никому ничего не говорят. Не назначайте универсальный лимит килобайт до сравнения реальных экспортов.

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

Разберите один расчёт, затем проверьте запрос

У лампы подготовлены одинаково кадрированные файлы шириной 400, 800 и 1200 пикселей. Блок занимает 400 CSS-пикселей. При DPR 1 ориентир составляет 400 × 1 = 400 пикселей; при DPR 2 — 800; при DPR 3 — 1200. Это расчёт потребности, а не обещание конкретного запроса.

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

Предположим, в нашем испытании записан запрос файла lamp-800.webp объёмом 92 КБ. Это условная запись для заполнения протокола. Чтобы оценить её, редактор открывает именно полученный кадр и отмечает, различим ли переключатель. Число 92 не является рекомендуемым пределом для других товаров.

Для плитки шириной 200 CSS-пикселей при DPR 2 расчётный ориентир уже 400 пикселей. В протоколе разделите плитку и главное фото: название одного телефона не описывает размеры обоих блоков.

Отделите первое фото от нижней галереи

web.dev рекомендует не откладывать через loading="lazy" изображения первого экрана. Для нижних изображений lazy позволяет отложить запрос до приближения к видимой области; порог зависит от браузера. Поэтому запрос немного раньше прокрутки к самому изображению ещё не доказывает ошибку. web.dev: отложенная загрузка.

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

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

Не пытайтесь исправить lazy у главного фото только через fetchpriority="high": приоритет не отменяет условие отложенной загрузки. Эти настройки отвечают на разные вопросы.

Сохраните проверяемое наблюдение

В Chrome DevTools панель Network показывает запросы и объём ресурсов. Откройте её до перезагрузки страницы: итог относится к записанным запросам. Укажите, что именно сравниваете: переданные данные или размер загруженного ресурса. Для проверки без обычного кэша используйте Disable cache при открытых DevTools. Chrome: панель Network.

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

Проведите отдельные проходы для первого посещения и возврата на страницу, явно подписав условия. Не смешивайте их в среднее «вес картинки». Затем повторите основной маршрут на настоящем телефоне. Эмуляция полезна как воспроизводимый тест, но не заменяет просмотр устройства, для которого согласована приёмка.

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

Пройдите пять проверок выпуска

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

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

Блокирующими считаем отсутствующий кадр, потерю важной детали и расхождение с согласованным комплектом без объяснения. Спорный объём файла отправляем на сравнение альтернатив при одинаковом качестве. Фразы «все картинки оптимизированы» недостаточно: возле каждой проверки должны стоять наблюдение и решение.