З 2017 року Google змінив політику оцінювання швидкості завантаження сторінок. Раніше бали нараховували за виконання рекомендацій, які інструмент показував після аудиту: стиснув зображення, CSS і JS, позбувся ресурсів, що блокують рендеринг, — молодець, пункти виконано, бали набрано. Тепер інструмент вимірює фактичну швидкість завантаження, момент першої появи контенту й те, як швидко користувач може почати взаємодіяти зі сторінкою. За новими критеріями більшість сайтів просіла за показниками, тож ми провели низку заходів, щоб повернути оцінки сайтів замовників у «зелену» зону.
Що змінилося в оцінці Google
Різниця між старою та новою логікою підрахунку принципова: раніше вимірювали старанність, тепер — результат, який бачить жива людина з живим пристроєм і живим каналом зв'язку.
Як було до 2017 року
Бали нараховували за виконання рекомендацій, які інструмент показував після аудиту. Стиснув зображення, CSS і JS, позбувся ресурсів, що блокують рендеринг сторінки, — пункт закрито, бали зараховано. За такого підходу набрати «зелену зону» було неважко.
Як стало зараз
Інструмент вимірює актуальну швидкість завантаження сторінки, першу появу контенту й те, як швидко користувач може почати взаємодіяти зі сторінкою. Формальне виконання пунктів зі звіту саме собою вже нічого не гарантує.
CSS і JS: головні ресурси, що блокують відображення
Найбільшу просадку за швидкістю дають скрипти, зображення та CSS — саме вони є ресурсами, що блокують відображення сторінки.
Добрий приріст продуктивності дало підключення JS через тег <script> з атрибутами async і defer, коли завантаження скриптів відбувається разом із завантаженням сторінки, а розбір і виконання — після.
Але тут варто розуміти, з яким саме скриптом ми маємо справу. Перед тим як вішати атрибути, перевіряємо три речі:
- чи самодостатній цей скрипт;
- чи є в нього залежності від інших скриптів;
- чи покладається він на повністю розібраний DOM.
Другий момент — підключення засобами фреймворка
Більшість скриптів підключається методами самого фреймворка: у корпоративних CMS для цього передбачено власну конструкцію. За такого підключення ми отримуємо всі «плюшки» — автоматичне об'єднання скриптів, стиснення й підключення gzip-версії скрипта, якщо відповідні опції увімкнено в адмінпанелі, а сервер налаштовано з можливістю віддавати .gz файли.
Підключаючи скрипти через тег <script>, ми цих переваг позбавляємося. Рішення — CompressionWebpackPlugin: він створить стиснуту gzipped-копію JS-білду поряд з основною. Результат — файли, стиснуті більш ніж утричі.
Що ще варто зробити з CSS і JS
- підключати JS і CSS, які використовуються лише на конкретних сторінках, якщо така можливість є;
- мінімізувати CSS і JS — це обов'язкова умова, а не побажання;
- за можливості робити відкладене завантаження зовнішніх скриптів.
У сумі асинхронне підключення скриптів додало близько 15 балів у PageSpeed, а мінімізація CSS і JS — ще 12.
Підключення тільки потрібних модулів
Бібліотеки компонентів дозволяють імпортувати окремі компоненти. Замість усієї бібліотеки, з якої ми використовуємо лише кілька форм і кнопок, підключаємо тільки ті компоненти, які нам потрібні.
Це може заощадити до 300 КБ у фінальному білді — вага, яку користувач інакше качав би даремно.
Шрифти
Google вимагає, щоб текст був видимий якомога раніше під час завантаження сторінки. Тому, коли на проєкті використовуються нестандартні шрифти, їх потрібно завантажувати відкладено, показуючи спочатку стандартний.
- Підключення. Шрифти підключаємо через @font-face.
- Асинхронне підвантаження. За нього відповідає властивість font-display.
- Вибір значення. У font-display є різні значення, але найкращі показники за швидкістю отримуємо з font-display: fallback.
Підключення шрифтів у такий спосіб може дати 15–20 балів.
Зображення
Логічно, що чим менше важить картинка, тим швидше вона завантажується. Google просуває власний формат зображень .webp, тому для зображень на сайті потрібно зробити їхні webp-копії, а підключати в шаблонах через тег <picture>, вказавши всередині два джерела — звичайну картинку й картинку .webp. Новий формат працює в більшості сучасних браузерів, але не в Safari — саме тому друге джерело обов'язкове.
Також можна зробити відкладене завантаження зображень — за допомогою плагіна jQuery Lazy або через IntersectionObserver.
Відкладене завантаження GTM
Цей пункт ми винесли окремо, бо разом з GTM може підтягуватися ще тонна зовнішніх маркетингових скриптів — і всі вони здатні дати сильну просадку за швидкістю.
Тож підключення GTM можна виконати через setTimeout, секунди на три, з атрибутами async і defer.
Скільки балів дав кожен крок
Підсумок на прикладі intertop.ua
Ось як усі перелічені заходи виглядають разом на реальному проєкті.
Чек-лист і що далі
| Захід | Що робимо | Що це дає |
|---|---|---|
| CSS і JS | async і defer, мінімізація, посторінкове підключення, gzipped-копія білду | близько 15 балів за асинхронність і ще 12 за мінімізацію |
| Модулі | імпортуємо окремі компоненти замість цілої бібліотеки | до 300 КБ економії у фінальному білді |
| Шрифти | @font-face плюс font-display: fallback | 15–20 балів |
| Зображення | webp-копії через <picture> і відкладене завантаження | менша вага сторінки й швидший показ контенту |
| GTM | підключення через setTimeout з async і defer | знімає просадку від зовнішніх маркетингових скриптів |
Головний висновок з цієї історії простий: доганяти показники постфактум завжди дорожче, ніж закласти їх у проєкт одразу.
Тепер ми проводимо оптимізацію під PageSpeed ще на етапі створення сайтів, щоб одразу досягати найкращих показників.Богдан Панасенко / Front-end розробник
