Почему сайт долго грузится: диагностика и главные причины

Когда пользователи спрашивают, почему сайт долго грузится, проблема не всегда в «тяжёлом фронтенде» или слабом сервере. Медленная загрузка складывается из нескольких этапов: DNS, TCP/TLS-соединение, ожидание ответа сервера, скачивание HTML, загрузка CSS/JS/изображений, выполнение JavaScript и отрисовка страницы.

Для владельца сайта это выглядит одинаково: страница открывается 5–10 секунд, иногда зависает, иногда «оживает» после обновления. Для разработчика и DevOps-инженера это разные классы проблем. Высокий TTFB указывает на сервер, базу данных или сеть до origin. Долгая отрисовка при нормальном TTFB — чаще на фронтенд. Медленная загрузка только из отдельных регионов — повод смотреть CDN, DNS, маршруты и блокировки.

Ниже — практический разбор: какие метрики смотреть, как быстро сузить область поиска и какие причины чаще всего делают сайт медленным.

Сначала разделите загрузку на этапы

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

1) DNS lookup — время, за которое доменное имя превращается в IP-адрес. Если DNS отвечает медленно или нестабильно, браузер ещё не начал подключаться к серверу, а пользователь уже ждёт. Для диагностики пригодятся dig, nslookup, данные браузера и внешние проверки. Подробнее о механике резолвинга — в статье как работает DNS.

2) TCP connect — установка соединения с сервером. Долгий connect обычно связан с сетью, маршрутизацией, перегрузкой сервера, фаерволом или проблемами у хостинга.

3) TLS handshake — установка HTTPS-сессии. Если сертификаты, цепочка, SNI/ALPN или TLS-настройки работают некорректно, соединение может устанавливаться долго или периодически падать. Базу по HTTPS можно освежить в материале как работает HTTPS.

4) TTFB — Time To First Byte, время до первого байта ответа. Высокий TTFB обычно означает, что браузер уже подключился, но сервер долго готовил ответ: выполнял код, ждал базу данных, обращался к внешнему API или упёрся в ресурсы.

5) Content download — скачивание HTML и остальных ресурсов. Здесь влияют размер файлов, сжатие, HTTP/2 или HTTP/3, CDN и пропускная способность канала.

6) Rendering — парсинг, выполнение JavaScript, построение DOM/CSSOM, layout, paint. Если HTML приходит быстро, а пользователь долго видит пустой экран, причина обычно в большом JS-бандле, блокирующих скриптах или неудачном SSR/CSR.

Разделяйте два сценария: «сервер долго отвечает» и «страница долго становится интерактивной». Они лечатся разными инструментами.

Быстрая диагностика: как понять, где тормозит

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

1) Проверьте страницу в браузере — откройте DevTools → Network, включите Disable cache и перезагрузите страницу. Смотрите waterfall: где самая длинная полоса, сколько занимает Waiting for server response, какие ресурсы блокируют загрузку, есть ли ошибки 4xx/5xx.

Если главный HTML-документ долго находится в состоянии Waiting, проблема ближе к серверу. Если HTML пришёл быстро, но затем грузятся мегабайты JS, шрифтов и изображений — смотрите фронтенд и статику.

2) Измерьте время ответа через curl — команда позволяет разложить запрос по этапам: curl -o /dev/null -s -w "%{time_namelookup} %{time_connect} %{time_appconnect} %{time_starttransfer} %{time_total}\n" https://example.com. Значения покажут DNS, TCP, TLS, TTFB и общее время. Если редко пользуетесь curl, пригодится инструкция что такое curl и как им пользоваться.

3) Сравните разные точки проверки — сайт может быть быстрым из Москвы и медленным из Европы, Казахстана или Дальнего Востока: причины в маршрутах, CDN, блокировках или перегруженном провайдере. Для постоянного контроля полезен внешний мониторинг вроде Statuser — он проверяет сайт с заданным интервалом и присылает уведомление, если ответ стал ошибочным или сайт перестал открываться.

4) Проверьте логи сервера — в access-логах Nginx/Apache ищите время обработки запроса, статус-коды, upstream-время, IP-адреса, User-Agent. В error-логах — таймауты, ошибки соединений, проблемы с upstream.

5) Сравните динамические и статические URL — если /assets/app.js отдаётся быстро, а /catalog медленно, причина, вероятно, в приложении или базе. Если всё медленно, включая картинки и CSS, смотрите сеть, диск, Nginx, CDN, лимиты хостинга.

