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

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

Важливо також розрізняти загальний час завантаження сторінки, продуктивність серверної частини та користувацькі метрики. Сторінка може почати відображатися швидко, але довго реагувати на взаємодію, зміщувати елементи під час завантаження або блокувати головний потік браузера важким JavaScript. Саме тому сучасна оцінка продуктивності охоплює не одну цифру, а комплекс показників, серед яких особливе значення мають Core Web Vitals.

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

Чому швидкість завантаження сайту важлива?

Швидкість завантаження сайту безпосередньо впливає на те, наскільки комфортно користувачеві взаємодіяти з вебресурсом. Людина очікує, що сторінка швидко покаже основний контент, кнопки та меню реагуватимуть без помітних затримок, а елементи інтерфейсу не змінюватимуть положення після того, як користувач уже почав читати текст або намагався натиснути посилання. Коли цього не відбувається, сайт суб’єктивно сприймається як повільний навіть тоді, коли завантаження другорядних ресурсів завершується вже після появи основного контенту.

Особливо критичною продуктивність стає для мобільного трафіку. Смартфон може мати слабший процесор, ніж настільний комп’ютер, а користувач може відкривати сайт через мобільну мережу з нестабільною пропускною здатністю та високою затримкою. Важкі JavaScript-файли, великі зображення або надмірна кількість сторонніх ресурсів у таких умовах створюють значно помітнішу проблему. Саме тому під час тестування не варто орієнтуватися лише на те, наскільки швидко сайт відкривається на потужному робочому комп’ютері через швидке з’єднання.

Продуктивність також пов’язана з SEO, але цей зв’язок потрібно трактувати коректно. Google використовує Core Web Vitals у своїх системах ранжування, однак хороші показники самі по собі не гарантують високих позицій у результатах пошуку. Релевантність і якість контенту, можливість його коректного сканування та індексації, загальний користувацький досвід та інші сигнали також мають значення. Оптимізація швидкості допомагає усунути технічні перешкоди й покращити взаємодію із сайтом, але не замінює повноцінну SEO-роботу.

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

Як перевірити швидкість сайту?

Щоб перевірити швидкість завантаження сайту коректно, варто уникати тестування лише однієї URL-адреси. Головна сторінка часто має унікальну структуру і може істотно відрізнятися від сторінок товарів, категорій, статей, особистого кабінету або інших функціональних частин ресурсу. Наприклад, каталог може містити значно більше зображень і JavaScript, а сторінка товару – зовнішні віджети, рекомендації, відгуки та аналітичні скрипти.

Практичний процес перевірки можна побудувати так:

1. Вибрати репрезентативні сторінки. Перевіряють головну сторінку, кілька важливих посадкових сторінок, типові сторінки товарів або послуг, статті та інші шаблони, які отримують значну частину трафіку.
2. Запустити тест у кількох інструментах. Один сервіс не дає повної картини. PageSpeed Insights зручний для аналізу лабораторних показників Lighthouse та доступних даних Core Web Vitals, GTmetrix – для детального перегляду ресурсів і мережевих запитів, а Search Console – для контролю польових Core Web Vitals.
3. Розділити лабораторні та польові дані. Лабораторний тест моделює певні умови в конкретний момент, тоді як польові показники формуються з агрегованих даних реального використання.
4. Знайти вузьке місце. Потрібно визначити, що саме створює затримку: серверна відповідь, LCP-ресурс, JavaScript, CSS, сторонній сервіс, шрифт, зображення, велика кількість мережевих звернень або інший компонент.
5. Внести зміни та повторити тест. Після оптимізації важливо використовувати ті самі сторінки й максимально схожі умови, щоб коректно порівнювати результати до та після змін.

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

Під час діагностики серверної частини корисно окремо дивитися на TTFB – Time to First Byte. Він показує, скільки часу проходить до отримання браузером першого байта відповіді. Високий TTFB може бути пов’язаний із тривалою генерацією сторінки, роботою бази даних, кешем, мережею або встановленням з’єднання, тому його потрібно аналізувати разом з іншими показниками, а не трактувати як чисту метрику продуктивності процесора сервера.

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

Інструменти для перевірки швидкості сайту

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

Найкраще використовувати інструменти разом. PageSpeed Insights допомагає оцінити лабораторну продуктивність сторінки та, за наявності достатньої кількості даних, Core Web Vitals із Chrome User Experience Report. GTmetrix дозволяє розібрати процес завантаження на окремі ресурси, а Google Search Console показує стан Core Web Vitals для груп URL на основі польових даних.

Google PageSpeed Insights

Google PageSpeed Insights – один із базових інструментів, коли потрібно провести перевірку швидкості сайту. Достатньо вказати URL, після чого сервіс показує результати для мобільного та десктопного сценаріїв. У звіті можна побачити лабораторні дані Lighthouse, оцінку Performance, окремі метрики продуктивності та діагностичні рекомендації.

Для URL або доменів, за якими доступно достатньо статистики, PageSpeed Insights також показує польові дані Chrome User Experience Report – CrUX. Вони формуються з анонімізованих даних реальних користувачів Chrome, які відповідають умовам включення до вибірки. Це принципово інший тип інформації. Лабораторний тест відображає результат конкретного запуску у змодельованих умовах, а польові дані характеризують досвід користувачів на різних пристроях і мережах. Саме тому після технічної оптимізації Lighthouse може відразу показати покращення, тоді як польові Core Web Vitals змінюються поступово.

Не варто сприймати Performance Score як єдину мету оптимізації. Дві сторінки з однаковою оцінкою можуть мати різні проблеми: в однієї повільно відображається найбільший елемент контенту, у другої браузер довго зайнятий виконанням JavaScript. Тому після загальної оцінки потрібно переходити до конкретних метрик, ресурсів і діагностичних рекомендацій.

GTmetrix

GTmetrix корисний, коли потрібно детальніше побачити, з яких ресурсів складається завантаження сторінки. Одна з найцінніших частин звіту – Waterfall Chart. Він показує завантаження ресурсів за окремими запитами та дозволяє оцінити, коли браузер почав отримувати конкретний файл, скільки часу зайняв запит, з якого домену надходив ресурс і який обсяг даних передавався.

Це допомагає знаходити проблеми, які складно помітити лише за загальним показником швидкості. Наприклад, сторінка може чекати відповіді стороннього сервісу, завантажувати великий JavaScript із зовнішнього домену, виконувати зайві редиректи або передавати надто важкі зображення. За Waterfall Chart можна побачити послідовність таких запитів і визначити ресурси, що затримують наступні етапи завантаження.

GTmetrix використовує Lighthouse для лабораторного аналізу. Водночас INP у стандартному лабораторному тесті GTmetrix не вимірюється як польова метрика, оскільки для неї потрібні реальні або спеціально змодельовані взаємодії. Для лабораторної діагностики блокування головного потоку використовується Total Blocking Time – TBT, який може слугувати проксі для пошуку проблем, пов’язаних із реактивністю. Це ще одна причина не ототожнювати показники різних типів тестування.

Google Search Console

У Google Search Console для аналізу користувацького досвіду використовується звіт Core Web Vitals. Він показує дані окремо для мобільних і десктопних пристроїв та групує URL за станом – хороші, ті, що потребують покращення, та проблемні.

Головна відмінність Search Console від разового лабораторного тесту полягає в джерелі інформації. Звіт базується на польових даних CrUX, тобто на агрегованих вимірюваннях реального використання. Тому він особливо важливий після того, як технічні роботи завершені. Лабораторна перевірка швидкості завантаження сайту допомагає швидко оцінити результат змін, а Search Console – зрозуміти, чи покращилися Core Web Vitals у реальних умовах.

Search Console не слід використовувати як інструмент для миттєвої перевірки одного конкретного URL. Система групує схожі сторінки, а для частини URL може не бути достатньо польових даних. Для діагностики окремої сторінки зручніше використовувати PageSpeed Insights, DevTools або інший лабораторний інструмент, а Search Console залишити для контролю загального стану Core Web Vitals на сайті.

Що таке Core Web Vitals?

Core Web Vitals – це набір основних метрик Google, які характеризують три важливі аспекти користувацького досвіду: швидкість завантаження основного видимого контенту, реактивність сторінки та візуальну стабільність. Станом на 2026 рік до Core Web Vitals входять LCP, INP і CLS.

LCP, або Largest Contentful Paint, показує час до відображення найбільшого елемента контенту, видимого в області перегляду. Ним може бути велике зображення, текстовий блок або інший підтримуваний тип контенту. Для хорошого користувацького досвіду рекомендованим орієнтиром є LCP до 2,5 секунди.

INP, або Interaction to Next Paint, характеризує загальну реактивність сторінки на взаємодії користувача протягом її життєвого циклу. Метрика враховує затримку введення, виконання пов’язаних обробників і час до відображення наступного кадру. Хорошим орієнтиром є INP до 200 мс. Високе значення часто пов’язане з довгими JavaScript-завданнями, складною роботою DOM, важкими обробниками подій або перевантаженням головного потоку браузера.

