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

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

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

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

Виміряти самостійно з командного рядка

Для серверної частини історії браузер узагалі не потрібен. curl може вивести власну розбивку таймінгів:

curl -o /dev/null -sS -w   "dns:%{time_namelookup}s connect:%{time_connect}s tls:%{time_appconnect}s ttfb:%{time_starttransfer}s total:%{time_total}s\n"   https://example.com/

Це вимірює лише один запит на сам HTML-документ, тож завжди виглядатиме швидшим за реальну сторінку. Саме тому це корисно: воно відокремлює сервер від браузера. Якщо ttfb тут високий, жодна оптимізація зображень не допоможе. Якщо ttfb низький, а сторінка все одно відчувається повільною, проблема в тому, що браузеру доводиться робити після того, як прийшов HTML.

Що означають TTFB, LCP і повне завантаження

• Час до першого байта (TTFB). Скільки часу знадобилося серверу, щоб почати відповідати, включно з DNS, встановленням з'єднання, TLS і власною обробкою на сервері. Високий TTFB вказує на хостинг, запити до бази даних чи бекенд-код, а не на ресурси сторінки.
• Найбільша видима відмальовка (LCP). Момент, коли найбільший видимий елемент у вікні перегляду завершив рендеринг, зазвичай головне зображення, обкладинка відео чи великий блок тексту. Це число найближче до того, що відвідувач назве "коли з'явилася сторінка". Google вважає хорошим результат 2,5 секунди чи менше.
• Час завантаження / повне завантаження. Момент, коли браузер завершив завантаження документа й ресурсів, що його блокують. Усе, що відвідувач може побачити, зазвичай готове задовго до цього моменту.
• Загальний час до заспокоєння. Час завантаження плюс усе, що ще виконується потім, як-от скрипти, що підвантажують дані, коли сторінка вже виглядає готовою. Сторінка може виглядати завершеною і все ще бути зайнятою, і ця робота конкурує з першим скролом чи кліком відвідувача.
• Запити й передані байти. Скільки файлів підвантажила сторінка і скільки було завантажено. Саме вони - важелі, що стоять майже за кожним числом вище.

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

Чому один тест з одного місця вводить в оману

Нормально протестувати ту саму URL двічі й отримати два різні результати, і жоден не буде помилковим. Три речі найбільше зумовлюють цю різницю:

• Відстань. Тест, запущений поблизу сервера, має коротший мережевий шлях, ніж запущений на іншому континенті. Якщо ваші відвідувачі в Європі, а ви тестуєте з того самого міста, що й ваш сервер, ви вимірюєте найкращий випадок, а не типовий.
• Профіль пристрою. Тест може імітувати мобільний пристрій з меншим вікном перегляду, іншим user agent і обмеженою швидкістю з'єднання. Сторінка, налаштована під десктоп, показує зовсім інший результат під мобільною емуляцією - і це навмисно.
• Кешування й розігрів. Перший запит може влучити в холодний кеш на CDN чи в застосунку; другий обслуговується вже "теплим". Запустіть сторінку два-три рази й орієнтуйтеся на патерн, а не на єдиний найшвидший прогін.

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

Як читати waterfall

Waterfall - це таймлінія по кожному запиту, одна смуга на файл, упорядкована за часом початку. Чотири форми трапляються знову і знову:

1. Довга перша смуга перед початком усього іншого. Це TTFB на HTML, і все інше стоїть у черзі за ним.
2. Сходинки, де кожен запит починається лише тоді, коли завершується попередній. Це ланцюжок залежностей, зазвичай скрипт, що завантажує інший скрипт, який завантажує справжній контент. Ланцюжки - найдорожча форма на графіку.
3. Широка смуга посередині від стороннього домену. Тут сидять реклама, віджети чату, аналітика й шрифти, і повільна третя сторона затримує вашу власну сторінку, якщо її завантажують синхронно.
4. Щільний кластер крихітних смуг. Десятки дрібних файлів, кожен зі своїми витратами на з'єднання. Менше, більших за розміром і кешованих файлів зазвичай краще, ніж багато дрібних.

Смуги червоного кольору чи з кодами 4xx і 5xx заслуговують на увагу, навіть коли сторінка виглядає нормально, бо невдалий запит усе одно коштує часу, перш ніж зазнати невдачі.

Виявити уповільнення, яке ніхто не шукав

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