6) Проверьте повторяемость — разовый медленный запрос может быть прогревом кэша, cold start или сетевым всплеском. Постоянный высокий p95/p99 — уже системная проблема.

Высокий TTFB: сервер отвечает слишком долго

Если первый байт приходит через 2–5 секунд, фронтенд-оптимизация не спасёт ощущение медленного сайта: браузер просто ждёт сервер.

1) Приложение выполняет тяжёлую логику — генерация страницы, сложные агрегации, обращение к нескольким сервисам, построение меню, персонализация, проверка прав, SSR. Частая ошибка — собирать слишком много данных для первого экрана.

Что делать: профилировать обработчики, выносить тяжёлые операции в фоновые задачи, кэшировать результат, отдавать часть данных после первого рендера, ограничивать объём выборок.

2) База данных отвечает медленно — отсутствие индексов, неоптимальные JOIN, сортировка по большим таблицам, блокировки, нехватка соединений, медленный диск. Проверьте slow query log, планы запросов, блокировки, количество активных соединений. Если подозреваете индексы, полезен материал как работает database indexing: сам факт наличия индекса ещё не гарантирует быстрый запрос.

3) Нет кэша или он неэффективен — каждый запрос заново строит одно и то же: главную страницу, карточку товара, список категорий, настройки сайта. Это особенно заметно после рекламной рассылки или публикации ссылки в соцсетях.

Что делать: HTTP-кэш, application cache, Redis/Memcached, fragment caching, CDN-кэш для публичных страниц. Следите за инвалидацией, иначе получите быстрый, но устаревший контент.

4) Внешние API тормозят страницу — платёжный сервис, CRM, рекомендации, доставка, авторизация, аналитика на сервере. Если запрос к внешнему сервису выполняется синхронно при рендере страницы, его задержка становится задержкой пользователя.

Решение: таймауты, circuit breaker, fallback-данные, асинхронная загрузка, кэширование ответов, очереди для необязательных операций.

5) Сервер упёрся в ресурсы — CPU, RAM, диск, лимит процессов, пул соединений, файловые дескрипторы. При насыщении ресурса среднее время ответа может быть нормальным, но хвостовые задержки растут: часть пользователей ждёт очень долго.

Смотрите не только среднее, но и p95/p99, load average, iowait, swap, очередь запросов, GC-паузы. Если сайт «то быстрый, то медленный», проблема часто именно в хвостовых задержках.

Проблемы сети, DNS и TLS

Иногда приложение работает нормально, но путь до него медленный — с сервера всё выглядит здоровым, а пользователи жалуются.

1) Медленный DNS — домен обслуживается нестабильными DNS-серверами, есть проблемы с делегированием, некорректные записи, слишком короткий или слишком длинный TTL. Браузер не начнёт подключение, пока не получит IP. Проверьте A, AAAA, CNAME, NS, DNSSEC, ответы из разных сетей. Если после смены IP часть пользователей идёт на старый адрес, причина может быть в DNS-кэше.

2) Неудачный IPv6 — домен имеет AAAA-запись, но IPv6-маршрут или сервер настроены плохо. Некоторые клиенты сначала пробуют IPv6, ждут таймаут и только потом переключаются на IPv4 — для пользователя это выглядит как задержка перед открытием сайта. Проверьте доступность по IPv4 и IPv6 отдельно; если IPv6 работает нестабильно, лучше временно убрать AAAA, чем оставлять полурабочую конфигурацию.

3) TLS-рукопожатие занимает слишком много времени — длинная цепочка сертификатов, ошибки OCSP, старые протоколы, отсутствие session resumption, неправильный SNI, перегруженный reverse proxy. На единичном запросе это может быть незаметно, но при большом количестве ресурсов задержка накапливается.

4) Плохая маршрутизация до сервера — пользователь далеко от origin, маршрут проходит через перегруженные узлы, пакеты теряются, растут retransmits. Диагностируйте через mtr, traceroute, мониторинг TCP-соединений и проверки из разных регионов.

5) Фаервол или rate limiting режет легитимный трафик — слишком агрессивные правила могут задерживать или блокировать часть запросов, иногда только у мобильных операторов, корпоративных сетей или пользователей за NAT.

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

Фронтенд: тяжёлые ресурсы и блокирующий JavaScript

Если TTFB нормальный, но страница всё равно долго грузится, переходите к фронтенду. Частый симптом: HTML приходит быстро, но пользователь несколько секунд видит белый экран, скелетон или неактивный интерфейс.

