Чи слід вставляти зображення як data / base64 в CSS або HTML

Щоб зменшити кількість запитів на сервері, я вставив деякі зображення (PNG & SVG) як BASE64 безпосередньо в css. (Автоматизовано в процесі збирання)

подобається це:

background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAFWHRTb2Z0d2FyZQBBZG etc...);

Це хороша практика? Чи є причини, щоб цього уникнути? Чи є якісь основні веб-переглядачі, які не мають підтримки URL-адреси даних?

Питання про бонус: чи є сенс робити це і для CSS & JS?

Це хороша практика? Чи є причини, щоб цього уникнути?

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

Він має ряд помітних недоліків:

• Не працює взагалі в IE6 та 7.

• Працює з ресурсами лише до 32 кб в IE8 . Це обмеження, яке застосовується після кодування base64. Іншими словами, не більше 32768 символів.

• Він зберігає запит, але замість нього роздуває HTML-сторінку! І робить зображення неможливими для кешування. Вони завантажуються щоразу, коли міститься сторінка або аркуш стилів.

• Кодування Base64 розширює розміри зображень на 33%.

• Якщо їх подають на ресурсі gzipped, data:зображення майже напевно становлять жахливу напругу на ресурсах сервера! Зображення традиційно дуже стисне для процесора, з дуже невеликим зменшенням розміру.

Тут, мабуть, загальні відповіді дозволяють припустити, що це не потрібно з ряду законних причин. Однак, все це, здається, нехтує поведінкою сучасних додатків та процесом побудови.

Це не неможливо (і насправді досить просто) розробити простий процес, який буде проходити через зображення папок і генерувати єдиний CSS з усіма зображеннями цієї папки.

Цей css буде повністю кешований і різко скоротить зворотні поїздки до сервера, що так само правильно підказує @MemeDeveloper одним із найбільших хітів продуктивності.

Звичайно, це злом. без сумніву. те саме, що спрайт - хак. У досконалому світі це не знадобиться, до цього часу можлива практика, якщо потрібно виправити:

1. Сторінка з декількома зображеннями, які не легко "сприймаються".
2. Повернення до серверів - це фактичне вузьке місце (думаю, мобільний).
3. швидкість (до рівня мілісекунд) дійсно така важлива для вашого випадку використання.
4. Вам не байдуже (як слід, якщо ви хочете, щоб мережа рухалася вперед) про IE5 та IE6.

мій погляд.

Це не вдала практика. Деякі браузери не підтримують URI даних (наприклад, IE 6 і 7) або підтримка обмежена (наприклад, 32 КБ для IE8).

Дивіться також цю статтю у Вікіпедії для отримання повної інформації про недоліки URI даних:

• Схема URI даних

Недоліки

• URI даних не кешуються окремо від документів, що містять їх (наприклад, CSS або HTML файли), тому дані завантажуються щоразу, коли містяться документи перезавантажуються.
• Вміст має бути перекодовано та повторно вбудовано щоразу, коли внесені зміни.
• Internet Explorer у версії 7 (приблизно 15% ринку станом на січень 2011 року) не має підтримки.
• Internet Explorer 8 обмежує URI даних максимальною довжиною 32 КБ.
• Дані включаються як простий потік, і багато середовищ обробки (наприклад, веб-браузери) можуть не підтримувати використання контейнерів (таких як multipart/alternativeабо message/rfc822) для забезпечення більшої складності, таких як метадані, стиснення даних або узгодження вмісту.
• URI-файли даних, кодовані Base64, на 1/3 більше, ніж їх двійковий еквівалент. (Однак цей наклад зменшується до 2-3%, якщо сервер HTTP стискає відповідь за допомогою gzip)
• URI даних ускладнюють програмне забезпечення для безпеки фільтрувати вміст.

Я використовував дані-урі близько місяця, і я просто перестав їх використовувати, оскільки вони зробили мої таблиці стилів абсолютно величезними.

Data-uri працюють в IE6 / 7 (вам просто потрібно подати файл mhtml цим браузерам).

Єдиною перевагою, яку я отримав від використання даних-урі, було те, що мої фонові зображення видавалися, як тільки було завантажено таблицю стилів, на відміну від поступового завантаження, яке ми бачимо інакше

Приємно, що у нас є ця методика, але я не буду її занадто сильно використовувати. Я радимо спробувати це, хоча б ви знали самі

Я б більше схильний використовувати CSS Sprites для комбінування зображень та збереження на запитах. Я ніколи не пробував техніку base64, але це, мабуть, не працює в IE6 та IE7. Також означає, що якщо якісь зображення змінюються, то, звичайно, вам доведеться відновити повністю втрачене, якщо, звичайно, у вас є декілька файлів CSS.

Я не маю уявлення про загальні найкращі практики, але я, наприклад, не хотів би бачити таку річ, якби міг у цьому допомогти. :)

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

Чи є причини, чому, на вашу думку, наразі надто багато запитів на сервер?

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

• Крихітна, тому що кодування Base64 збільшує розмір
• Часто використовується, тому що це виправдовує більший час початкового завантаження

Звичайно, потрібно пам’ятати про проблеми з підтримкою старих браузерів. Крім того, може бути хорошою ідеєю використовувати можливості фреймворку для автоматичного вбудовування зображень за допомогою таких URL-адрес, як ClientBundle GWT, або принаймні використовувати класи CSS замість того, щоб безпосередньо додавати його до стилю елемента.

Більше інформації зібрано тут: http://davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/