Перейти к содержанию

Краткая история изображений в Интернете

История изображений в Интернете, начиная с элемента 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

Комментарии