Как ускорить загрузку сайта на VPS

MAATRIX

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

Сначала измерьте, что тормозит

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

curl -w "time_total: %{time_total}s\n" -o /dev/null -s http://localhost/

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

Включите кеширование

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

Для динамических сайтов на PHP включите кеш на уровне приложения (в WordPress — плагины кеширования, в самописных проектах — Redis или Memcached для данных и запросов). На уровне веб-сервера настройте кеширование ответов: nginx умеет складывать сгенерированные страницы и отдавать их из кеша, не тревожа бэкенд. Отдельно включите кеширование на стороне браузера, задав заголовки для статики, чтобы повторные визиты не перекачивали одни и те же файлы:

location ~* \.(jpg|jpeg|png|gif|css|js|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

Этот блок говорит браузеру хранить статику месяц и не запрашивать её заново. Уже одно это заметно ускоряет повторные загрузки и снижает нагрузку на сервер.

Сжатие и современные протоколы

Передавать несжатый текст — расточительство. Включите gzip или более эффективный brotli, чтобы HTML, CSS и JavaScript уходили к посетителю в разы меньшего размера. В nginx это делается парой директив:

gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;
gzip_comp_level 5;

Сжатие уменьшает объём текстовых файлов на 60–80% почти без нагрузки на процессор. Параллельно убедитесь, что включён HTTP/2: он мультиплексирует запросы и грузит множество мелких файлов заметно быстрее старого HTTP/1.1. Для этого нужен работающий HTTPS — добавьте http2 в директиву listen и проверьте, что сертификат на месте. Современный протокол особенно ощутим на страницах с десятками картинок и скриптов.

Оптимизируйте статику и базу

Часто основной вес страницы — это картинки. Огромные неоптимизированные изображения способны в одиночку убить скорость. Сжимайте картинки перед загрузкой, отдавайте их в современных форматах вроде WebP, задавайте правильные размеры вместо масштабирования гигантских оригиналов средствами браузера. Объедините и минифицируйте CSS и JavaScript, уберите неиспользуемые скрипты и сторонние виджеты, которые тянут загрузку.

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

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

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

Отдавайте статику эффективно

Пусть тяжёлую статику отдаёт веб-сервер напрямую, а не приложение. nginx раздаёт файлы кратно быстрее и экономнее, чем PHP или Node через прослойку. Убедитесь, что картинки, стили и скрипты идут через location веб-сервера, а не проходят через бэкенд. Для географически распределённой аудитории имеет смысл поставить перед сайтом CDN, который отдаёт статику с ближайшей к посетителю точки, но базовую скорость нужно сначала выжать из самого сервера.

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

Когда дело в тарифе

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

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