Изображения под ширину экрана и плотность пикселей
После исследования LCP у нас появился ранний img в HTML. Теперь рассмотрим, какой файл браузер должен получить для разных экранов. Одна большая картинка может быть избыточной для узкой колонки, а слишком маленькая — терять детали на плотном дисплее. Нужен выбор между реальной шириной показа и качеством изображения.
В speed-lab подготовлены собственные простые растровые схемы шириной 480, 800 и 1200 пикселей. У них одинаковое отношение сторон. Это учебные файлы с хорошо сжимаемыми цветными областями, поэтому их вес не представляет фотографии ProfessorWeb. Примеры не запускались автором, а выигрыш доставки предстоит оценивать читателю на подходящем содержимом.
CSS-пиксель и пиксель файла
Размер изображения на странице обычно задаётся в CSS-пикселях. Сам растровый файл состоит из собственных пикселей. На устройстве с плотным экраном одному CSS-пикселю может соответствовать несколько физических. Поэтому картинка, видимая шириной 400 CSS-пикселей, иногда требует большего количества пикселей файла для сохранения детализации. Это полезная модель выбора, но не обещание точного алгоритма браузера.
Рассмотрим учебное условие: колонка имеет ширину 720 CSS-пикселей. При DPR 1 ресурс шириной 800 может быть достаточным, а при DPR 2 браузер способен предпочесть более крупный из доступных. Если максимум набора равен 1200, это ограничение остаётся. Нельзя сказать, что srcset создаёт недостающий вариант: он предлагает существующие файлы.
Кроме качества, следует оценивать смысл изображения. Диаграмма с мелкими подписями и декоративная фотография предъявляют разные требования. Сжатие, делающие подписи нечитаемыми, изменяет учебный материал. В серии про изображения в статье уже рассмотрена связь изображения и содержания; здесь сосредоточимся на сетевом выборе ресурса.
Набор вариантов и ожидаемая ширина
Вместо одного URL зададим несколько кандидатов с дескрипторами ширины. sizes описывает предполагаемую ширину элемента в CSS при разных условиях. Эти сведения нужны браузеру для выбора, но не меняют CSS-оформление. Если объявленная ширина не соответствует реальной колонке, файл может оказаться лишним или недостаточным. Responsive images.
Полный элемент candidate выглядит так:
<img class="hero" src="../assets/delivery-800.v1.png"
srcset="../assets/delivery-480.v1.png 480w,
../assets/delivery-800.v1.png 800w,
../assets/delivery-1200.v1.png 1200w"
sizes="(max-width: 800px) calc(100vw - 80px), 720px"
width="1200" height="640" fetchpriority="high"
alt="Три стадии доставки: документ, ресурсы и отображение">Числа 480w, 800w и 1200w обозначают фактическую ширину файлов. Условие sizes относится к нашему макету: доступная ширина страницы уменьшается отступами, а на широком экране изображение занимает примерно 720 CSS-пикселей. При изменении макета нужно пересмотреть эту формулу. Копирование её в любую статью не создаёт правильный выбор автоматически.
Атрибуты width и height дают исходное отношение сторон. Фактическое оформление .hero использует width: 100% и height: auto, поэтому элемент вписывается в контейнер. Числа атрибутов не требуют показывать картинку неизменно шириной 1200 CSS-пикселей. Их роль в резервировании пространства станет особенно важна при изучении CLS.
Здесь сохранён fetchpriority="high", поскольку это вариант для главного изображения. Для карточек ниже статьи приоритет и момент доставки могут быть другими. Не переносите настройку в общий генератор для каждого изображения без разбора. Подсказка о важности должна отражать сценарий, иначе поздние ресурсы будут конкурировать с ранними.
Как проверить выбор браузера
После ручной загрузки выберите элемент и исследуйте currentSrc, ширину показа и свойства изображения. Следующий диагностический фрагмент предназначен для Console, не выполнялся автором и не является автоматической проверкой качества:
const hero = document.querySelector(".hero");
console.table({
selected: hero.currentSrc,
cssWidth: hero.getBoundingClientRect().width,
dpr: window.devicePixelRatio,
complete: hero.complete,
});currentSrc сообщает выбранный URL. Сопоставьте его с Network, чтобы увидеть фактическую доставку и состояние кеша. Свойство complete само по себе не означает успешного показа содержательной картинки: завершённое состояние возможно и при неудачной загрузке. Для расследования важны ответ ресурса и его изображение на странице.
При изменении размера окна браузер не обязан немедленно заменить уже полученный крупный ресурс меньшим. Поэтому эксперимент выбора лучше проводить отдельными переходами при заранее установленном viewport. Иначе кеш и ранее загруженный вариант станут дополнительными переменными. Сохраняйте тот же протокол, который использовали для LCP.
Проверяйте реальные размеры файлов, а не только имя delivery-800. Имя является соглашением автора, а дескриптор должен соответствовать данным. Если один вариант неожиданно имеет другое отношение сторон, смена ресурса способна повлиять на компоновку. Для art direction, когда меняется само кадрирование, потребуется отдельное решение через picture; не смешивайте его с простым выбором разрешения.
Формат и цена обработки
WebP и AVIF могут оказаться полезными вариантами доставки, но степень сжатия зависит от содержимого и параметров кодирования. У простой схемы и фотографии результат различается. Сравнивайте при сопоставимом визуальном качестве и учитывайте браузеры целевой аудитории. В исходниках этой серии такие версии не подготовлены, поэтому мы не выдаём их предполагаемый выигрыш за полученный.
Уменьшение байтов не всегда пропорционально уменьшает время показа. После получения изображение обрабатывается браузером, а кадр зависит от остальной работы страницы. Поэтому сохраняйте два наблюдения: размер доставки и появление результата. Если меньший файл не ускорил LCP, вернитесь к разделению фаз из предыдущего урока, вместо того чтобы объявлять сравнение бессмысленным.
Практическое продолжение — подставить собственную лицензированную фотографию, создать настоящие размеры и сравнить детали. На узком и широком экране прочитайте подписи, проверьте кадрирование и выбранный URL. Только после этого сопоставляйте байты одинаковых сценариев. Учебные цветные схемы полезны для разметки и выбора, но не для выводов о качестве фото.
Неудачная доставка и резерв
Проверьте выбранный ресурс при отсутствующем файле в отдельной локальной копии. Альтернативный текст должен передавать смысл схемы, а основная статья оставаться читаемой. Такой сценарий не измеряет эффективность сжатия, но помогает убедиться, что подготовленные размеры не скрывают сообщение об ошибке и что содержание не зависит только от растровых пикселей. Доступность сохраняется вместе с техническим выбором.
У нескольких вариантов должны совпадать назначение и структура изображения. Если файл меньшего размера содержит другие подписи или сокращённую схему, сравнение уже относится к разному материалу. Можно специально создавать адаптивное кадрирование, но его договор должен быть явным. В этой серии все три файла показывают одни цветные блоки, поэтому выбор разрешения не меняет учебную информацию.
На большом количестве статей полезно хранить исходное изображение отдельно от доставляемых вариантов. Тогда изменения качества и размера можно воспроизвести по известным параметрам. Здесь не вводим новый конвейер генерации: результат урока ограничен пониманием разметки и выбранного файла. Но именно этот договор позже позволит автоматизировать подготовку, не подменяя проверку качества случайным правилом имени.
К концу урока сохраните связь «ширина контейнера → набор вариантов → выбранный ресурс». Она объясняет, почему браузер получил именно этот файл. Следующее изменение касается шрифта: он также является ресурсом, но его доставка влияет на появление текста и размеры строк, поэтому правильного сетевого выбора одного файла там будет недостаточно.