Почему страница кажется медленной, когда все метрики сервера говорят, что она работает быстро

Кто-то говорит, что ваш сайт медленный. Вы открываете панель мониторинга, и всё в норме. Время отклика сервера в районе сотен миллисекунд, ошибок нет, нагрузка в норме, ничего не превышает пороги.

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

Два таймера, запущенные в разные моменты

Таймер вашего сервера начинает отсчёт, когда приходит запрос, и заканчивает, когда сервер завершает написание ответа. Этот интервал представляет собой то, что сообщает ваш мониторинг: реальное измерение реальной вещи.

Таймер посетителя начинает отсчёт, когда он кликает, и не останавливается до тех пор, пока на странице не отрисуется то, ради чего он сюда пришёл. Между этими двумя моментами стоят: поиск DNS, соединение TCP, рукопожатие TLS, работа вашего сервера, ответ, возвращающийся назад, парсинг HTML, таблицы стилей, шрифты и скрипты, которые затем запрашивает HTML, каждый из которых повторяет большинство вышеуказанного, и, наконец, рендеринг.

Ваш сервер участвовал только в одном шаге этого процесса. Страница может потратить 80 миллисекунд на вашем сервере и четыре секунды на то, чтобы стать полезной, и ничего не будет неправильным в ваших приложениях мониторинга, когда они сообщают 80 миллисекунд.

Число, которое описывает сервер, и числа, которые описывают опыт

Число серверной части называется Time to First Byte, которое Google описывает как измерение “время между началом навигации на страницу и началом прибытия первого байта ответа”. Их рекомендация: “большинство сайтов должны стремиться иметь TTFB 0.8 seconds или менее”.

Но они явно указывают на его ограничения: “Поскольку TTFB не является метрикой Core Web Vitals, это не абсолютно необходимо для того, чтобы сайты соответствовали пороговому значению хорошего TTFB, если это не препятствует их способности хорошо работать по метрикам, которые имеют значение.”

К метрикам, которые имеют значение, относятся три Core Web Vitals, и каждая отвечает на вопрос, который человек действительно узнает.

Largest Contentful Paint показывает, когда самый большой элемент на экране завершает рисование, что является ближайшим человекоподобным прокси для “страница отобразилась”. Целевое значение: “LCP должен произойти в течение 2.5 seconds после того, как страница начнёт загружаться”.

Interaction to Next Paint показывает, сколько времени требуется странице, чтобы видимо ответить после того, как кто-то с ней взаимодействует: “страницы должны иметь INP 200 milliseconds или менее”. Он заменил First Input Delay как стабильный Core Web Vital в 2024 году, и это изменение важно, потому что FID измерял только задержку перед началом обработки, а INP измеряет весь путь до следующего рендеринга. Страница, которая мгновенно принимала ваш клик, а затем зависала, хорошо работала по старой метрике.

Cumulative Layout Shift вообще не о скорости. Он измеряет, насколько страница движется во время загрузки, и целевое значение “0.1 или менее”. Он находится в этом списке, потому что страница, которая прыгает под вашим пальцем, кажется сломанной таким образом, что читается человеком как медленная, даже если ничего не было.

Деталь, которая разрешает большинство этих споров

Core Web Vitals оцениваются на “75th percentile загрузок страниц, сегментированных по мобильным и настольным устройствам”.

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

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

Слабо

"Сайт медленный." Проверил панель мониторинга, p50 время отклика 90 мс, закрываю как невоспроизводимое.

Лучше

"Медленно на странице товара, примерно 6 секунд до того, как что-нибудь появится, на мобильном интернете." LCP служит метрикой, TTFB был в норме, поэтому время куда-то уходит после прихода ответа.

Куда на самом деле уходит время

Как только вы примете, что разрыв реален, остаётся всего несколько мест, где он скрывается, и они всегда одинаковы.

Ресурсы, блокирующие рендеринг. HTML прибыл быстро, а затем попросил таблицу стилей, и браузер не будет отрисовывать, пока он не получит её. Каждый блокирующий запрос в head добавляется к времени перед тем, как что-нибудь появится.

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

Изображения без размеров. Самая распространённая причина сдвига макета. Браузер не может зарезервировать пространство, поэтому всё ниже движется, когда приходит изображение.

JavaScript на медленном устройстве. Это невидимо на машине разработки по конструкции. Парсинг и выполнение большого пакета стоит часть секунды на ноутбуке и несколько секунд на смартфоне среднего диапазона, и страница не реагирует на касания в течение всего этого времени.

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

Что просить вместо “можете ли вы быть более конкретны”

“Медленно” невозможно реализовать, но три вещи, которые делают его осуществимым, все легко запросить, и ни одна из них не требует, чтобы заявитель понимал что-либо из вышесказанного.

• На какой странице и что они ждали. Медленно появляется вообще, медленно реагирует после касания или движется при загрузке. Это три разные метрики и три разные причины.
• На чём и с какого соединения. Android пятилетней давности на мобильном интернете и настольный компьютер на оптоволокне предоставляют совершенно разный опыт.
• Примерно сколько времени и всегда ли это происходит. Разница между “всегда примерно шесть секунд” и “иногда зависает” отражает отличие между тяжёлой страницей и перемежающейся неисправностью, и они не имеют общих исправлений.

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

Что из этого следует

Зелёная панель мониторинга не свидетельствует о том, что сайт быстрый. Она показывает, что контролируемая вами часть работает быстро, представляя собой лишь один шаг в последовательности, которую посетитель переживает полностью.

Измеряйте то, что они переживают, на процентиле, где живут жалобы, а не на среднем, и считайте ваш собственный опыт вашего собственного сайта как самую непредставительную точку данных, к которой у вас есть доступ.