Независимо от того, как далеко вы продвинулись в изучении дизайна и разработки для Интернета, элемент <img> не требует особого представления. Запущенный в Netscape («Mosaic» в то время) в 1993 году и добавленный в спецификацию HTML в 1995 году, <img> долгое время играл простую, но важную роль в веб-платформе. Разработчик добавляет «исходный» файл изображения с атрибутом src и предоставляет текстовую альтернативу с атрибутом alt на тот случай, если изображение невозможно отобразить или вспомогательные технологии запрашивают альтернативу. Отсюда у браузера есть только одна задача: получить данные изображения, а затем отобразить их как можно быстрее.
На протяжении большей части истории веб-разработки работа с изображениями не была намного сложнее. И, несмотря на сложность современной сети, основы работы с изображениями не изменились: используйте удобный для Интернета формат изображения для совместимости, разумное сжатие для экономии пропускной способности и размеры, соответствующие пространству, которое изображение будет занимать на странице. макет.
Использование макетов фиксированной ширины, как мы это делали в те времена, когда считали, что можем больше влиять на то, как пользователи взаимодействуют с Интернетом, сделало этот процесс несложным. Было особенно легко установить размер источника изображения. Для изображения, которое занимало пространство шириной пятьсот пикселей и высотой триста пикселей, это был случай указания исходного изображения того же размера.
Изображения в адаптивном макете
Наряду с гибким макетом и использованием медиа-запросов CSS, «гибкие изображения и медиа» являются одним из трех определяющих аспектов адаптивного веб-дизайна . Чтобы сделать изображение гибким, разработчики начали использовать CSS, чтобы установить max-width: 100% для изображения (или всех изображений по всему сайту), чтобы сообщить механизму рендеринга браузера, что изображение никогда не должно переполнять родительский контейнер путем его уменьшения. . Визуально это работает идеально: уменьшение растрового изображения визуально происходит незаметно. С помощью одной-двух строк CSS уменьшенное изображение всегда будет выглядеть так, как будто мы указали источник изображения, который должен был отображаться в этом размере. Когда механизмам рендеринга предоставляется больше данных изображения, чем необходимо для пространства, которое изображение занимает в макете, они могут принимать обоснованные решения о том, как визуализировать уменьшенное изображение, и могут делать это без каких-либо визуальных артефактов или размытия.
Обычно вам не потребуется масштабировать изображение, то есть отображать <img> в размере, превышающем внутренний размер исходного изображения. Отображаемое изображение будет выглядеть размытым и зернистым.
Использование img { max-width: 100% } означает, что при изменении размеров гибкого контейнера изображения будут соответствующим образом уменьшены. В отличие от установки более жесткой width: 100% , это также гарантирует, что изображение не будет увеличено за пределы его внутреннего размера. Долгое время правила работы с изображениями сводились к следующему: используйте формат, понятный браузерам, используйте разумный уровень сжатия и никогда не масштабируйте изображения вверх.
Но каким бы простым и эффективным ни был этот подход визуально, он стоил огромных потерь в производительности. Поскольку <img> поддерживал только один источник данных изображения, этот подход требовал от нас предоставления ресурса изображения с внутренним размером, равным наибольшему размеру, при котором оно могло отображаться. Изображение, которое должно было занимать пространство в макете шириной от 300px до 2000px , в зависимости от размера области просмотра пользователя, требовало источника изображения с внутренней шириной не менее 2000px . Для пользователя, который просматривает страницу только через небольшую область просмотра, все будет выглядеть так, как ожидалось — изображение будет прекрасно масштабироваться. На обработанной странице массивное, но уменьшенное исходное изображение не будет отличаться от изображения подходящего размера. Тем не менее, они по-прежнему будут передавать и отображать изображение шириной 2000px , используя огромную пропускную способность и вычислительную мощность без какой-либо ощутимой выгоды.
Ситуация стала намного хуже с появлением первых устройств Retina, поскольку плотность дисплея стала проблемой наряду с размером области просмотра. Источнику изображения требуется гораздо большая внутренняя ширина, чтобы соответствовать дисплею с высокой плотностью изображения. Проще говоря, дисплею с удвоенной плотностью требуется вдвое больше пикселей изображения, чтобы изображение было максимально четким.
Здесь разработчики снова смогли положиться на способность механизмов рендеринга визуально уменьшать масштаб изображений. Если предоставить браузеру исходное изображение шириной 800px в src , а затем указать, что оно должно отображаться с шириной 400px с помощью CSS, в результате получится изображение, отображаемое с двойной плотностью пикселей:
Единое исходное изображение, обрезанное так, чтобы оно соответствовало максимально возможному пространству вашего макета и дисплеям высокой плотности, естественно, визуально работает для всех пользователей. Огромный источник изображения с высоким разрешением, отображаемый на маленьком дисплее с низкой плотностью, будет выглядеть как любое другое маленькое изображение с низкой плотностью, но будет восприниматься намного медленнее. Пользователю придется нести все затраты на производительность этого огромного источника изображения шириной 4000 пикселей, но это не принесет никакой пользы.
Долгое время <img> в основном делал одну задачу — «получал данные изображения и выводил их на экран». Конечно, он справился с этим достаточно хорошо, но <img> не смог справиться с радикальными изменениями в контексте просмотра, с которыми мы столкнулись. В то время как адаптивный веб-дизайн стал основной практикой разработки, браузеры оптимизировали производительность img в течение почти двадцати лет, но для всех, кроме самых привилегированных пользователей, содержимое страниц с изображениями было неэффективным с самого начала. Независимо от того, насколько быстро браузеру удалось запросить, проанализировать и отобразить источник изображения, этот ресурс, скорее всего, будет намного больше, чем нужно пользователю.