Пустое изображение Что использовать: Base64 vs 1x1 JPEG изображение

11

Я создаю веб-сайт, и я хочу сделать HTTP-запросы как можно меньше для лучшей скорости сайта и SEO. Страница, которую я только что создал, показывает изображения при прокрутке (изображения имеют атрибут data-scr, который преобразуется в src, когда пользователь прокручивает вниз на соответствующем изображении).

Поскольку все изображения имеют data-srcатрибут вместо src, W3C показывает мне ошибки.

На данный момент я нашел два варианта, чтобы решить эту проблему:

  1. Исходный источник всех изображений должен быть URL пустого изображения 1x1
  2. Исходный источник всех изображений должен быть базой данных 64 пустое изображение

Когда я использую URL пустого изображения 1x1, тогда (протестировано с tools.pingdom.com) он показывает 1 HTTP-запрос. Когда я использую пустое изображение из базы данных 64, тогда оно показывает столько же запросов, сколько количество изображений на странице.

Какой из них является более эффективным, поскольку веб-сайт работает быстрее и делает меньше HTTP-запросов? (предположим, что пользователь загружает веб-страницу со скоростью интернета 14,4 кбит / с - первая скорость интернета).

Но для SEO?

Есть ли другой вариант?

MM PP
источник
8
«Когда я использую пустое изображение из базы данных 64, тогда оно показывает столько же запросов, сколько количество изображений на странице». - там что-то не так? Весь смысл использования data-URI заключается в том, что нет внешнего HTTP-запроса. (Только пользовательские агенты, которые не понимают URI данных, могут
запускать
Если пустое изображение будет больше, чем 1x1 px (я думаю, это так), я бы порекомендовал большее фоновое изображение (10x10 px, 100x100 px), потому что рендеринг будет быстрее .
Тотимедли
3
Использовать никто? Вы можете создать тег img динамически одновременно с конвертацией data-src в src. Вместо того, чтобы иметь пустое изображение с data-src, вы можете хранить список изображений и генерировать тег при необходимости.
the_lotus
@Pharap, который не работает, потому что браузер загрузит изображения, даже если они скрыты.
Рассерженная шлюха
Что бы вы ни выбрали для доставки контента, кодирование его в формате png8, вероятно, будет быстрее, чем JPEG.
Symcbean

Ответы:

12

Опцию base64 image следует использовать там, где у вас будет только очень небольшое количество изображений, и вы хотите устранить сетевые накладные расходы при получении изображения с сервера. Однако из того, что вы указываете в вопросе, я предполагаю, что это может масштабироваться до большого количества изображений. В этом случае я бы использовал одно прозрачное изображение размером 1px x 1px с сервера с большим временем жизни кеша, так как оно будет выбрано с сервера, а затем кэшировано в браузере и любых промежуточных прокси-серверах.

Например, размер этого изображения будет около 95 байт ( https://commons.wikimedia.org/wiki/File:1x1.png ), для строки изображения в кодировке base64 вы обнаружите, что размер будет на уровне этого изображения размер файла, но будет повторяться для каждого изображения, к которому вы добавляете его.

Для 2-5 изображений размер и скорость будут незначительными и уменьшат трафик сервера, исключив одну целую выборку, но, более того, размер страницы станет слишком большим, что повлияет на время загрузки и, в свою очередь, на рейтинг SEO.

Крис Рутерфурд
источник
6
Пустой base64 изображение может иметь 55 байт: data:image/gif;base64,R0lGODlhAQABAAAAACwAAAAAAQABAAA=. Если URL-адрес изображения немного длиннее (например, example.com/templates/template-name/files/1x1.png ), будет рекомендовано изображение base64, поскольку вы не выполняете HTTP-запросы и оно меньше в байтах чем URL изображения (повторяется для каждого изображения на странице) + размер внешнего изображения.
хостинг NETCreator
@ NETCreatorHosting-WebDesign Спасибо за ваш комментарий. Я сравнил размер веб-сайта при использовании изображения base64 и внешнего изображения, а размер меньше при использовании изображения base64. Я использую около 40 изображений на странице.
MM PP
Или вы можете загрузить изображение в корень вашего сайта и использовать относительный URL, чтобы сайт был намного меньше.
хостинг NETCreator
3
gzip позаботится о повторениях, поэтому наличие 400 кодированных в base-64 изображений на вашей странице не будет стоить больше пропускной способности, чем 400 URL-адресов изображений.
user2428118
3
@Aron Если ваша страница имеет размер 25,6 МБ (400 URI данных длиной 82 байта с 64 КБ между ними = 25 568 800 байт), у вас есть более серьезные проблемы, связанные с 32,8 КБ изображений в кодировке base64.
user2428118
5

Обязательно используйте URI данных, если вам не нужна поддержка IE <8. ( Поддержка браузера .)

Встраивание множества крошечных изображений непосредственно в HTML может выглядеть так, как если бы оно занимало большую полосу пропускания, чем прямая ссылка на них, но увеличение будет уменьшено с помощью gzip ; единственная разница в размере страницы будет заключаться в разнице в длине между одним URI данных пустого изображения и одним URL-адресом изображения на вашем сервере. Пустой GIF может быть как 43 байт. База 64-кодирована, это 82 байта. Нет способа, который когда-либо будет работать хуже, чем HTTP-запрос> 500 байт, ответ такого же размера, и тогда я даже не принимаю во внимание размер пакета TCP и другие издержки.

Вот базовое 64-байтовое 43-байтовое GIF-изображение:

data:image/gif;base64,R0lGODlhAQABAIAAAP///////yH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==

Что касается SEO, взгляните на исходный код сайта Google, например, Новости Google , и выполните поиск data:image/gif,base64

user2428118
источник
Ваше изображение большое. Проверьте комментарий выше для 55-байтовой версии.
Джошуа
1
Этот ответ на StackOverflow с отчетными тестами (май 2014 г.), по- видимому, показывает, что встраивание большого количества (~ 1800) изображений с разрешением 1px значительно медленнее, чем повторное связывание с одним и тем же внешним изображением. Внешнее изображение запрашивается один раз и кэшируется, в то время как браузер должен декодировать каждый data-URI отдельно как часть процесса синтаксического анализа HTML - это может показаться узким местом. Казалось бы, это предполагает, что данные URI должны быть ограничены небольшим количеством (маленьких) изображений.
DocRoot
@Joshua Хотя это изображение правильно отображается в моем браузере (Firefox), оно не может быть открыто другими программами (например, Paint), поэтому я бы не использовал его.
user2428118
2

На данный момент я нашел два варианта решения этой проблемы: исходный источник всех изображений должен быть базой данных 64 пустое изображение

Эта опция не только требует современного браузера, но она может быть медленнее на стороне клиента, так как браузер должен base-64 декодировать данные изображения, чтобы получить изображение.

Исходный источник всех изображений должен быть URL пустого изображения 1x1

Это нормально, при условии, что пустой URL-адрес изображения для всех слотов изображений является точно таким же URL-адресом и что он имеет длительное время жизни кэша, определенное в заголовке HTTP «cache-control». Проблема заключается в том, что при загрузке новых файлов изображений квадраты изображений переходят к новому размеру, что может сделать работу пользователя не такой замечательной.

Почти идеальная идея заключается в следующем ...

Когда страница запускается, представьте сетку с полями фиксированного размера, которые могут вместить каждое изображение. Это нормально, если вся сетка не помещается на экране. Затем создайте javascript, который выполняется после загрузки HTML, и в этом javascript создайте новый элемент изображения и прикрепите его к каждой ячейке сетки, затем установите источник изображения в правильный файл изображения. Делайте это, пока не заполнится первый экран. затем обнаружите прокрутку в javascript, а затем, когда прокрутка произойдет, повторите описанный выше процесс для новых ячеек.

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

Вот шаблон HTML для использования, если вы хотите идти быстрым путем. Только два запроса сделаны. HTML-код и одно изображение. В этом коде я предполагаю, что каждое изображение с листа имеет ширину 100 пикселей и высоту 200 пикселей и что каждое изображение идеально выровнено рядом друг с другом без пропусков.

<html>
<head>
<style type="text/css">
#imagegrid {background-color: black; background-image:url('http://example.com/url/to/imagesheet.jpg');}
A {display:block;width:100px;height:200px;margin:10px;float:left;}
#image1{background-position: 0px 0px}
#image2{background-position: 100px 0px}
#image3{background-position: 200px 0px}
...
#imageN{background-position: XXXpx 0px}
</style>
</head>
<body>
<div id="imagegrid">
<a href="image_one.htm" id="image1"></a>
<a href="image_two.htm" id="image2"></a>
<a href="image_three.htm" id="image3"></a>
...
<a href="image_N.htm" id="imageN"></a>
</div>
</body>
</html>

В своем коде я добавил 3 точки. Это означает, что вы можете продолжать добавлять изображения, увеличивая числа и увеличивая положение на 100 каждый раз, если ваш спрайт-лист содержит только одну строку изображений. Кроме того, в некоторых браузерах, таких как Opera, вам может понадобиться добавить знак минуса перед значениями положения фона, чтобы заставить их работать.

Майк
источник
2
Если размер ваших изображений не достигнет половины гигабайта, то невозможно, чтобы декодирование изображения с помощью base64 оказало заметное влияние на производительность.
user2428118
Это также зависит от компьютерной системы тоже. Если у клиента все еще есть старомодный компьютер, такой как Pentium 1, это может привести к снижению производительности.
Майк
1

Изображение, потому что ремонтопригодность.

По моему опыту, лучше использовать изображение. Это более очевидно в реальном коде и легче запомнить. Я сомневаюсь, что вы помните закодированную строку для прозрачного изображения, и даже если вы это сделаете, ваши преемники / коллеги.
Если вы вернетесь к этому коду через несколько недель, вы забудете base64.

Поддерживать код будет намного проще, если вы используете изображение, минимальный профессионал не справится с этим.

Мартейн
источник
Многие люди используют сценарии для генерации значений base-64, поэтому требование запоминать такие значения выходит за рамки, если OP не использует только набор HTML-файлов для представления кода своего веб-сайта.
Майк
1

Как насчет всего ~ 3 дополнительных байта, 0 дополнительных запросов http и 0 дополнительных длин img src (или 0 не кешированных заполнителей для данных данных). Можете ли вы использовать пустой SRC для изображения?

<img src data-src="banannanannas.jpg" />

И если у них есть altтеги, вы можете скрыть их от изображения ошибки / сбоя:

<img src data-src="banannanannas.jpg" onerror="this.alt=''" alt="some desc" />

Отображает: ничего. Взлом метки alt имеет небольшую задержку FOUC от границы заполнителя изображения. Возможно, это тоже можно убрать.

dhaupin
источник
2
Хотя пустой srcатрибут все равно выдаст ошибки в W3C Validator (что, похоже, является проблемой).
MrWhite
@ w3dk Да, это отстой, но, опять же, очень мало модернизаций.
Дхаупин
Если вы хотите передать правила W3C, необходимо указать что-то для src, даже если это URL, который возвращает ошибку 404. Я также рекомендовал бы указать значения атрибутов width и height для изображения, чтобы пользователи сначала видели фактические заполнители, а не крошечные прямоугольники, которые надуваются в процессе загрузки.
Майк