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

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

Если сайт быстрый у владельца, это ещё не означает, что он так же быстро доставляется другим посетителям. Рабочий браузер уже хранит часть CSS, JavaScript, изображений и шрифтов, DNS может быть прогрет, а CDN — отдавать ресурсы с ближайшего edge-узла. Новый пользователь начинает с других условий.

Диагностировать нужно не «скорость сайта вообще», а место, где теряется время у конкретного пользователя: DNS → сеть → CDN или прокси → веб-сервер → приложение → браузер.

У владельца сайт открывается быстро, а у посетителей — нет

Проверка с рабочего компьютера владельца — слишком «тёплый» тест. Браузер уже знает часть ресурсов, DNS может быть закеширован, а повторные соединения — переиспользоваться. Поэтому десятое открытие страницы с одного и того же компьютера плохо имитирует первый визит пользователя из другой сети.

Для начала откройте страницу в режиме инкогнито, в DevTools перейдите в Network и включите Disable cache. Затем повторите тот же URL через другую сеть, например мобильный интернет. Это помогает исключить обычный HTTP-кеш браузера, но не делает тест полностью «холодным»: системный DNS-кеш, CDN-кеш и часть механизмов повторного соединения могут сохраняться.

Сравните не только итоговое время загрузки, но и Transferred и Resources. Если страница содержит несколько мегабайт ресурсов, а при повторном открытии по сети передаётся лишь малая часть, владелец фактически тестирует локальный кеш.

Первый вопрос в таких случаях лучше формулировать так: «у кого, откуда, на какой странице и при первом или повторном визите возникает задержка?». Это сразу даёт больше информации, чем фраза «сайт грузится медленно».

Как отделить задержку сервера от задержки сети и браузера

Чтобы найти источник проблемы, нужно отдельно измерить DNS, установку соединения, TLS, ожидание первого байта и загрузку ресурсов. Общая цифра «страница открылась за четыре секунды» не показывает, где именно потеряно время.

Что показывает TTFB

В Chrome DevTools откройте Network, выберите основной запрос типа document и посмотрите Timing. Там видны DNS Lookup, Initial connection, SSL, Waiting for server response и Content Download. Если основная пауза находится в Waiting, уже имеет смысл разбираться с TTFB, origin и backend. Если задержка возникает раньше, подозревать PHP или базу данных преждевременно.

Для быстрой проверки через консоль можно использовать:

curl -o /dev/null -s -w "DNS:%{time_namelookup} Connect:%{time_connect} TLS:%{time_appconnect} TTFB:%{time_starttransfer} Total:%{time_total}\n" https://example.com/

Здесь есть нюанс: time_connect, time_appconnect и time_starttransfer — накопительные отметки от начала запроса, а не независимые длительности этапов. Для HTTPS грубо можно читать их так: DNS ≈ time_namelookup, TCP ≈ time_connect - time_namelookup, TLS ≈ time_appconnect - time_connect, а ожидание первого байта после TLS ≈ time_starttransfer - time_appconnect.

Универсального порога «плохого TTFB» нет. Статический лендинг, WooCommerce и приложение с внешними API ведут себя по-разному. Важнее сравнивать один и тот же URL в разных условиях и смотреть, на каком этапе появляется лишняя пауза.

Когда виноваты ресурсы, а не backend

Например, HTML приходит за 300 мс, но сторонний JavaScript отвечает 2,5 секунды и блокирует дальнейшую работу страницы. Добавление RAM серверу в таком случае вряд ли изменит пользовательское ощущение: backend уже закончил работу, а браузер всё ещё ждёт ресурс или выполняет код.

Сначала локализуем секунду, потом оптимизируем. Иначе легко несколько часов менять PHP-FPM, MySQL и кеширование, хотя задержка живёт совсем в другом месте.

Почему один и тот же сервер работает по-разному из разных сетей

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

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

ping example.com
traceroute example.com
mtr -rw example.com

В Windows вместо traceroute используется tracert, а для длительной проверки удобно применять WinMTR. Лучше получить результат именно из сети, где проявляется проблема: трассировка с сервера в обратную сторону может идти другим путём.

