Пусте зображення. Що використовувати: Base64 vs 1x1 JPEG зображення


11

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

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

На даний момент я знайшов два варіанти вирішення цієї проблеми:

  1. Початковий src всіх зображень має бути URL-адресою порожнього 1x1 зображення
  2. Початковий src всіх зображень, який має бути базою даних 64, пусте зображення

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

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

Але для SEO?

Чи є якийсь інший варіант?


8
"Коли я використовую пусте зображення бази даних 64, воно показує стільки запитів, скільки кількість зображень на сторінці." - там щось трохи не так? Вся суть використання URI даних полягає в тому, що немає зовнішнього запиту HTTP. (Лише користувацькі агенти, які не розуміють URI даних, можуть запускати HTTP-запит.)
MrWhite

Якщо порожнє зображення буде більшим, ніж 1х1 пікс (я думаю, що воно є), я б рекомендував більш велике фонове зображення (10х10 пікс., 100х100 пкс), оскільки візуалізація буде швидшою .
totymedli

3
Нічого не використовувати? Ви можете створювати тег img динамічно, одночасно перетворюючи data-src у src. Замість того, щоб мати порожнє зображення з data-src, ви можете зберігати список зображень та генерувати тег за потреби.
the_lotus

@Pharap не працює, оскільки браузер завантажує зображення, навіть якщо вони приховані.
НевдоволенийGoat

Що б ви не вибрали для доставки вмісту, кодування його як png8, ймовірно, буде швидше, ніж JPEG.
symcbean

Відповіді:


12

Параметр зображення base64 слід використовувати там, де у вас буде лише дуже мала кількість зображень, і ви хочете усунути мережеві накладні отримання зображення з сервера. Однак, з того, що ви вказуєте у запитанні, я припускаю, що це може масштабувати велику кількість зображень. У цьому випадку я використовував би одне прозоре зображення 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 зображень на сторінці.
МП ПП

Або ви можете завантажити зображення в корінь свого веб-сайту і використовувати відносну URL-адресу, тому веб-сайт буде набагато меншим.
Хостинг NETCreator

3
gzip подбає про повторення, тому наявність на вашій сторінці 400 кодованих базових 64 зображень не буде коштувати більше пропускної здатності, ніж 400 URL-адрес зображень.
користувач2428118

3
@Aron Якщо ваша сторінка має величину 25,6 Мб (400 UI даних з довгими 82 байтами з 64 кБ між ними = 25 568 800 байт), у вас виникнуть великі проблеми, ніж турбуватися про 32,8 кБ базових зображень, кодованих base64.
користувач2428118

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 News , і знайдіть data:image/gif,base64


Ваше зображення велике. Перевірте коментар вище щодо 55-байтної версії.
Джошуа

1
Ця відповідь на StackOverflow із повідомленими тестами (травень 2014 р.) Показує, що вбудовування великої кількості (~ 1800) зображень у форматі 1px значно повільніше, ніж багаторазове посилання на одне й те саме зовнішнє зображення. Зовнішнє зображення запитується один раз і кешується, тоді як браузер повинен декодувати кожен URI даних окремо як частина процесу аналізу HTML - це, здається, є вузьким місцем. Здається, це дозволяє припустити, що URI даних має бути обмежено невеликою кількістю (малих) зображень.
DocRoot

@Joshua Хоча це зображення відображається правильно у моєму браузері (Firefox), його не можна відкрити деякими іншими програмами (наприклад, Paint), тому я б уникав його використовувати.
користувач2428118

2

У цей момент я знайшов два варіанти вирішення цієї проблеми: Початковий src всіх зображень повинен бути базою даних 64 пустим зображенням

Цей параметр вимагає не тільки сучасного веб-переглядача, але й може бути повільнішим на клієнтській стороні, оскільки для створення зображення браузер повинен базувати-64 декодувати дані зображення.

Початковий src всіх зображень має бути URL-адресою порожнього 1x1 зображення

Це нормально за умови, що порожня URL-адреса зображення для всіх слотів зображення є точно такою ж URL-адресою і що він має довгий термін служби кешу, визначений у заголовку HTTP "кеш-контроль". Проблема в цьому полягає в тому, що, коли завантажуються нові файли зображень, квадрати зображень підскочать до нового розміру, що може зробити досвід користувача не таким чудовим.

Майже ідеальна ідея така ...

Коли сторінка запускається, пред'явіть сітку з фіксованими розмірами полями, які вміщують кожне зображення. Це нормально, якщо вся сітка не вміщується на екрані. Потім створіть 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 впливало на продуктивність.
користувач2428118

Це також залежить від комп'ютерної системи. Якщо у клієнта все ще є старомодний комп'ютер, такий як пентий 1, можливо, це може бути хітом для продуктивності.
Майк

1

Образ, тому що ремонтопридатність.

На мій досвід, краще використовувати зображення. Це більш очевидно в фактичному коді і простіше запам’ятати. Я сумніваюся, ви запам'ятаєте закодовану рядок для прозорого зображення, і навіть якщо це зробити, ваші наступники / колеги.
Якщо ви повернетесь до цього коду через кілька тижнів, ви забули базу64.

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


Багато людей використовують сценарії для генерування базових значень 64, тому вимога запам’ятовувати такі значення є поза вікном, якщо OP не використовує лише набір HTML-файлів для представлення коду свого веб-сайту.
Майк

1

Як щодо приблизно 3 додаткових байтів, 0 додаткових запитів http та 0 додаткової довжини src img (або 0 незакріплених заповнювачів зображень даних). Чи можете ви використовувати пустий src для зображення?

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

І якщо вони мають altтеги, ви можете приховати їх від зображення помилки / помилки:

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

Показує: нічого. Злому тегу alt має невелику затримку FOUC від межі заповнення зображення. Можливо, це теж можна очистити.


2
Хоча порожній srcатрибут все-таки видасть помилки у валідаторі W3C (що, здається, викликає занепокоєння).
MrWhite

@ w3dk Так, це гарно, але потім знову дуже мало модернізацій.
dhaupin

Якщо ви хочете передати правила W3C, для src потрібно щось вказати, навіть якщо його URL-адреса повертає помилку 404. Я також рекомендую вказати значення атрибутів ширини та висоти для зображення, щоб користувачі спочатку бачили фактичні заповнювачі замість крихітних коробок, які надуваються наполовину в процесі завантаження.
Майк
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.