Как проверить скорость сайта

Быстрый способ: запустить тест в настоящем браузере

Введите 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 указывает на хостинг, запросы к базе данных или серверный код, а не на ресурсы страницы.
• Largest contentful paint (LCP). Момент, когда завершилась отрисовка самого крупного видимого элемента во вьюпорте, обычно это главное изображение, постер видео или крупный блок текста. Это число ближе всего к тому, что посетитель называет "когда страница появилась". Google считает хорошим значением 2,5 секунды и меньше.
• Время загрузки / полной загрузки. Момент, когда браузер закончил загружать документ и его блокирующие ресурсы. Все, что посетитель может увидеть, обычно готово задолго до этого момента.
• Общее время до успокоения. Время загрузки плюс все, что еще выполняется после, например скрипты, получающие данные уже после того, как страница выглядит готовой. Страница может выглядеть завершенной и при этом оставаться занятой, и эта работа конкурирует с первой прокруткой или кликом посетителя.
• Запросы и переданные байты. Сколько файлов подтянула страница и сколько было скачано. Это рычаги, стоящие почти за каждым числом выше.

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

Почему один тест из одного места вводит в заблуждение

Нормально дважды протестировать один и тот же URL и получить два разных результата, и ни один из них не ошибочен. За большей частью разброса стоят три вещи:

• Расстояние. Тест, запущенный рядом с сервером, имеет более короткий сетевой путь, чем запущенный на другом континенте. Если ваши посетители в Европе, а вы тестируете из того же города, что и сервер, вы измеряете лучший случай, а не типичный.
• Профиль устройства. Тест может эмулировать мобильное устройство с меньшим вьюпортом, другим user agent и ограниченной скоростью соединения. Страница, настроенная под десктоп, показывает совершенно другой результат при эмуляции мобильного, и так и задумано.
• Кэширование и прогрев. Первый запрос может попасть в холодный кэш CDN или приложения; второй отдается уже прогретым. Прогоните страницу два-три раза и ориентируйтесь на паттерн, а не на один самый быстрый прогон.

Разовый тест все равно стоит проводить. Просто число несет смысл только вместе с условиями, в которых оно было измерено.

Как читать водопад

Водопад - это временная шкала по каждому запросу, по одной полосе на файл, упорядоченная по времени начала. Снова и снова встречаются четыре формы:

1. Длинная первая полоса перед началом всего остального. Это TTFB на HTML, и все встает в очередь за ним.
2. Лестница, где каждый запрос начинается только когда заканчивается предыдущий. Это цепочка зависимостей, обычно скрипт, загружающий другой скрипт, загружающий настоящее содержимое. Цепочки - самая затратная форма на графике.
3. Широкая полоса посередине от стороннего домена. Здесь находятся реклама, виджеты чата, аналитика и шрифты, и медленная третья сторона задерживает вашу собственную страницу, если загружается синхронно.
4. Плотное скопление крошечных полос. Десятки мелких файлов, каждый со своими накладными расходами на соединение. Меньшее число более крупных кэшируемых файлов обычно выигрывает у множества мелких.

Полосы красного цвета или с кодами 4xx и 5xx заслуживают внимания, даже когда страница выглядит нормально, потому что провалившийся запрос все равно стоит времени еще до того, как провалится.

Как заметить замедление, которое никто не искал

Разовый тест показывает, как страница отработала один раз, из одного места, на одном профиле устройства. Это именно то, что нужно при отладке чего-то конкретного. Но это не то, что нужно, когда цель - вообще заметить замедление: страницы тяжелеют по одному обновлению за раз, и никто не запускает ручной тест в тихий вторник. Плановый мониторинг скорости страницы запускает один и тот же тест из одних и тех же локаций с заданным интервалом, хранит историю и оповещает, когда числа пересекают порог. Запустите его прямо сейчас с помощью теста скорости страницы, а если медленной оказалась именно серверная часть, смотрите время отклика сервера.