2009-02-07 1 views
26

Так что я работаю над чем-то в php, где мне нужно получить мои изображения из базы данных sql, где они будут закодированы в base64. Скорость отображения этих изображений имеет решающее значение, поэтому я пытаюсь выяснить, будет ли она быстрее превращать данные базы данных в файл изображения, а затем загружать ее в браузере или просто отбирать необработанные данные base64 и использовать:Base 64 encode vs загрузка файла изображения

<img src="data:image/jpeg;base64,/9j/4AAQ..." /> 

Это поддерживается в FireFox и других браузерах Gecko.

Так что, чтобы повторить, было бы быстрее передать фактический файл изображения или код base64. Будет ли потребоваться меньше HTTP-запроса при использовании ajax для загрузки изображений?

Изображения будут не более 100 пикселей.

+1

Является ли это одним и тем же статическим изображением снова и снова?Тогда есть методы, чтобы отправлять только одно изображение, а css показывает только его часть. – some

+1

@ some: CSS спрайты, вероятно, будут полезны здесь. – Piskvor

ответ

18

Ну, я не согласен ни с кем из вас. Бывают случаи, когда вы загружаете все больше и больше изображений. Не все страницы содержат 3 изображения. На самом деле я работаю над сайтом, где вы загружаете более 200 изображений. Что происходит, когда 100000 пользователей запрашивают 200 изображений на очень загруженном сайте. Диски сервера, возвращающие изображения, должны разрушаться. Еще хуже, что вы должны сделать так много запросов на сервер, а не на base64. Для большого количества эскизов я предпочел бы представление base64, предварительно сохраненное в базе данных. Я нашел решение и сильную аргументацию в http://www.stoimen.com/blog/2009/04/23/when-you-should-use-base64-for-images/. Парень действительно в этом случае и сделал несколько тестов. Я был впечатлен и сделал свои тесты. Реальность такова, как она говорит. Для большого количества изображений, загруженных на одну страницу, один ответ с сервера действительно полезен.

+13

Парень, которого вы упоминаете, кажется, говорит, что его изображения имели 2 МБ (мегабайт) при подаче с диска и доходили до 45 КБ (килобайт) при подаче в линию. Это само по себе делает его дело довольно сомнительным. – Piskvor

+0

В целом, я проверил, что кодировка base64 фактически увеличивает размер. Если этот парень не сделал компрессию – Richeek

23
  • Кодировка Base64 делает файл более крупным и, следовательно, более медленным для передачи.
  • Включая изображение на странице, его нужно скачивать каждый раз. Внешние изображения обычно загружаются только один раз, а затем кэшируются браузером.
  • Он не совместим со всеми браузерами
+1

также, base64 декодирование медленное. –

+0

также есть альтернатива слияния миниатюр изображений на более крупные изображения, а затем представлены только соответствующие части с использованием чистого css. Таким образом, необходимы 2 запроса - страница и 1 изображение. Изображения могут быть восстановлены, как только будет достигнут предел для каждой строки с разбивкой по страницам. К сожалению, это не относится к содержимому, доступному для поиска. – too

+0

@GaryRichardson Я могу это подтвердить. Особенно на телефонах. – JedatKinports

1

Как правило, используя кодирование base64 собирается увеличить размер в байтах примерно 1/3. Из-за этого вам придется перемещать 1/3 байта из базы данных на сервер, а затем перемещать эти лишние одинаковые 1/3 байта по проводу в браузер.

Конечно, по мере увеличения размера изображения указанные выше накладные расходы будут пропорционально увеличиваться.

Это, как говорится, я думаю, что это хорошая идея, чтобы сменить файлы на свои байтовые представления в db и передать их.

3

Не думаю, что data:// работает в IE7 или ниже.

Когда изображение запрашивается, вы можете сохранить его в файловой системе, а затем выполнить его с тех пор. Если данные изображения в базе данных меняются, просто удалите файл. Подавайте его из другого домена, также как img.domain.com. Вы можете получить все преимущества последних изменений или электронных тегов бесплатно с вашего веб-сервера без необходимости запуска PHP, если вам тоже не нужно.

Если вы используете Apache:

# If the file doesn't exist: 
RewriteCond %{REQUEST_FILENAME} !-f 
RewriteRule ^/(image123).jpg$ makeimage.php?image=$1 
+1

Anyways IE Sucks! –

+0

Я остановился, используя этот подход, чтобы не допустить, чтобы пользователь не имел доступа к некоторому файлу изображения. Изображение может содержать конфиденциальную информацию. Не сказать, что это бас, но в каком-то исключении вы хотите этого избежать. –

0

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

Запрет всего этого, когда вы запрашиваете данные, проверяете, было ли это последнее изменение, затем записывайте его на диск и оттуда оттуда. Вы хотите удостовериться, что вы уважаете заголовок If-Modified-Since, чтобы не передавать данные без необходимости.

Если вы не можете записать на диск или какой-либо другой кэш, то было бы самым быстрым сохранить его в виде двоичных данных в базе данных и выпустить его. В этом случае поможет настройка размеров буфера.

3

Зачем восстанавливать изображение снова и снова, если оно не будет изменено.Гипотетически, даже если есть 1000 различных возможных изображений, которые будут показаны на основе 1000 различных условий, я все же думаю, что 1000 изображений на дисках лучше. Помните, что изображения на основе дисков могут кэшироваться браузером и сохранять пропускную способность и т. Д.

1

Чтобы ответить на первый вопрос, я провел тест, измеряющий изображения JPEG 400x300 пикселов точек в 96 PPI:

base64ImageData.Length 
177732 

bitmap.Length 
129882 
2

Это очень быстро и простое решение. Хотя размер изображения увеличится примерно на 33%, использование base64 значительно сократит количество HTTP-запросов.

Изображения Google и изображения Yahoo используют base64 и служат изображениям inline. Проверьте исходный код, и вы его увидите.

Конечно, есть недостатки в этом подходе, но я считаю, что выгоды перевешивают затраты. Недостатки, которые я нашел, находятся в медленных устройствах. Например, в iPhone 3GS изображения, обслуживаемые изображениями Google, очень медленны для рендеринга, так как изображения выходят из сервера и должны быть несжаты в браузере. Таким образом, если у клиента есть медленное устройство, он немного пострадает при визуализации изображений.

0

Я использовал изображения base64 один или два раза для значков (10x10 пикселей или около того).

Base64 изображения плюсы:

  • компактный - у вас есть один файл. также, если файл сжат, изображение base64 сжимается почти до размера обычного изображения.
  • страница извлекается по одному запросу.

Base64 изображения минусы:

  • быть реалистичным, вы, вероятно, необходимо использовать обработчик сценариев (например PHP) на всех страницах, который содержит изображение.
  • Если изображение изменено, все кэшированные страницы должны быть повторно загружены.
  • Поскольку изображение является встроенным, вы не можете использовать веб-сервер CDN или статического контента.

Нормальные изображения плюсы:

  • , если вы будете использовать протокол SPDY, по крайней мере теоретическая, страница + изображения + CSS будет загружаться с одного запроса тоже.
  • вы можете установить срок действия изображения, поэтому контент будет кэшироваться из браузеров.