Насколько быстрее использовать встроенные /base64 изображения для веб-сайта, чем просто ссылку на жесткий файл?
Насколько быстрее использовать base64/line для отображения изображений, чем просто ссылаться на жесткий файл на сервере?
url(data:image/png;base64,.......)
Я не смог найти какой-либо тип показателей производительности по этому вопросу.
У меня есть несколько проблем:
- Вы больше не получаете выгоду от кеширования
- Разве base64 не намного больше, чем размер файла PNG/JPEG?
Давайте определим "быстрее" как в: время, которое требуется пользователю, чтобы увидеть полностью отображенную веб-страницу HTML
4 ответа
"Быстрее" сложно ответить, потому что есть много возможных интерпретаций и ситуаций:
Кодировка Base64 расширит изображение на треть, что увеличит использование полосы пропускания. С другой стороны, включение его в файл приведет к удалению очередного GET-запроса на сервер. Таким образом, канал с большой пропускной способностью, но с низкой задержкой (например, спутниковое интернет-соединение), вероятно, загрузит страницу с встроенными изображениями быстрее, чем если бы вы использовали отдельные файлы изображений. Даже на моей (сельской, медленной) линии DSL сайты, для которых требуется многократные поездки, загружаются намного дольше, чем те, которые являются относительно большими, но требуют только нескольких GET.
Если вы выполняете кодировку base64 из исходных файлов при каждом запросе, вы будете использовать больше ресурсов ЦП, перезагружать кэш данных и т. Д., Что может повлиять на время отклика серверов. (Конечно, вы всегда можете использовать memcached или тому подобное для решения этой проблемы).
Это, конечно, предотвратит большинство форм кэширования, которые могут сильно повредить, если изображение часто просматривается - скажем, логотип, отображаемый на каждой странице, который обычно может кэшироваться браузером (или прокси-кеш, такой как squid или что угодно) и просили раз в месяц. Это также предотвратит множество оптимизаций, которые имеют веб-серверы для обслуживания статических файлов с использованием API-интерфейсов ядра, таких как sendfile(2).
По сути, это поможет в определенных ситуациях и повредит в других. Вам нужно определить, какие ситуации важны для вас, прежде чем вы действительно сможете понять, стоит ли это для вас.
Я сделал сравнение между двумя HTML-страницами, содержащими 1800 однопиксельных изображений.
Первая страница объявляет изображения встроенными:
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAANSURBVBhXYzh8+PB/AAffA0nNPuCLAAAAAElFTkSuQmCC">
Во втором изображения ссылаются на внешний файл:
<img src="img/one-gray-px.png">
Я обнаружил, что при многократной загрузке одного и того же изображения, если оно объявлено как встроенное, браузер выполняет запрос для каждого изображения (я полагаю, что base64 декодирует его один раз для каждого изображения), тогда как в другом сценарии изображение запрашивается один раз. за документ (см. изображение сравнения ниже).
Документ со встроенными изображениями загружается примерно за 250 мс, а документ со связанными изображениями - за 30 мс.
(Проверено с хромом 34)
Сценарий документа HTML с несколькими экземплярами одного встроенного изображения не имеет большого смысла априори. Однако я обнаружил, что плагин jquery lazyload определяет встроенный заполнитель по умолчанию для всех "ленивых" изображений, чьи src атрибут будет установлен на него. Затем, если документ содержит много ленивых изображений, может возникнуть ситуация, подобная описанной выше.
Вы больше не получаете выгоду от кеширования
Будет ли это иметь значение, зависит от того, насколько сильно вы зависите от кэширования.
Разве base64 не намного больше, чем размер файла PNG/JPEG?
Формат файла / алгоритм сжатия изображения тот же, я так понимаю, то есть PNG.
При использовании Base-64 каждый 8-разрядный символ представляет 6-разрядный код: поэтому двоичные данные распаковываются с отношением 8 к 6, т.е. только около 35%.
Насколько быстрее это
Определите "быстрее". Вы имеете в виду производительность HTTP (см. Ниже) или производительность рендеринга?
Вы больше не получаете выгоду от кеширования
На самом деле, если вы делаете это в файле CSS, он все равно будет кэширован. Конечно, любые изменения в CSS сделают кеш недействительным.
В некоторых ситуациях это может быть использовано как значительное повышение производительности во многих HTTP-соединениях. Я говорю о некоторых ситуациях, потому что вы, вероятно, можете использовать в своих целях такие методы, как спрайты изображений, но всегда хорошо иметь в своем арсенале другой инструмент!