1) Слишком большой JavaScript-бандл — браузер должен скачать, распаковать, распарсить и выполнить JS. На мощном ноутбуке это терпимо, на бюджетном смартфоне — долго, особенно в SPA, где без JS не отображается основной контент. Решение: code splitting, lazy loading, tree shaking, удаление лишних библиотек, перенос тяжёлых виджетов за первый экран. Практические подходы разобраны в статье про Lazy Loading и Code Splitting.

2) Рендер блокируют CSS и шрифты — большие CSS-файлы, несколько webfont-вариантов, отсутствие font-display, невыделенный критический CSS. Браузер ждёт ресурсы, без которых не может корректно отрисовать страницу. Что делать: минимизировать CSS, удалять неиспользуемые стили, аккуратно использовать preload, настроить font-display: swap, не подключать лишние начертания шрифтов.

3) Изображения слишком большие — баннер весит несколько мегабайт, на мобильный отдаётся desktop-версия, нет srcset, не используются WebP/AVIF, картинки грузятся до первого экрана без необходимости. Оптимизация изображений часто даёт быстрый эффект: сжатие, современные форматы, адаптивные размеры, lazy loading, CDN image resizing. Подробнее — в материале как оптимизировать изображения на сервере.

4) Сторонние скрипты мешают загрузке — аналитика, чаты, A/B-тесты, рекламные пиксели, карты, виджеты отзывов. Каждый скрипт — это ещё один DNS, TLS, скачивание, выполнение и риск, что чужой сервис затормозит вашу страницу. Подключайте сторонний код асинхронно, откладывайте необязательные виджеты, проверяйте влияние каждого скрипта в waterfall.

5) Нет сжатия и правильных заголовков — HTML, CSS, JS должны отдаваться с gzip или br. Статические ресурсы — с корректными Cache-Control, ETag или версионированными именами файлов, иначе пользователи скачивают одно и то же снова.

CDN, кэширование и география пользователей

CDN помогает, когда пользователи находятся далеко от origin или сайт отдаёт много статики. Но CDN — не магическая кнопка: неправильная настройка иногда делает сайт медленнее.

1) Статика не кэшируется на edge — CDN есть, но Cache-Control запрещает кэш, URL постоянно меняются, используются cookies для всех запросов, или правила CDN обходят кэш для нужных путей. В итоге каждый запрос всё равно идёт на origin. Проверьте заголовки Cache-Control, Age, CF-Cache-Status или аналог вашего CDN. Для статики нужны долгие TTL и версионирование файлов: app.8f3a.js, styles.91d.css.

2) HTML кэшируется неправильно — динамическая страница может кэшироваться там, где нельзя, или наоборот не кэшироваться там, где можно. Для публичных страниц часто уместны stale-while-revalidate, короткие TTL, кэширование фрагментов. Основы заголовков и стратегий описаны в статье как работает HTTP caching.

3) CDN выбран без учёта аудитории — edge-узлы могут быть далеко от ваших пользователей. Если основная аудитория в России и СНГ, а ближайшие узлы CDN фактически обслуживают трафик через удалённые регионы, выигрыш будет слабым.

4) Origin всё равно остаётся узким местом — CDN ускоряет статику и кэшируемые ответы, но не решает медленные запросы к базе, неоптимальный SSR или внешние API. Если MISS на CDN стабильно медленный, лечить нужно origin.

5) Неправильная связка CDN и TLS — ошибки сертификата, режимы проксирования, редиректы HTTP→HTTPS→HTTP, несовпадение хостов, длинные цепочки. В таких случаях появляются не только задержки, но и нестабильная доступность.

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

Нагрузка, очереди и периодические замедления

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

1) Пиковая нагрузка — реклама, рассылка, публикация в медиа, индексация ботами, сезонный спрос. Если сервер рассчитан на средний трафик, всплеск быстро приводит к очередям в веб-сервере, приложении, базе, пуле соединений. Смотрите RPS, latency, 5xx, количество активных соединений, очередь запросов, CPU, iowait, память, swap.

2) Боты и сканеры — поисковые роботы, парсеры, уязвимость-сканеры могут создать заметную нагрузку, иногда ходят по тяжёлым страницам: фильтрам, поиску, пагинации, параметризованным URL. Решения: robots.txt, rate limiting, кэширование, защита тяжёлых endpoint-ов, отдельные правила для известных ботов.

