Кодування Base64; Майстер CSS; Оптимізація веб-продуктивності
Автор Гаррі Робертс на майстрі CSS.
Це перша публікація з двох частин. Прочитайте частину 2.
Видатні поради щодо ефективності, що існували кілька років тому, просто заявляли, що нам слід «зменшити кількість запитів, які ми робимо». Незважаючи на те, що це, загалом, цілком слушна порада, вона не позбавлена застережень. Ми можемо зробити так, щоб сторінки завантажувались набагато швидше, елегантно розподіляючи наші ресурси за кількома більш продуманими запитами, а не за меншими.
Однією з рекламованих "найкращих практик", породжених цією порадою, було прийняття кодування Base64: акт взяття зовнішнього ресурсу (наприклад, зображення) та вбудовування його безпосередньо в текстовий ресурс, який би його використовував (наприклад, таблиця стилів). Результатом цього є те, що ми зменшуємо кількість HTTP-запитів, а обидва ресурси (наприклад, таблиця стилів та зображення) надходять одночасно. Звучить як сон, так?
На жаль, ресурси кодування Base64 - це дуже анти-шаблон 1. У цій статті я сподіваюся поділитися деякою ідеєю щодо критичної оптимізації шляху, Gzip і, звичайно, Base64.
Давайте подивимось якийсь код
Причиною того, що мене спонукало написати цю статтю, є те, що я щойно проводив аудит ефективності для клієнта і натрапив на ті самі проблеми, які я збираюся окреслити. Це фактична таблиця стилів від фактичного клієнта: речі анонімні, але це цілком реальний проект.
Я провів швидкий мережевий профіль на сторінці і виявив лише одну таблицю стилів (що є певним чином хорошим, оскільки ми точно не хочемо бачити 12 запитів таблиці стилів), але ця таблиця стилів з’явилася колосальною 925 тис після декомпресії та розширення. Фактична кількість байтів, що надходить через провід, була значно меншою, але все ще дуже великою - 232 КБ.
Як тільки ми починаємо бачити таблиці стилів такого розміру, ми повинні почати панікувати. Я був відносно впевнений - навіть не потрібно дивитись - що тут буде якийсь Base64. Це не означає, що я очікував, що це буде єдиним фактором (плагіни, відсутність архітектури, застарілі дані тощо, ймовірно, зіграють свою роль), але великі таблиці стилів, як правило, свідчать про Base64. Ще:
- Base64 чи ні, 925 тис. CSS жахливо.
- Зменшення його зменшує лише до 759K.
- Gzipping зводить нас до просто 232K. Точно такий же код стиснутий на 693K.
- 232K над дротом все ще жахливий.
Для того, щоб проаналізувати таблицю стилів такого розміру, потрібно очей поливати 88 мс. Передача даних через мережу - це лише початок наших проблем:
Я попередньо сформулював файл 2, зберіг його на своїй машині, пропустив через CSSO, а потім запустив цей мініфікований висновок через Gzip на звичайному рівні. Ось як я дійшов до цих цифр, і я залишився дивитись на це:
Наступне, що потрібно було зробити, - це побачити, скільки цих байтів було з кодованих активів Base64. Щоб це вирішити, я просто (і досить грубо) видалив усі рядки/декларації, що містили data: strings (: g/data:/d 3 для користувачів Vim, які читають це). Більша частина цього кодування Base64 стосувалася зображень/спрайтів та кількох шрифтів. Потім я зберег цей файл як no-base64.css і провів ту ж мініфікацію та Gzipping над цим:
У нашому нестисненому CSS нам вдалося втратити цілих 217 тис. Base64. Це все ще залишає нам тривожну кількість CSS (708K досить громіздко), але нам вдалося позбутися добрих 23,45% нашого коду.
Де все справді стає дивовижним, хоча це після того, як ми зішпартували те, що залишилось. Нам вдалося перейти від 708K до всього 68K по дроту! Це економія 90,39%. Ого.
Збереження Gzip…
Gzip неймовірний! Це, мабуть, найкращий інструмент захисту користувачів від розробників. Нам вдалося зробити 90% економії на дроті, просто стиснувши наш CSS. З 708K до 68K безкоштовно.
... іноді
Однак над цим Gzip працює не кодовану версію Base64. Якщо ми подивимось на оригінальний CSS (CSS з кодуванням Base64), ми виявимо, що ми лише заощадили 74,91%.
| Так | 925 тис | 232 тис | 74,91% |
| Ні | 708 тис | 68 тис | 90,39% |
Різниця між двома варіантами - приголомшливі 164 тис. (70,68%). Ми можемо надіслати на 164 тис. CSS менше, просто перемістивши ці активи кудись більш доцільно.
Base64 жахливо стискає. Наступного разу, коли хтось спробує все, так, але Gzip ... вибачте, скажіть їм про це (якщо вони намагаються виправдати Base64, тобто).
Так чому Base64 такий поганий?
Гаразд, отже, ми цілком зрозуміли, що Base64 збільшує розмір файлу таким чином, що Gzip насправді не може нам допомогти, але це лише одна невелика частина проблеми. Чому ми так боїмося цього збільшення розміру файлів? Одне зображення може важити значно більше 232 тис., Тож чи не краще нам почати там?
Гарне запитання, і я радий, що ви згадали зображення ...
Потрібно поговорити про зображення
Для того, щоб зрозуміти, наскільки поганий Base64, нам спочатку потрібно зрозуміти, наскільки хороші зображення. Суперечлива думка: зображення не настільки погані для продуктивності, як ви думаєте.
Так, зображення є проблемою. Насправді вони найбільше сприяють збільшенню кількості сторінок. Станом на 2 грудня 2016 року зображення складають близько 1623 тис. (Або 65,46%) середньої веб-сторінки. Це робить нашу таблицю стилів 232K схожою на краплю в морі для порівняння. Однак існують принципові відмінності між тим, як браузери обробляють зображення та таблиці стилів: