Краткая история изображений в Интернете¶
История изображений в Интернете, начиная с элемента image в 1993 году
Независимо от того, как далеко вы продвинулись в изучении дизайна и разработки для Web, элемент <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
оно будет потреблять огромное количество полосы пропускания и вычислительной мощности без ощутимой пользы.
Ситуация значительно ухудшилась с появлением первых "ретина"-устройств, когда наряду с размером области просмотра стала учитываться и плотность отображения. Для того чтобы источник изображения подходил для дисплея с высокой плотностью, ему требуется гораздо большая собственная ширина. Проще говоря, дисплей с удвоенной плотностью требует в два раза больше пикселей изображения для его максимально четкого отображения.
Здесь разработчики снова смогли положиться на способность движков рендеринга визуально уменьшать масштаб изображения. Предоставив браузеру исходное изображение шириной 800px
в src
, а затем указав в CSS, что оно должно отображаться с шириной 400px
, мы получаем изображение с удвоенной плотностью пикселей:
Одно исходное изображение, обрезанное под максимально возможное пространство в макете и на дисплеях высокой плотности, конечно, работает для всех пользователей визуально. Огромное исходное изображение высокого разрешения, выведенное на маленький дисплей с низкой плотностью, будет выглядеть как любое другое маленькое изображение с низкой плотностью, но работать будет гораздо медленнее. Пользователь будет вынужден нести все издержки производительности этого массивного изображения шириной 4000px
, не получая никакой выгоды.
Долгое время <img>
выполнял в основном одну задачу - "получал данные изображения и выводил их на экран". Конечно, он делал это достаточно хорошо, но <img>
не справлялся с радикальными изменениями в контексте просмотра, которые мы переживали. В то время как отзывчивый веб-дизайн стал основной практикой разработки, браузеры оптимизировали работу img
в течение почти двадцати лет - но для всех, кроме самых привилегированных пользователей, изображение содержимого страницы было неэффективным с самого начала. Независимо от того, насколько быстро браузеру удавалось запросить, разобрать и отобразить исходное изображение, его размер, скорее всего, был намного больше, чем требовалось пользователю.
Источник — A brief history of images on the web