Сайт тормозит на VPS: диагностика

MAATRIX

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

Первым делом: где именно теряется время

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

Ключевой показатель серверной части — время до первого байта (TTFB): сколько сервер думал, прежде чем начал отвечать. Его легко измерить простым запросом, который покажет разбивку по этапам:

curl -w "connect: %{time_connect}s | ttfb: %{time_starttransfer}s | total: %{time_total}s\n" -o /dev/null -s https://ваш-сайт

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

Диагностика на стороне сервера

Если TTFB высокий, начните с общего состояния сервера. Посмотрите нагрузку на процессор, память и диск в реальном времени — часто торможение объясняется банальной перегрузкой одного из ресурсов:

htop

Обратите внимание на load average относительно числа ядер, на объём свободной памяти и на то, не ушла ли система в своп. Уход в своп — частая причина резкого замедления: когда оперативной памяти не хватает, система начинает использовать диск как память, и всё замедляется в разы. Проверьте и загрузку диска: высокий iowait означает, что сервер простаивает в ожидании медленного накопителя, и тогда узкое место — диск, а не вычисления.

Если ресурсы сервера в норме, а TTFB всё равно велик, значит время уходит внутри приложения — в генерации страницы или в запросах к базе. Здесь диагностику продолжают уже на уровне кода и СУБД, к чему мы и переходим. Важно двигаться именно в этом порядке: сначала исключить нехватку ресурсов, потом искать медленный код, иначе можно долго оптимизировать запросы на сервере, который просто задыхается от нехватки памяти.

Медленная база данных

База — самый частый виновник высокого TTFB на динамических сайтах. Один тяжёлый запрос без индекса, выполняющийся на каждой странице, способен растянуть ответ на секунды. Включите журнал медленных запросов в вашей СУБД — он записывает всё, что выполняется дольше заданного порога, и почти всегда виновником оказываются один-два конкретных запроса.

Разобравшись, какие запросы медленные, ищите причину: чаще всего это отсутствие нужного индекса, из-за чего база перебирает всю таблицу вместо мгновенного поиска. Добавление индекса нередко ускоряет запрос в сотни раз. Вторая частая беда — раздутая база, забитая мусором от плагинов и старыми данными: её стоит регулярно чистить. Третья — нехватка памяти под кэш базы, из-за чего она постоянно читает с диска вместо оперативной памяти. Оптимизация базы почти всегда даёт больший эффект, чем апгрейд железа, и начинать надо именно с неё.

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

Полезно также понимать разницу между разовым и систематическим торможением. Если страница медленно открылась один раз, а потом летает — виноват холодный кэш или разовый фоновый процесс, и это не проблема. А вот стабильно высокий TTFB на каждой загрузке — это система, которую нужно разбирать по-настоящему. Не гоняйтесь за случайными подтормаживаниями: диагностику стоит вести по устойчивой, воспроизводимой медленности, которую видно на нескольких повторных замерах, иначе легко «чинить» то, что не сломано.

Кэш и тяжёлый фронтенд

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

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

Сеть, локация и CDN

Если время соединения велико, а сама генерация быстрая, дело в расстоянии между сервером и посетителем. Каждый километр — это задержка, и сайт на сервере в другом полушарии будет ощутимо медленнее для местной аудитории, даже если сам сервер мощный. Проверьте пинг от вашей аудитории до сервера: большие значения прямо указывают на неудачную локацию.

Решений два. Первое — разместить сервер ближе к основной аудитории: для российских посетителей это сервер в России, для европейских — в Европе. Второе — подключить CDN, который кэширует статику на узлах по всему миру и отдаёт её с ближайшего к посетителю. Для контентных сайтов с картинками и видео CDN снимает и задержку, и нагрузку с основного сервера. Если аудитория распределена, сочетание правильной локации основного сервера и CDN даёт лучший результат.

Пошаговый чеклист диагностики

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

Если же сервер отвечает быстро, а тормозит отрисовка — займитесь фронтендом: сжатие, оптимизация картинок, объединение скриптов. А если велика сетевая задержка — оцените локацию и подключите CDN. Двигаясь по этому списку сверху вниз, вы не перескакиваете через звенья и не тратите время на оптимизацию того, что и так работает быстро. Методичность здесь важнее скорости: случайные правки вслепую чаще маскируют проблему, чем решают.

Когда виноват сам сервер

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

Отдельная причина, которую стоит исключить, — перепроданный хостинг, где соседи по железу отъедают ресурсы, и ваш сайт тормозит без вины с вашей стороны. Признак — высокий steal time в мониторинге. В этом случае никакая оптимизация не поможет, и настоящее решение — сервер с гарантированными ресурсами и быстрым NVMe-диском. Быстрый предсказуемый сервер — это фундамент, на котором оптимизация даёт полную отдачу, а не борется с проседающим под вами железом.

Частые вопросы