Давним-давно кожен сайт використовував для відображення тексту тільки такі шрифти, як Arial. Verdana. Garamond або Times New Roman. тому що тільки ці шрифти напевно були встановлені майже на будь-якому комп'ютері. Але ці часи позаду. Веб-шрифти поширюються по всьому інтернету, але ми все ще толком не знаємо, як завантажувати їх ефективніше.
- Використовуємо шрифти тільки в форматі woff
- Інші браузери отримує старі «безпечні» шрифти
- Завантажуємо шрифт в бінарному форматі і оптимізуємо його
- Віддаємо шрифти самі
- Віддаємо їх в якості CSS-файлів - URIs з закодованими в base64 даними
- Якщо у користувача немає шрифту, завантажуємо його асинхронно і зберігаємо в localStorage
- Інакше завантажуємо його з localStorage без звернення до сервера.
- Радіємо, бо ваш сайт відображається набагато швидше, а ваші користувачі отримують набагато більше зручності
Для тих, хто все ще читає, ось мої роз'яснення, щодо верхніх пунктів.
Якщо ви не особливо довіряєте цій оптимізації, я зробив дві демо-сторінки. Просто протестуйте їх і погляньте на те, як вони завантажуються, що блокується, а що ні.
1. Підтримка браузерами
Згідно caniuse. 84% використовуваних браузерів підтримують формат woff. Винятком є старі браузери - IE8 і вбудовані браузери старих андроїдів. Отже, цілком достатньо надати веб-шрифти тільки сучасним браузерам з підтримкою формату woff. А старі браузери можуть задовольнятися запасним рішенням у вигляді шрифту Arial, наприклад. А також користувачі будуть вам вдячні за те, що ваш сайт швидше відображається в браузері. Просто постарайтеся знайти те, що краще підходить для дизайну вашого сайту.
2. Не використовуйте зовнішні джерела шрифтів, такі як Google Fonts або Typekit
Вони або викликають багато додаткові блокують запити, або подразнюючу миготіння під час асинхронної завантаження. Трохи пізніше ми побачимо набагато кращі способи завантаження веб-шрифтів.
3. Необхідність ліцензії
Уважніше вибирайте шрифт, який ви завантажуєте собі. На жаль, не всі ліцензії дозволяють це робити. Але на щастя, багато дозволяють - як ті, що з відкритим кодом. Наприклад, такі як Open Sans або Source Sans Pro. Коли ви виберете шрифт, завантажуйте «виконавчі» файли (форматів otf або ttf)
4. Оптимізація, зменшення розміру, генерація CSS
Заходьте на: генератор веб-шрифтів Font Squirrel.
Важливо вибрати правильний варіант, щоб згенерувати CSS-файл. який містить шрифти, закодовані в base64. Це буде файл, який вам дійсно потрібен.
5. Віддача CSS-файлу
Файл може бути досить великим (аж до 100-300кб) в залежності від вибору кодувань і інших опцій. Тому важливо правильно стиснути файл за допомогою gzip і встановити суворе кешування під час його отримання користувачами.
На щастя для ваших користувачів, вам буде потрібно віддати їм цей файл тільки один раз. У перший раз, коли у користувача не виявиться цього шрифту, браузер завантажить його асинхронно і помістить в localStorage. В цей час користувачі з повільним з'єднанням можуть бачити, як браузер перемальовує «запасні» шрифти в ваші веб-шрифти, але це відбувається не більше одного разу. А більшість користувачів взагалі нічого не помітять.
Починаючи з другої завантаження сторінки, ви будете завантажувати тільки CSS-файл з localStorage. Який завантажується досить швидко (5-50мс). Його користувачі не побачать навіть мерехтіння, тому що всі дії синхронні, але зажадають всього пари мілісекунд.
6. Покажіть мені код
Після того, як ми зберегли файл в localStorage, цим методом необхідний код тільки на клієнтській стороні. Ось візьміть:
7. Чого ми домоглися
- Усунули як мінімум один, а швидше за все безліч блокуючих запитів
- Максимум одне мерехтіння у користувача, під час заміни «запасного» шрифту на веб-шрифт (перші відвідини, перший запит)
- Прискорили час відображення на першій сторінці запиту
- Поліпшили показники швидкості в Google Page Speed Insights і WebPageTest.org
8. Побачити це в дії
Користувач Twitter'a @Kseso, поінформував мене про інший підхід, який також отримує 99/100 балів в Google Page Speed Insights.
Я виступаю проти цього підходу, тому що він надовго затримує відображення тексту. Тому давайте більш детально расссмотрім, що відбувається в цьому методі.
- Ми відразу ж визначаємо сімейство шрифтів в звичайному HTML-файлі:
- Браузер не буде отримувати файл шрифту до тих пір, поки не переконається, що цей шрифт взагалі знадобиться де-небудь на сторінці.
- Браузер дочекається остаточного побудови DOM і CSSOM
- Браузер почне отримувати файл шрифту з Google Fonts (зауважте, що для fonts.gstatic.com потрібно зайвий DNS-запит).
Ця шкала часу показує, як браузер починає завантажувати файл шрифту тільки перед подією DOMContentLoaded.
- Тільки IE почне відображення негайно з «запасними» шрифтами
- Firefox і Chrome35 + чекають повного завантаження шрифту протягом трьох секунд (а потім відображають «запасний» шрифт)
- Safari і Chrome до 35-ї версії чекають повного завантаження шрифту без будь-яких таймаутів.
Тому на повільних з'єднаннях ви затримаєте відображення текстового вмісту аж до 3 секунд в більшості браузерів. У гіршому випадку, якщо ваш шрифт занадто довго вантажиться (наприклад, через погане мобільного з'єднання), користувачі Safari взагалі не побачать текстового вмісту і просто покинуть вашу сторінку. Користувачі можуть бачити білу сторінку до спрацьовування таймаута.
Більше інформації можна знайти в блозі Іллі Григорик.
Так само я створив тестову сторінку. де ви можете перевірити це самі.
P.S. Це теж може бути цікаво:
Base64 можна застосовувати тільки тоді, коли шрифт точно повинен бути на сторінці. Мабуть, про це і писав "Kseso". Інакше файл шрифту завантажиться в будь-якому випадку, використовується він на сторінці чи ні. При цьому base64 важить зазвичай більше оригінального файлу woff.
Як я зрозумів, Адам напирає на те, що власне грузиться файл буде тільки для першої сторінки, а в подальшому буде братися навіть не з кеша, а з localStorage (взагалі без запиту до сервера і очікування 304-го відповіді, тобто практично миттєво). Так що навіть якщо він не знадобиться відразу, то як тільки знадобиться, він буде доступний відразу, не викликаючи ні секунди очікування (особливо неприємного в вебкітятах, де під час цього очікування текст виводиться білим по білому). А різниця в розмірах файлу досить непогано нівелюється gzip-ом.
Особисто мене ці аргументи швидше переконують :)
Тоді треба бути точно впевненим, що користувач дійде до сторінки шрифтом.
Не минуло й півроку з останньої зміни робочого процесу W3C, як керівництву Консорціуму надійшла пропозиція застосувати нарешті цей новий процес на ділі. І списати вже неактуальні специфікації HTML в музей, щоб вони не заплутували розробників, «прикидаючись» актуальними.
Ще один модуль CSS, про який ми розповідали, непомітно дозрів до статусу, з якого W3C радить починати повсякденне використання новинок. Властивість contain дозволяє обмежувати зміни дерева відтворення, перерисовку CSS-боксів і зміни їх розмірів в межах елемента. Тому воно так важливо ...
ДАЛІ
З Парижа (на фото), де недавно проходила зустріч робочої групи CSS, прилетіла цікава новина: властивості grid-row-gap і grid-column-gap, а також їх скорочення grid-gap ...