Як покращити свої метрики в Google PageSpeed ​​/ LightHouse [Доповідь Demi Murych]

У рамках щорічної конференції з інтернет-маркетингу 8Р я записала доповідь Демі Мурича, спеціаліста у реверс-інжинірингу та технічному SEO.

З цієї доповіді ви дізнаєтеся, як LightHouse оцінює продуктивність сайту, і що можна зробити для того, щоб її покращити та потрапити в зелену зону PageSpeed ​​тесту (90-100 балів), не володіючи серйозними технічними кваліфікаціями.

1. Що наразі оцінює LightHouse

До 2018 року всі вважали важливим, наскільки швидко сайт завантажується (від початку до кінця). Зараз це не має значення, наскільки швидко ваш сайт завантажується. Зараз цікавить те, з якою швидкістю перша область відображення формується у користувача на пристрої.

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

Lighthouse зчитує з API браузера три важливі тимчасові мітки в момент рендеру:

1. FCP (First Contentful Paint). Відображення чогось, є деякий текст, передній план, фонові картинки, SVG, і т.д., але цього контенту недостатньо для взаємодії з користувачем.
2. FMP (First Meaningful Paint). Відображення головного контенту (hero elements), який можна вважати цінним для користувача.
3. LCP (Largest Contetful Paint). В рамках області екрану сформовано достатньо контенту для того, щоб сторінка вважалася закінченою та готовою.

Наша мета як оптимізаторів зробити так, щоб усі ці мітки були ближчими до початку моменту, коли цей рендер починається.

Таким чином, навіть якщо сайт містить важкі картинки й може довго завантажуватися (3 секунди й більше), але він правильно оптимізований з точки зору продуктивності, він може потрапити в зелену зону PageSpeed тесту.

2. Які метрики вимірюють продуктивність сайту

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

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

FP, FCP, FMP, LCP на шкалі — це лише тимчасові мітки, які оцінюють, коли щось сталося. І чим раніше ці тимчасові мітки з’являються, тим краще.

Усі Web Vitals, про які зараз заявляє Google, включають ті самі метрики, які є з 2018 року. Змінилися лише назви та способи їх підрахунку.

Окремо стоїть CLS (Cumulative Layout Shift) - цю метрику ввели зовсім недавно, і найцікавіше, що вона не має жодного відношення до продуктивності.

CLS оцінює візуальну стабільність або те, наскільки сильно трясе наш сайт під час завантаження його ресурсів. Наприклад, коли у нас завантажуються картинки, наш сайт починає «стрибати» у міру завантаження зображень. Але якщо наш сайт зверстаний правильно, він «стрибати» не повинен взагалі.

Чому за цю характеристику потрібно Google сказати спасибі? Тепер у всіх людей, які не є технічними фахівцями, є можливість показати розробнику результат тесту, де написано «поганий CLS», якась страшна цифра, червоне коло і «будь ласка, виправте». І він має виправити, тому що мінімальний рівень якості верстки, який має бути забезпечений, це CLS = 0.

Підсумовуючи, всі метрики, окрім CLS, дійсно мають деяке відношення до продуктивності, а саме до того, наскільки швидко формується перша область відображення вгорі вашого сайту. А суть CLS тільки в тому, щоб підрахувати, наскільки сильно «трясе» сайт у момент завантаження його ресурсів.

3. Що знижує продуктивність сайту і як це виправити?

3.1. JS, CSS, медіа

Дуже просте правило для CSS: якщо обсяг вашої сторінки в стислому вигляді + обсяг вашого CSS-коду в стислому вигляді становить не більше 100 кБ, то можна весь ваш CSS-код вставити інлайном в шапку HTML-сторінки. Так робити не зовсім правильно, але за сукупністю позитивних і негативних факторів це рішення буде ідеальним.

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

Дізнатися про об'єм сторінок та CSS у стислому вигляді можна у вкладці Network.

Медіа, аудіо та звук повинні завантажуватися відкладено і лише тоді, коли вони дійсно потрібні.

JavaScript найбільше впливає на результати. Ось основне правило, яке дасть вам 100 балів у Lighthouse:

• Все, що завантажується, не повинно завантажуватись.
• Усе, що виконується, повинно виконуватися.

Одна з серйозних проблем сучасного Інтернету полягає в тому, що нашим ресурсам необхідно постійно встановлювати з'єднання між браузером та сервером. На це завдання йде дуже багато ресурсів.

Візьмемо типовий приклад: ми починаємо завантажувати Google Fonts стилі та вставляємо їх собі, припускаючи, що у них шикарний CDN, і вони найближче розташовані до клієнта. Але насправді це не добре. Ваше завдання: завантажити шрифти локально на свій сервер, де у вас розташований проект, в CSS замінити адреси й підключити завантаження цих ресурсів локально.

Чому? Навіть якщо у вас налаштований HTTP2, запит до локального сервера буде здійснюватися швидше, ніж до Google-сервера. Річ у тому, що при першому запиті до вашого ресурсу, фаза визначення зв'язків IP-адреси з ім'ям вашого домену вже була пройдена. А всі витрати, які, здається, значення не мають, є основними витратами при завантаженні будь-якого ресурсу: на з'єднання, на резолвінг DNS і т.д.

Правило дуже просте - чим менше JavaScript-коду на момент формування сторінки виконується, тим краще для вас. Все, що ми можемо відкласти у завантаженні, має бути відкладено.

До 2014 року загальний рецепт був таким: збирати всі скрипти в єдиний файл. Зараз концепція змінилася: чим більше подрібнень скрипту ви можете собі дозволити, тим швидше наш проект завантажуватиметься. Поки один шматок скрипта завантажуватиметься, інший виконуватиметься. Таким чином, ви розподіляєте навантаження між цими скриптами.

Тобто, якщо ви раптом відкриваєте зараз свій проект і бачите, що весь ваш JavaScript код вантажиться одним великим файлом, починайте думати, як це змінити.

3.2. Iframe: YouTube, Vimeo

А ось ці вставки зустрічаються у всіх на сайті та є критичними для продуктивності вашого проекту.

Будь-який iframe (найчастіше це вставка YouTube плеєра, Vimeo і т.д.) може просадити ваш сайт зі 100 балів до 0. Тому якщо на вашому проекті ви бачите вставлений iframe, починайте думати, як би інтегрувати й зробити те саме, але без iframe.

У цьому випадку вам допоможе мікророзмітка Videoobject - Google її правильно розуміє і правильно індексує.

3.3. Google Tag Manager, Google Analytics та Yandex з усіма його сервісами

Цей код, який ми повинні використовувати на наших сайтах, написаний не оптимальним чином.

До речі, базова точність роботи цих сервісів (Google Tag Manager, Google Analytics, Yandex) — плюс-мінус 10%. Це можна помітити, якщо ви вставите код лічильника на початок вашої сторінки, місяць покрутіть, а потім вставте в кінець і теж покрутіть місяць. Різниця лише всередині вашої сторінки покаже вам плюс-мінус 7% точності роботи цієї штуки.

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

Висновок: Потрібно оптимізувати та диференціювати навантаження, яке створюють ваші скрипти, які навантажують процесор та уповільнюють рендер початку першої області відображення.

4. Міфи про покращення продуктивності

Часто рекомендують: якщо у вас не впроваджено протокол HTTP2, то для вашої продуктивності це обов'язково потрібно зробити, і буде вам щастя.

Розберімося, чи це так.

1. HTTP / HTTP2

HTTP2 справді дуже серйозний прорив стосовно HTTP1. Коли з'явився HTTP2, його основною перевагою перед HTTP1 було те, що для того, щоб завантажувати той чи інший ресурс, не потрібно було встановлювати масу з'єднань.

І, здавалося б, чудово! Нумо використовувати HTTP2? Але якщо ви пам'ятаєте, як у якихось 2000-х, ми качали фільми, у нас були всякі download-менеджери, які писали нам про величезну кількість потоків, з яких вони починають завантажувати файли. Вони встановлювали 5-10 з'єднань, щоб завантажити цей файл. І, здавалося б, як це може бути швидко, якщо у нас канал товстіший не став від того, що ми 5 з'єднань встановили. Ситуація досить банальна: коли у вас поганий канал, то одне підвісне з'єднання не вплине на 4 інших з'єднань, які встановлені навіть до того ж серверу.

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

Наразі традиційні рекомендації розв'язання цих проблем полягають у тому, щоб встановити 4 HTTP2 з'єднання. Тільки різниці тоді між HTTP2 з 4 з'єднаннями та HTTP з 4 з'єднаннями немає ніякої. Це стосується саме випадку оптимізації продуктивності.

2. Об'єм DOM дерева

Якщо ви відкривали HTML-код вашого проекту, то бачили, що він складається з тегів. Кожен тег – це певний вузол дерева. Кожен такий вузол займає багато пам'яті. Що більше таких вузлів, то більше пам'яті займає ваш проект. Чим менше пам'яті залишається у пристрої, тим повільніше працює пристрій.

Об'єм DOM дерева в 1500 вузлів – це дуже консервативна характеристика. Люди, які оптимізуються серйозно, можуть зробити й на 3000, і на 5000 вузлах проект, який працюватиме дуже швидко. Тому якщо ви почуєте «у вас 2500 вузлів, терміново зробіть так, щоб у вас їх було менше», і ви суб'єктивно зі свого телефону не маєте жодних проблем, значить, не хвилюйтеся про цю цифру.

3. Векторна графіка

Прекрасна штука, яка незалежно від дозволу демонструє ту саму якість. Але вона має один єдиний і дуже великий недолік. Для формування цієї графіки використовують центральний процесор. Дуже часто подібна графіка може дуже сильно навантажити ваш процесор.

Якщо вам здається, що з вашою сторінкою стало відбуватися щось негаразд, щось її пригальмовує, найчастіше тому виною найменший, найпримітивніший SVG файл на 800 байтів. Здавалося б, як це може гальмувати систему? А дуже просто: всередині нього використовується певний фільтр (а всередині будь-якого SVG-файлу можна використовувати масу фільтрів від negative/positive до згладжувань тощо). Так ось, єдиний такий фільтр може призвести до того, що файл SVG може гальмувати всю вашу сторінку.

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

Висновок

Продуктивність проекту не дорівнює швидкості його завантаження. LightHouse взагалі практично не цікавить швидкість вашого завантаження. Його цікавить лише тимчасовий відрізок, який проходить між початком та формуванням першої області відображення.

Всі метрики, які використовуються LightHouse для оцінки продуктивності сайту (крім CLS), мають деяке відношення до продуктивності, а саме до того, наскільки швидко формується перша область відображення вгорі вашого сайту.