3) Периодические фоновые задачи — бэкапы, генерация отчётов, импорт товаров, пересчёт индексов, cron-задачи. Они конкурируют с сайтом за CPU, диск, базу и сеть, и пользователь видит медленную загрузку, хотя проблема началась не в веб-приложении. Разносите тяжёлые задачи по времени, ограничивайте ресурсы, используйте очереди, следите за длительностью job-ов.

4) Холодные старты и прогрев кэша — после деплоя, рестарта контейнера или очистки кэша первые запросы могут быть медленными. Если деплой происходит часто, пользователи регулярно попадают в «холодное» состояние. Помогают graceful shutdown, предварительный прогрев, blue-green deployment, readiness-пробы, сохранение кэша между релизами.

5) Проблемы в контейнерах и лимитах — приложение может упираться в CPU quota, memory limit, throttling, лимиты файловых дескрипторов. На графиках хоста всё выглядит нормально, но контейнер живёт в более жёстких рамках. Проверяйте метрики контейнеров отдельно: throttling, OOM, рестарты, сетевые ошибки, лимиты cgroups.

Как выстроить постоянный контроль скорости

Разовая проверка помогает найти текущую причину, но не защищает от повторения. Для сайта важна не только доступность, но и стабильное время ответа.

1) Мониторьте доступность и latency снаружи — внешняя проверка показывает, как сайт виден пользователю, а не только что происходит внутри сервера. Для этого подойдёт тот же Statuser: важно хранить не только факт сбоя, но и историю времени ответа и статус-кодов.

2) Разделяйте технические и пользовательские метрики — серверные метрики показывают CPU, RAM, диск, базу, очереди; синтетические проверки — доступность URL и время ответа; RUM — реальный опыт пользователей в браузерах. Эти уровни дополняют друг друга.

3) Настройте пороги не только по ошибкам — алерт на 500 полезен, но деградация часто начинается раньше: растёт TTFB, увеличивается p95, база отвечает медленнее, набирается очередь запросов. Хороший алерт ловит ухудшение до массового отказа.

4) Храните контекст релизов — отмечайте деплои, миграции, изменения CDN, обновления зависимостей, смену тарифов хостинга. Если после релиза выросло время ответа, расследование начинается быстрее.

5) Проверяйте ключевые страницы отдельно — главная, каталог, поиск, карточка товара, авторизация, API health endpoint. Один URL может быть быстрым, а бизнес-критичный сценарий — медленным.

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

Чеклист: что проверить в первую очередь

Если сайт начал долго грузиться прямо сейчас, действуйте по порядку.

1) Откройте DevTools и найдите главный тормоз — HTML, JS, CSS, изображения, шрифты, сторонние скрипты. Сравните TTFB и полное время загрузки.

2) Проверьте curl с таймингами — разделите DNS, TCP, TLS, TTFB, total. Повторите несколько раз.

3) Сравните разные сети — домашний интернет, мобильный оператор, VPN, сервер в другом регионе, внешний мониторинг.

4) Посмотрите access/error-логи — статусы, upstream time, таймауты, всплески 5xx, медленные URL.

5) Проверьте ресурсы сервера — CPU, RAM, disk I/O, load average, swap, лимиты контейнеров, рестарты.

6) Проверьте базу данных — slow queries, locks, connection pool, индексы, нагрузку на диск.

7) Проверьте кэш и CDN — заголовки, cache hit/miss, TTL, правила для HTML и статики.

8) Отключите или отложите необязательное — тяжёлые виджеты, внешние API, скрипты аналитики, фоновые задачи. Это не финальное решение, но быстрый способ подтвердить гипотезу.

Главный принцип: сначала локализовать этап задержки, потом оптимизировать — иначе есть риск улучшить то, что не было узким местом.

FAQ

Почему сайт долго грузится только у части пользователей?
Чаще всего причина в географии, провайдере, DNS, IPv6, маршрутизации, CDN или локальном кэше. Сравните проверки из разных регионов и сетей.

Какой TTFB считать плохим?
Единого порога нет: зависит от типа сайта и географии. Но если TTFB стабильно измеряется секундами, проблему почти всегда нужно искать на сервере, в базе, сети или кэше.

CDN всегда ускоряет сайт?
Нет. CDN помогает со статикой, географией и кэшируемыми страницами. Если origin медленно генерирует динамический HTML, CDN без правильного кэширования не решит проблему.

Почему после деплоя сайт стал медленнее?
Возможны новые тяжёлые запросы, рост JS-бандла, сброшенный кэш, миграции базы, изменение конфигурации Nginx/CDN или cold start приложения. Сравните метрики до и после релиза.