Изображения и скорость длинной статьи

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

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

Размер отображения и размер файла

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

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

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

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

Выбор подходящего ресурса

После предоставления двух собственных файлов замените текстовый прототип следующим ресурсным фрагментом:

<img src="media/markdown-flow-1200.png"
     srcset="media/markdown-flow-640.png 640w, media/markdown-flow-1200.png 1200w"
     sizes="(min-width: 64rem) 46rem, (min-width: 48rem) 68ch, calc(100vw - 2rem)"
     width="1200" height="675"
     alt="Схема перехода от исходника Markdown к готовой HTML-странице">

srcset перечисляет варианты с их настоящей шириной, а sizes описывает ожидаемую ширину отображения для разных условий. Браузер использует эти сведения вместе со своими условиями выбора. Механизм рассмотрен в MDN об адаптивных изображениях. Это не приказ всегда загрузить определённый вариант в каждом устройстве.

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

Атрибуты width и height дают исходную пропорцию. Место под изображение может быть рассчитано заранее, а CSS сохранит адаптивную ширину. Такой подход уменьшает один из источников сдвигов содержимого, описанных в web.dev. Он не гарантирует нулевой CLS всей страницы, поскольку другие объекты тоже могут изменять геометрию.

Положение изображения в статье

У изображения в первой области и изображения далеко ниже разные условия. Картинка, необходимая для понимания начала, должна быть доступна своевременно. Если отложить её загрузку только ради общего правила, читатель увидит пустую область там, где ожидает пояснение.

Для собственной иллюстрации ниже первого экрана можно рассмотреть loading="lazy". Оно позволяет браузеру откладывать загрузку до приближения к видимой области; точное расстояние выбирает браузер. Поведение описано в MDN для img. Не объявляйте, что все изображения гарантированно загрузятся только после нажатия или пересечения одной фиксированной линии.

decoding="async" может быть отдельной подсказкой декодирования, но не является универсальной гарантией ускорения. При подготовке дизайна важнее заранее обеспечить правильные размеры и подходящий ресурс. Дополнительные атрибуты должны отвечать конкретной задаче, а не создавать декоративный список оптимизаций.

Не назначайте fetchpriority="high" каждой картинке. Это подсказка относительного приоритета, полезность которой зависит от критичности ресурса; рекомендации и ограничения приведены в web.dev о Fetch Priority. Если всё объявлено главным, понятное различие задач теряется.

Схема и снимок интерфейса

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

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

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

Кадрирование через object-fit: cover не заменяет обработку файла. Оно может обрезать видимую область, продолжая загружать исходный ресурс. Кроме того, обрезка кода или системного сообщения искажает учебное объяснение. Для основной статьи сохраняем изображение целиком.

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

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

Ресурсный договор

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

Не заносите в таблицу выдуманные килобайты и миллисекунды. Они становятся наблюдениями только после работы с конкретными ресурсами и выбранной средой. Пока можно оставить соответствующие поля пустыми и записать ожидаемые ограничения. План оптимизации и полученный результат не совпадают.

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

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