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

Немного загадочно, но это то, что я хотел бы:

Legos!

37
задан Tim 15 October 2009 в 21:33
поделиться

3 ответа

'Faster' is a hard thing to answer because there are many possible interpretations and situations:

Base64 encoding will expand the image by a third, which will increase bandwidth utilization. On the other hand, including it in the file will remove another GET round trip to the server. So, a pipe with great throughput but poor latency (such as a satellite internet connection) will likely load a page with inlined images faster than if you were using distinct image files. Even on my (rural, slow) DSL line, sites that require many round trips take a lot longer to load than those that are just relatively large but require only a few GETs.

If you do the base64 encoding from the source files with each request, you'll be using up more CPU, thrashing your data caches, etc, which might hurt your servers response time. (Of course you can always use memcached or such to resolve that problem).

Doing this will of course prevent most forms of caching, which could hurt a lot if the image is viewed often - say, a logo that is displayed on every page, which could normally be cached by the browser (or a proxy cache like squid or whatever) and requested once a month. It will also prevent the many many optimizations web servers have for serving static files using kernel APIs like sendfile(2).

Basically, doing this will help in certain situations, and hurt in others. You need to identify which situations are important to you before you can really figure out if this is a worthwhile trick for you.

44
ответ дан 27 November 2019 в 04:33
поделиться

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

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

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

5
ответ дан 27 November 2019 в 04:33
поделиться

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

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

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

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

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

5
ответ дан 27 November 2019 в 04:33
поделиться
Другие вопросы по тегам:

Похожие вопросы: