Швидкість завантаження сайту: як перевірити і прискорити

Швидкість завантаження сайту Google оцінює за трьома метриками Core Web Vitals: LCP (до 2,5 с), INP (до 200 мс) і CLS (до 0,1). Дані беруться з реальних користувачів, а не з тесту. Повільний сайт втрачає і позиції, і людей, які йдуть, не дочекавшись. Нижче - як міряти правильно, які проблеми зустрічаються найчастіше і 8 кроків, що дають найбільший ефект без переробки сайту.

Чому швидкість сайту - це не тільки про SEO

Про швидкість зазвичай згадують у контексті ранжування: «Google любить швидкі сайти». Це правда, але не головна причина нею займатись. Швидкість - фактор ранжування, проте один із сотень. Повільний сайт із сильним контентом усе одно обійде швидкий, але порожній.

Головна причина в іншому. Понад дві третини трафіку в Україні - мобільний, часто з нестабільним зв'язком. Людина, яка чекає на відкриття сторінки п'ять секунд, у більшості випадків повертається до видачі й відкриває наступний сайт. Ви не побачите цього в позиціях - ви побачите це у високому показнику відмов і низькій конверсії при нормальному трафіку.

Тому в кожному аудиті я дивлюсь на швидкість не як на «технічний пункт для галочки», а як на прямий вплив на гроші: скільки людей ви приводите і скільки з них втрачаєте на першому екрані.

Core Web Vitals простими словами

Google звів оцінку швидкості до трьох метрик. Вони вимірюють не «час завантаження» абстрактно, а те, що відчуває людина.

Важлива деталь, яку часто пропускають: Google рахує ці метрики за даними реальних відвідувачів Chrome за останні 28 днів, а не за результатом тесту. Тобто якщо ваша аудиторія заходить із дешевих телефонів через мобільний інтернет, метрики будуть гіршими, ніж показує тест на швидкому ноутбуці в офісі. Саме тому «у мене PageSpeed показує 90» і «у Search Console сторінки червоні» - не суперечність, а дві різні речі.

Як правильно перевірити швидкість завантаження сайту

1. Звіт Core Web Vitals у Search Console

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

2. PageSpeed Insights

Безкоштовний інструмент Google для перевірки окремої сторінки. Дивіться на верхній блок - там польові дані реальних користувачів. Нижче йде лабораторний тест з оцінкою від 0 до 100 і списком рекомендацій. Оцінка корисна як орієнтир, але не є фактором ранжування - Google дивиться саме на польові метрики.

3. Перевірка очима

Найпростіший і найчесніший тест: відкрийте сайт зі свого телефона через мобільний інтернет, не через Wi-Fi. Не з кешу - у режимі інкогніто. Якщо довелося чекати, ваші клієнти теж чекають.

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

Що гальмує сайт найчастіше

За роки аудитів у мене склався досить стабільний список. У дев'яти випадках із десяти проблема в одному або кількох пунктах нижче.

• Важкі зображення. Фото на 3-5 МБ, завантажені прямо з камери, у форматі JPEG, без стиснення. Найпоширеніша і найлегше виправна проблема;
• Сторонні скрипти. Чати, віджети відгуків, пікселі реклами, карти - кожен підвантажує свій код. П'ять-шість таких віджетів легко додають 2-3 секунди;
• Немає кешування. Браузер щоразу завантажує все з нуля, хоча міг би взяти стилі й картинки з пам'яті;
• Повільний хостинг. Сервер довго думає перед тим, як віддати перший байт. Часто це найдешевший тариф, на якому крутиться ще сотня сайтів;
• Роздутий шаблон. Тема для WordPress «з усім одразу», де підвантажується десяток бібліотек, з яких використовується дві;
• Шрифти. Кілька сімейств у різних накресленнях із зовнішнього сервісу. Поки вони не завантажились, текст або невидимий, або стрибає.

8 кроків, які дають найбільший ефект

У порядку від найпростішого до складнішого. Перші чотири зазвичай закриваються за день і дають найбільший приріст.

1. Стисніть зображення і переведіть у WebP

