Коротко. Медленная загрузка раскладывается на фазы: разрешение DNS, установка TCP/TLS, время до первого байта (TTFB) и рендеринг в браузере. Чтобы ускорить сайт, сначала замерьте, какая фаза тормозит — командой curl -w. Если велик TTFB — проблема на сервере (медленный бэкенд, БД, отсутствие кэша). Если велик рендер — это фронтенд (большие JS/CSS, неоптимизированные картинки). Начните с замера, а не с догадок.
Разложите загрузку на фазы
Главная ошибка — оптимизировать наугад. Сначала измерьте, где именно теряется время:
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
# Пример вывода:
# dns:0.012 connect:0.045 tls:0.120 ttfb:0.890 total:1.230
# Большой ttfb (0.89s) при малом connect = тормозит серверTTFB (time to first byte) — главный индикатор серверной скорости. Если до первого байта проходит больше 600 мс, оптимизировать картинки бессмысленно — узкое место на бэкенде.
Что означает каждая фаза
| Фаза (curl) | Что измеряет | Если велика — причина |
|---|---|---|
| time_namelookup | Разрешение DNS | Медленный/далёкий DNS-резолвер |
| time_connect | TCP-рукопожатие | Сетевая задержка, далёкий сервер |
| time_appconnect | TLS-рукопожатие | Тяжёлый TLS, отсутствие session resumption |
| time_starttransfer (TTFB) | Время до первого байта | Медленный бэкенд, БД, нет кэша |
| time_total | Полная загрузка документа | Большой объём ответа |
Если велик TTFB (серверная сторона)
- Включите кэширование страниц (Redis/Memcached, page cache).
- Оптимизируйте медленные SQL-запросы — добавьте индексы, проверьте EXPLAIN.
- Уберите N+1 запросы и тяжёлые вызовы внешних API документацию в синхронном коде.
- Поднимите OPcache/JIT для PHP, проверьте число воркеров PHP-FPM.
- Проверьте загрузку CPU/RAM — сервер может быть перегружен.
Если велик рендер (фронтенд)
- Сожмите и минифицируйте CSS/JS, уберите неиспользуемый код.
- Оптимизируйте изображения: WebP/AVIF, правильные размеры, lazy-loading.
- Уберите рендер-блокирующие скрипты, используйте defer/async.
- Включите HTTP/2 или HTTP/3 и keep-alive.
- Подключите CDN для статики ближе к пользователю.
Если велик DNS/TCP/TLS (сеть)
- Большой DNS — смените резолвер или используйте быстрый авторитетный DNS.
- Большой connect — сервер физически далеко; CDN или ближний регион помогут.
- Большой TLS — включите TLS 1.3, OCSP stapling и session resumption.
Если сайт быстр из одного региона и медленный из другого — это сетевая дистанция. Один сервер не может быть одинаково быстрым по всему миру без CDN.
Сравните несколько прогонов
Один замер обманчив — сделайте 3-5 прогонов, чтобы исключить случайность и увидеть прогрев кэша:
for i in 1 2 3 4 5; do
curl -o /dev/null -s -w "ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com
doneПервый прогон холодный (кэш пуст), последующие должны быть быстрее. Если TTFB стабильно высок — кэш не работает.
Как enterno.io помогает
PageSpeed-проверка enterno.io разбирает загрузку на метрики (LCP, FCP, TBT, CLS) и показывает, что именно тормозит — сервер или фронтенд. HTTP-чекер показывает заголовки кэширования и сжатия. Мониторинг аптайма пишет время отклика каждой проверки, так что вы видите деградацию TTFB во времени, а не только в моменте. Мультирегиональная проверка (RU/EU/US) показывает, медленно ли везде или только из одного региона — это сразу указывает на сетевую дистанцию против серверной проблемы. Алерты по росту времени отклика — Telegram/Slack/email/webhook. enterno.io измеряет и предупреждает; саму оптимизацию делает владелец.
FAQ
Какой TTFB считается нормальным?
Хороший TTFB — до 200 мс, приемлемый — до 600 мс. Выше 600 мс — явный сигнал оптимизировать бэкенд и кэш.
Сайт быстрый у меня, но клиент жалуется на медленность?
Замерьте из его региона. Скорее всего, дело в сетевой дистанции до сервера — поможет CDN или региональный мониторинг сайтов для подтверждения.
С чего начать оптимизацию?
С замера фаз через curl -w. Сначала узнайте, где теряется время, потом чините именно это, а не всё подряд.
Помогает ли просто включить Cloudflare?
CDN ускоряет статику и TLS, но не лечит медленный бэкенд. Если велик TTFB на динамике, нужен серверный кэш и оптимизация запросов.
Следующий шаг: прогоните сайт через PageSpeed-проверку и посмотрите заголовки в HTTP-чекере. См. также гайд по мониторингу и включите отслеживание времени отклика.