CLS, або Cumulative Layout Shift, оцінює візуальну стабільність сторінки. Якщо під час використання текст, кнопки, банери або інші елементи несподівано зміщуються без очікуваної дії користувача, показник може зростати. Хорошим значенням вважається CLS до 0,1. Типовими причинами проблем стають зображення без зарезервованого місця, рекламні блоки, динамічно вставлений контент і окремі сценарії роботи вебшрифтів.

Для оцінки відповідності рекомендованим порогам Core Web Vitals використовується 75-й перцентиль, окремо для мобільних і десктопних пристроїв. Практично це означає, що для хорошого результату відповідним порогам мають відповідати щонайменше 75% виміряних відвідувань. Тому одиничний вдалий лабораторний тест не означає автоматично, що сторінка стабільно проходить Core Web Vitals у реальних умовах.

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

Причину повільної роботи потрібно шукати поетапно, тому що однаковий зовнішній симптом може виникати через різні компоненти. Наприклад, високий LCP може бути наслідком важкого hero-зображення, але інколи файл оптимізований, а затримка виникає ще до початку його завантаження через повільне формування HTML або пізнє виявлення ресурсу браузером.

Одна з найпоширеніших причин – зображення надмірного розміру. Якщо браузер отримує файл із шириною кілька тисяч пікселів для відображення у невеликому блоці, передається більше даних, ніж реально потрібно. Сучасні формати зображень, адаптивні розміри та правильне стиснення допомагають скоротити обсяг переданих даних. Водночас не варто автоматично застосовувати lazy loading до основного LCP-зображення: відкладене завантаження критичного візуального ресурсу може погіршити LCP.

Друга велика група проблем – CSS та JavaScript. Ресурси стилів, необхідні для початкового рендерингу, можуть затримувати відображення сторінки, а великий обсяг JavaScript – займати головний потік браузера та погіршувати реактивність інтерфейсу. Особливо варто перевіряти код, який завантажується або виконується на кожній сторінці незалежно від того, чи потрібен він конкретному шаблону.

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

Окрема складова – сторонні скрипти. Системи аналітики, рекламні платформи, онлайн-чати, карти, відеоплеєри, віджети соціальних мереж, системи персоналізації та маркетингові сервіси додають власний JavaScript і мережеві звернення. Кожен компонент окремо може створювати невелике навантаження, але їхній сумарний вплив іноді стає значним.

Серверне середовище визначає, наскільки швидко застосунок може сформувати відповідь на запит. Якщо CMS довго виконує PHP-код, база даних обробляє складні запити або доступних CPU і RAM недостатньо для поточного навантаження, браузер може довше чекати на початковий HTML. Для PHP-проєктів важливими можуть бути кешування, оптимізація бази даних, актуальна версія PHP, конфігурація вебсервера та архітектура застосунку.

Має значення і дискова підсистема, особливо для систем із великою кількістю операцій введення-виведення або інтенсивною роботою з базами даних. Детальніше про особливості сучасних накопичувачів у серверній інфраструктурі можна прочитати в матеріалі про NVMe-диски. Водночас сам перехід на швидший накопичувач не виправить важкий JavaScript, неоптимізовані зображення або невдалу архітектуру сайту.

На серверну продуктивність впливає й програмне середовище. Apache і Nginx мають різні архітектурні підходи та способи конфігурації, тому конкретна схема залежить від застосунку, навантаження та вимог до інфраструктури. Особливості двох рішень детально розглянуті у матеріалі Apache vs Nginx.

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

Як прискорити завантаження сайту?

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

Найчастіше робота охоплює такі напрями:

• Оптимізація зображень. Варто використовувати адекватні розміри, стиснення, сучасні формати та адаптивні варіанти файлів для різних екранів.
• Робота з CSS і JavaScript. Потрібно скорочувати невикористовуваний код, контролювати критичні ресурси та, де це технічно доречно, відкладати завантаження або виконання другорядних скриптів.
• Налаштування кешування. Браузерний, сторінковий, об’єктний і серверний кеш вирішують різні задачі та можуть комбінуватися відповідно до архітектури проєкту.
• Оптимізація серверної частини. Сюди можуть входити робота з PHP, базою даних, вебсервером, CPU, RAM, дисковою підсистемою та іншими компонентами інфраструктури.
• Відкладене завантаження другорядних ресурсів. Зображення та інший контент нижче першого екрана не завжди потрібно завантажувати одразу, тоді як критичні для початкового відображення ресурси потребують окремого підходу.
• Контроль сторонніх сервісів. Необхідно перевіряти реальну користь кожного маркетингового, аналітичного або функціонального скрипта та його вплив на головний потік і мережеві запити.
• Використання CDN за потреби. Для географічно розподіленої аудиторії CDN може скоротити шлях доставки кешованого контенту та зменшити частину запитів до вихідного сервера.

Особливо важливо правильно працювати з кешем. Для простого інформаційного сайту може бути достатньо сторінкового та браузерного кешування, тоді як інтернет-магазин, особистий кабінет або динамічний вебзастосунок потребують складнішої логіки. Redis і Memcached можуть використовуватися для кешування даних або object cache залежно від застосунку, тоді як OPCache зберігає скомпільований PHP-байткод. Тому ці технології не є прямими взаємозамінниками.

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

Чому сайт може повільно завантажуватися навіть після оптимізації?

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

Лабораторний тест запускається у визначеному середовищі, але навіть його результати можуть коливатися. На вимірювання впливають мережеві умови, стан сервера, кеш, доступність сторонніх ресурсів та інші фактори. Тому невеликі зміни показників між повторними тестами не обов’язково свідчать про проблему. Значно важливіше дивитися на тенденцію та повторювані вузькі місця.

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

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

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

Ще одна причина непорозумінь – різниця між лабораторними й польовими даними. Якщо після оптимізації вдалося перевірити швидкість сайту і побачити кращий Lighthouse-результат, це не означає, що Search Console одразу покаже інший статус Core Web Vitals. Польові показники формуються з накопичених реальних вимірювань, тому зміни відображаються поступово.

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

Універсальної цифри повного часу завантаження, яка однаково підходить для всіх сайтів, немає. Сторінка статті, складний інтернет-магазин, SaaS-застосунок і медіасервіс мають різну структуру, функціональність і кількість ресурсів. Крім того, показник повного завантаження може враховувати другорядні ресурси, які не заважають користувачеві вже читати сторінку або взаємодіяти з основним інтерфейсом.

Практичніше орієнтуватися на Core Web Vitals. Для LCP хорошим результатом вважається значення до 2,5 секунди, для INP – до 200 мс, для CLS – до 0,1. При цьому рекомендовані пороги оцінюються на 75-му перцентилі, тому важлива не одна вдала перевірка, а стабільна продуктивність для більшості користувачів.

Для LCP діапазон понад 2,5 секунди до 4 секунд означає потребу в покращенні, а понад 4 секунди – слабкий результат. Для INP значення понад 200 до 500 мс потребує покращення, а понад 500 мс вважається слабким. Для CLS значення понад 0,1 до 0,25 потребує покращення, а понад 0,25 характеризує слабку візуальну стабільність.

Водночас хороші Core Web Vitals не означають, що можна ігнорувати інші параметри. Повільний TTFB, надмірний обсяг переданих даних, велика кількість мережевих запитів або високе навантаження на головний потік можуть залишатися важливими проблемами навіть тоді, коли три основні показники перебувають у рекомендованих межах.

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

Як контролювати швидкість сайту після оптимізації?

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

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

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

Для лабораторної діагностики можна регулярно використовувати PageSpeed Insights, GTmetrix або інструменти браузера, а для оцінки польових Core Web Vitals – Search Console та інші джерела CrUX. Серверну частину варто контролювати окремо, оскільки хороша фронтенд-оцінка не показує всі можливі проблеми з навантаженням, базою даних або доступністю.

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

Висновок

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

PageSpeed Insights допомагає проаналізувати лабораторну продуктивність окремої сторінки та доступні польові Core Web Vitals, GTmetrix – детально дослідити процес завантаження ресурсів, а Google Search Console – контролювати Core Web Vitals для реальної аудиторії на рівні груп URL. Ці інструменти доповнюють один одного, тому оптимізацію не варто будувати навколо одного балу або одного тесту.

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

Стиснення зображень, оптимізація CSS і JavaScript, правильне кешування, контроль сторонніх скриптів, серверна оптимізація та використання CDN за відповідного сценарію можуть покращити продуктивність, але конкретний набір дій завжди залежить від причини проблеми. Саме тому якісна діагностика повинна передувати оптимізації, а контроль показників – продовжуватися після її завершення.

Якщо діагностика показує, що поточне серверне середовище обмежує продуктивність проєкту, варто окремо оцінити потрібний обсяг CPU, RAM, дискових ресурсів і рівень контролю над конфігурацією. Для сайтів і вебзастосунків, яким потрібне власне серверне середовище з можливістю самостійного налаштування вебсервера, PHP і кешування, одним із доступних у Hostpark варіантів є SSD VDS у Польщі. Перехід на іншу інфраструктуру доцільний тоді, коли вимірювання підтверджують, що вузьке місце справді знаходиться на серверній стороні, а не у фронтенді або сторонніх ресурсах.