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

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

Кодирование 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 мс.

(Проверено с помощью Chromium 34)

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

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

Имеет ли это значение, зависит от того, насколько вы зависите от кэширования.

Другая (возможно, более важная) вещь заключается в том, что если есть много изображений, браузер не будет получать их одновременно (т. е. параллельно), а только по нескольку за раз, поэтому в итоге протокол будет чатти. Если есть некоторая сквозная задержка в сети, то количество изображений, разделенных на несколько изображений за раз, умноженное на сквозную задержку для каждого изображения, приводит к заметному времени до загрузки последнего изображения.

Разве base64 не НАМНОГО больше размера файла PNG/JPEG?

Формат файла/алгоритм сжатия изображения тот же, я так понимаю, т.е. это PNG.

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

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

Дайте определение «быстрее». Вы имеете в виду производительность HTTP (см. ниже) или производительность рендеринга?

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

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

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