У mtr есть типичная ловушка. Потери на одном промежуточном hop не доказывают потерю пользовательского трафика: маршрутизатор может ограничивать ответы ICMP, но нормально пересылать пакеты дальше. Если на промежуточном узле видно 30% loss, а на конечном сервере потерь нет, сам этот hop не является достаточным доказательством проблемы.

Количество переходов тоже не диагноз. Пятнадцать стабильных hops могут работать лучше семи через перегруженный транзит. До сайта пользователь ещё должен нормально «доехать».

Как DNS и IPv6 создают проблему только для части аудитории

Если у домена есть AAAA-запись, часть клиентов может подключаться по IPv6, даже когда владелец проверяет сайт только по IPv4. Поэтому исправная A-запись и быстрый IPv4 ещё не доказывают, что сайт одинаково работает для всех.

A и AAAA нужно проверять отдельно

Сначала посмотрите фактические ответы DNS:

dig example.com A
dig example.com AAAA
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com

Затем отдельно проверьте оба стека:

curl -4 https://example.com/
curl -6 https://example.com/

A и AAAA показывают, куда домен отправляет клиента, а curl -4 и curl -6 помогают проверить каждый стек отдельно. Но curl -6 имеет диагностический смысл только из сети или узла, где IPv6 действительно работает. Если IPv6 нет у самого проверяющего, ошибка команды ещё не доказывает проблему сайта.

Что бывает после миграции на новый IP

После переноса встречается сценарий, когда A уже указывает на новый сервер, а AAAA осталась от старой конфигурации. Другой вариант — IPv6 опубликован в DNS, но Nginx или Apache не слушает нужный адрес. В зависимости от клиента это может проявляться задержкой, нестабильным подключением или ошибкой; современные браузеры и ОС часто пытаются быстро переключаться между IPv6 и IPv4, поэтому поведение бывает разным.

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

Проверили A — не значит проверили DNS. Для проблемы «у меня работает, у клиента нет» AAAA стоит смотреть отдельно.

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

CDN не гарантирует, что каждый запрос сразу обслуживается с edge. Один посетитель получает HIT, другой — MISS, а для третьего правило кеширования может дать BYPASS. Поэтому десятый прогретый запрос владельца и первый запрос нового пользователя — разные условия.

HIT и MISS — принципиально разные ситуации

Для просмотра заголовков можно начать с:

curl -I https://example.com/

HEAD-запрос подходит для быстрой проверки, но отдельные CDN и origin могут обрабатывать HEAD и GET не совсем одинаково. Если нужна более репрезентативная проверка реального GET-запроса:

curl -sS -D - -o /dev/null https://example.com/

Смотрите на Age, Cache-Control, CF-Cache-Status, X-Cache, Via и Server. Например, CF-Cache-Status: HIT означает, что объект уже найден в кеше Cloudflare, а CF-Cache-Status: MISS — что edge пришлось получить его с origin.

Почему динамическая страница всё равно идёт на origin

Изображения, CSS и JavaScript обычно кешируются проще, чем HTML. Cookie авторизованного пользователя, параметры query string, персонализированная корзина WooCommerce или правила CDN могут исключить страницу из кеша. Внешне CDN подключён, но сам HTML-документ всё равно запрашивается у origin-сервера.

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

Когда сервер быстрый, а страница всё равно тормозит

Быстрый HTML ещё не означает быстрый рендеринг. После получения документа браузер скачивает CSS, JavaScript, шрифты и изображения, строит DOM, выполняет скрипты, рассчитывает layout и отрисовывает страницу. На слабом смартфоне эта часть цепочки может занять намного больше времени, чем на рабочем компьютере владельца.

Быстрый HTML не гарантирует быстрый рендеринг

Если TTFB нормальный, но пользователь несколько секунд смотрит на пустую или недособранную страницу, откройте DevTools → Performance и сравните запись с Network waterfall. Долгие задачи в основном потоке, тяжёлый JavaScript bundle, синхронные скрипты и сложный layout обычно видны в профиле.

Lighthouse полезен как лабораторный тест, но один итоговый балл не заменяет диагностику. Для конкретной жалобы важнее увидеть, когда пришёл HTML, когда появился LCP-элемент, чем занят основной поток и какой запрос блокирует критический путь.

Сторонний JavaScript как отдельный источник задержки

Чаты, аналитика, карты, рекламные системы, виджеты отзывов и внешние шрифты работают за пределами вашего сервера. Если такой ресурс отвечает медленно или выполняет тяжёлый JavaScript, страница может ощущаться «тормозной» даже при хорошем ответе Nginx и PHP-FPM.

Временно отключите подозрительный сторонний ресурс на тестовой копии или заблокируйте его в DevTools и повторите запись Performance. Если задержка исчезает, причина уже намного конкретнее, чем абстрактная «медленная страница».

Какие данные нужны, чтобы воспроизвести жалобу пользователя

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

Минимально стоит получить:

• точный URL страницы;
• примерное время возникновения проблемы;
• страну или город;
• провайдера или мобильного оператора;
• Wi-Fi или мобильную сеть;
• браузер и устройство;
• первый это визит или повторное открытие.

Для технически подготовленного пользователя можно запросить HAR, скрин Network waterfall или результат traceroute. HAR особенно полезен, когда проблему нельзя поймать со своей стороны: он показывает последовательность запросов, статусы, размеры и временные интервалы. Перед передачей HAR нужно проверить файл и при необходимости удалить чувствительные данные — cookies, authorization headers, токены и URL с приватными параметрами.

Региональный тест или VPN помогают приблизительно воспроизвести географию, но не повторяют маршрут конкретного ISP. Если жалоба привязана к оператору, ценнее получить mtr именно из этой сети.

Фраза «сайт медленный» почти бесполезна, пока неизвестны страница, сеть и момент задержки. Не лечим скорость вообще — воспроизводим конкретный запрос.

В каком порядке проверять проблему, чтобы не менять всё подряд

Оптимизировать сервер имеет смысл только после того, как измерения показали задержку на стороне origin или приложения. Если время теряется на DNS, TLS, маршруте, CDN или JavaScript, дополнительные CPU и RAM не устранят причину.

Проверять удобно в таком порядке:

1. Открыть проблемную страницу в инкогнито с отключенным HTTP-кешем и повторить тот же URL через другую сеть.
2. Через curl сравнить DNS, TCP/TLS, TTFB и общее время.
3. Проверить A и AAAA, а при рабочем IPv6 отдельно выполнить curl -4 и curl -6.
4. Посмотреть Network waterfall и найти самые долгие запросы.
5. Проверить статус кеша CDN: HIT, MISS, BYPASS или его аналог.
6. Если жалобы региональные, получить mtr или traceroute из проблемной сети.
7. Только при подтверждённо высоком TTFB переходить к CPU, RAM, disk I/O, PHP-FPM, базе данных и логам приложения.

На серверной стороне уже уместно смотреть загрузку CPU, нехватку памяти, I/O wait, очередь PHP-FPM, slowlog, медленные SQL-запросы и access/error log Nginx или Apache. До этого этапа нужно дойти измерениями, а не предположением «наверное, хостинг слабый».

Короткий чек-лист

• Проверить страницу без обычного браузерного кеша и через вторую сеть.
• Сравнить DNS, TCP/TLS и TTFB.
• Проверить A, AAAA и доступность IPv6.
• Посмотреть Network waterfall и сторонние запросы.
• Проверить HIT/MISS CDN.
• При региональной проблеме получить mtr/traceroute из проблемной сети.
• После каждого изменения повторить тот же тест в тех же условиях.

Одна правка — один повторный замер. Если одновременно изменить CDN, кеш, PHP и настройки веб-сервера, даже улучшение не покажет, что именно помогло. Нормальная диагностика исключает классы проблем по очереди, пока не останется конкретный участок, где действительно теряется время.