Формат WebP дає той самий візуальний результат при вазі на 25-35% меншій, ніж JPEG. Плюс масштабування: банер на весь екран не має бути 4000 пікселів завширшки, якщо показується на 400. На цьому сайті, наприклад, фото в шапці важить 97 КБ у WebP замість 176 КБ у JPEG, а для старих браузерів залишено запасний варіант.

2. Увімкніть кешування і стиснення на сервері

Кілька рядків у файлі .htaccess - і браузер перестає щоразу завантажувати стилі, скрипти й картинки заново, а сервер віддає файли стисненими. Ось робочий фрагмент, який стоїть і на цьому сайті:

Якщо сайт на WordPress - те саме робить будь-який нормальний плагін кешування. Головне - щоб він був увімкнений і налаштований, а не просто встановлений.

3. Відкладіть завантаження зображень нижче екрана

Атрибут loading="lazy" на картинках, які не видно на першому екрані. Браузер завантажить їх тільки коли користувач догортає. Одна зміна - і сторінка з тридцятьма фото товарів вантажить спершу шість.

4. Приберіть або відкладіть зайві скрипти

Пройдіться по списку: чат, віджет соцмереж, лічильник, старий піксель реклами, яку давно вимкнули. Що не потрібно - видаліть. Що потрібно - завантажуйте після основного контенту через defer або підключайте через Google Tag Manager, щоб керувати ними в одному місці.

5. Задайте розміри всім зображенням і блокам

Це про CLS. Коли у картинки не вказані ширина й висота, браузер не знає, скільки місця під неї залишити, і текст стрибає, коли вона завантажиться. Людина хоче натиснути кнопку - а на її місці вже реклама. Прописані розміри знімають проблему повністю.

6. Зменшіть кількість шрифтів

Два сімейства в двох-трьох накресленнях - достатньо для будь-якого сайту. І параметр display=swap при підключенні, щоб текст показувався системним шрифтом, поки завантажується основний, а не залишався невидимим.

7. Підключіть CDN

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

8. Змініть хостинг, якщо сервер повільний

Показник TTFB (час до першого байта) понад 600-800 мс означає, що проблема в сервері, і ніяка оптимізація картинок її не вирішить. Це найдорожчий крок у списку, тому він останній - але іноді єдиний, який реально допомагає.

Три міфи про швидкість сайту

«Треба досягти 100 балів у PageSpeed». Не треба. Оцінка - лабораторний орієнтир, Google ранжує за польовими Core Web Vitals. Сайт із 65 балами і «зеленими» метриками в Search Console - у кращому становищі, ніж сайт із 95 балами і «червоними». Гонитва за сотнею часто ламає функціонал заради цифри.

«Достатньо поставити плагін кешування». Плагін закриває один пункт із восьми. Якщо сторінка вантажить 4 МБ зображень і шість віджетів, кеш допоможе тільки повторним відвідувачам - а з пошуку приходять нові.

«Прискорили сайт - виростуть позиції». Прискорення прибирає гальмо, але не додає газу. Якщо контент слабкий і посилань немає, швидкий сайт залишиться швидким сайтом на другій сторінці. Швидкість - частина комплексної роботи, а не заміна їй.

Де швидкість важлива найбільше

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

Друга категорія - сайти з мобільною аудиторією у регіонах: послуги, доставка, локальний бізнес. Там і зв'язок гірший, і телефони простіші, тому ті самі 3 МБ на сторінці відчуваються вдвічі болючіше, ніж у Києві.

З чого почати сьогодні

1. Відкрийте звіт Core Web Vitals у Search Console і подивіться, скільки сторінок «погані» на мобільних;
2. Прожените через PageSpeed Insights три сторінки, на які приходить найбільше трафіку - не головну;
3. Перевірте вагу зображень на цих сторінках: якщо є файли понад 300-500 КБ - ось перша задача;
4. Порахуйте сторонні скрипти на сторінці і вимкніть ті, якими не користуєтесь;
5. Перевірте, чи увімкнене кешування - у налаштуваннях хостингу або плагіна.

Цього достатньо, щоб за тиждень перевести більшість сторінок із «червоних» у «жовті» або «зелені». Далі - точкова робота по тому, що залишилось.