Насколько быстрее он использует изображения inline/base64 для веб-сайта, чем просто ссылку на жесткий файл?

Ответ 1

"Быстрее" сложно ответить, потому что существует множество возможных интерпретаций и ситуаций:

Кодировка Base64 расширит изображение на треть, что увеличит использование полосы пропускания. С другой стороны, в том числе и в файле, будет удалена еще одна поездка GET на сервер. Таким образом, труба с большой пропускной способностью, но с низкой задержкой (например, подключение к спутниковому интернету), скорее всего, загрузит страницу со встроенными изображениями быстрее, чем если бы вы использовали разные файлы изображений. Даже на моей (сельской, медленной) линии DSL сайты, которым требуется много раундов, требуют гораздо больше времени для загрузки, чем те, которые являются относительно большими, но требуют лишь нескольких GET.

Если вы делаете кодировку base64 из исходных файлов с каждым запросом, вы будете использовать больше CPU, разбивая ваши кэши данных и т.д., что может повредить время отклика серверов. (Конечно, вы всегда можете использовать memcached или такой, чтобы решить эту проблему).

Выполнение этого, конечно же, предотвратит большинство форм кеширования, что может сильно повредить, если изображение просматривается часто - скажем, логотип, который отображается на каждой странице, который обычно может кэшироваться браузером (или прокси-кешем как кальмар или что-то еще) и запрашивается один раз в месяц. Это также предотвратит использование многих веб-серверов оптимизации для обслуживания статических файлов с использованием API-интерфейсов ядра, таких как sendfile (2).

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

Ответ 2

Я провел сравнение двух HTML-страниц, содержащих 1800 однопиксельных изображений.

Первая страница объявляет изображения inline:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAANSURBVBhXYzh8+PB/AAffA0nNPuCLAAAAAElFTkSuQmCC">

Во втором, образы ссылаются на внешний файл:

<img src="img/one-gray-px.png">

Я обнаружил, что при многократном загрузке одного и того же изображения, если он объявлен inline, браузер выполняет запрос для каждого изображения (я предполагаю, что base64-декодирует его один раз на изображение), тогда как в другом сценарии изображение запрашивается один раз для каждого документа (см. сравнительное изображение ниже).

Документ с встроенными изображениями загружается примерно в 250 мс, а документ со связанными изображениями - через 30 мс.

(Протестировано хромом 34)

Сценарий HTML-документа с несколькими экземплярами одного и того же встроенного изображения не имеет большого значения априори. Тем не менее, я обнаружил, что плагин jquery lazyload определяет встроенный заполнитель по умолчанию для всех "ленивых" изображений, чей атрибут src будет установлен к нему. Затем, если в документе содержится много ленивых изображений, может произойти ситуация, подобная описанной выше.

Ответ 3

Насколько он быстрее

Определите "быстрее". Вы имеете в виду производительность HTTP (см. Ниже) или производительность рендеринга?

Вы больше не получаете преимущества кеширования

Собственно, если вы делаете это в файле CSS, он все равно будет кэшироваться. Разумеется, любые изменения CSS приведут к недействительности кеша.

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

Ответ 4

Вы больше не получаете преимущества кеширования

Будет ли это важно, зависит от того, насколько вы зависите от кеширования.

Не является ли base64 A LOT большим по размеру, чем размер файла PNG/JPEG?

Формат файла/алгоритм сжатия изображений один и тот же, я беру его, т.е. его PNG.

Используя Base-64, каждый 8-разрядный символ представляет 6 бит: поэтому двоичные данные разлагаются на отношение 8-к-6, то есть только около 35%.