Skip to content Медленный сайт на VPS тормозит почти всегда в одном из двух мест. Либо сервер долго собирает страницу, либо браузер долго скачивает и рисует то, что ему отдали. Лечится это совершенно по-разному, и большая часть советов из интернета бьёт мимо как раз потому, что место поломки никто не определил. Так что первые пять минут уходят на замер, а настройка начинается после него.
Если нужно прямо сейчас
Короткий порядок действий для тех, кому некогда читать дальше:
- С домашнего компьютера (не с самого сервера) три раза подряд выполни команду ниже и посмотри на строку TTFB.
- TTFB больше 0,8 секунды: тормозит сервер. Включи кэш страниц (плагин для WordPress или FastCGI-кэш в nginx) и проверь, что работает OPcache.
- TTFB в норме, а страница целиком грузится три-пять секунд: сервер почти ни при чём. Смотри на картинки, шрифты и скрипты темы.
- Проверь, что nginx сжимает CSS и JS, а не только HTML. В стандартном конфиге Debian и Ubuntu сжимается один HTML.
- Открой
topи глянь на память, swap и значениеstв строке CPU. Если сервер упирается в железо, настройками это не вылечить. - Перемерь. Без второго замера не узнать, что из сделанного сработало.
curl -o /dev/null -s -w 'connect: %{time_connect}\ntls: %{time_appconnect}\nttfb: %{time_starttransfer}\ntotal: %{time_total}\n' https://example.com/Вместо example.com подставь свой адрес. Если ты ещё ни разу не заходил на сервер из терминала, сначала пригодится статья про подключение к VPS по SSH.
Замер: где именно теряется время
Цифры, которые печатает curl, накопительные: каждая считается от момента запуска команды. Поэтому читать их надо разностями.
connect показывает, сколько ушло на установку соединения, т.е. фактически расстояние до сервера. Разница между tls и connect уходит на HTTPS-рукопожатие. А вот разница между ttfb и tls и есть чистое время, которое сервер думал над твоей страницей: запускал PHP, ходил в базу, собирал HTML. Допустим, вышло так: connect 0,04, tls 0,09, ttfb 1,62. Сеть и шифрование заняли меньше десятой доли секунды, а полторы секунды сервер собирал страницу. Тут помогут кэш и настройка PHP, а переезд в другой дата-центр не даст почти ничего.
Ориентиры такие. Google в своих материалах по Web Vitals считает хорошим TTFB до 0,8 секунды. Страница, отданная из кэша с сервера в той же стране, обычно укладывается в 0,05–0,3 секунды. WordPress без кэша с десятком-другим плагинов на недорогом VPS чаще всего выдаёт 0,6–2 секунды, и это не признак поломки, а нормальная работа PHP без кэша.
Полезный трюк: выполни ту же команду прямо на сервере. Сеть из уравнения выпадает, и если там тоже полторы секунды, сомнений не остаётся.
С PageSpeed Insights, которым все меряют скорость, своя путаница: в отчёте два разных блока. Верхний (если он есть) содержит данные реальных посетителей из Chrome за последние четыре недели, именно их Google учитывает при ранжировании. Нижний, с крупной оценкой от 0 до 100, получен в лаборатории: эмуляция недорогого телефона на медленной мобильной сети. Цифра в лаборатории скачет от запуска к запуску на 5–10 пунктов просто так. У небольших сайтов блока с реальными данными часто нет вовсе, трафика не хватает. Гнаться за сотней в лабораторном тесте можно бесконечно, и я бы сказал, что после 80–85 баллов на мобильных это уже занятие для души, а не для посетителей.
Если всё упирается в TTFB, читай дальше по порядку. Если TTFB хороший, а сайт всё равно вязкий, можно сразу перейти к разделу про картинки и скрипты.
Почему на своём VPS бывает медленнее, чем на shared-хостинге
«Переехал с хостинга на VPS, плачу больше, а сайт стал открываться медленнее». Обращения с такой формулировкой приходят регулярно, и обидно в них то, что сервер обычно ни в чём не виноват.
Хороший shared-хостинг отдаёт сайт через стек, который провайдер годами подкручивал под тысячи таких же сайтов: LiteSpeed с LSCache, включённый и настроенный OPcache, база с увеличенными буферами. Чистый VPS приходит с настройками по умолчанию, а они рассчитаны на то, чтобы всё запустилось на любой машине, скорость там стоит на втором плане. Добавь сюда, что на shared сайт мог пользоваться частью большого многоядерного сервера, а на младшем VPS у него один честный vCPU. Подробнее про разницу двух вариантов есть в статье shared-хостинг или VPS, а если переезд ещё впереди, пригодится разбор того, как перенести сайт на VPS.
Кэш страниц: самый крупный выигрыш
Без кэша каждый заход посетителя выглядит одинаково. Запускается PHP, WordPress (или другой движок) подгружает плагины, делает от тридцати до сотни запросов в базу и собирает HTML. Через секунду тот же путь проходит следующий посетитель, хотя страница для него точно такая же. Кэш страниц сохраняет готовый HTML и отдаёт его следующим посетителям без PHP и без базы. TTFB падает с секунды до десятков миллисекунд, а сервер выдерживает в разы больше трафика, ведь самая дорогая часть работы выполняется один раз на несколько минут.
Вариантов сделать это несколько, и у каждого своя цена.
| Вариант | Кто отдаёт кэш | Сильная сторона | Слабое место |
|---|---|---|---|
| Плагин кэша (WP Super Cache, W3 Total Cache и подобные) | PHP или nginx по отдельным правилам | Ставится за минуту, сам чистит кэш при обновлении записи | Если файлы отдаёт PHP, выигрыш заметно меньше; правила для nginx пишутся руками |
| FastCGI-кэш nginx | nginx, PHP не запускается вообще | Максимум скорости без лишних сервисов | Сам не знает, что запись изменилась; очистку нужно настроить |
| OpenLiteSpeed или LiteSpeed + LSCache | Веб-сервер | Очистка по событиям WordPress и WooCommerce из коробки | Другой веб-сервер: конфиги nginx не переносятся |
| Varnish | Отдельный сервис перед сайтом | Очень быстрый и гибкий | Сам не умеет HTTPS, нужен ещё один прокси; для новичка сложен |
На простом сайте любой вариант даст основную часть прироста, разница между ними видна уже на нагрузке и в удобстве. Если стек на сервере собран по схеме LEMP, логичнее всего FastCGI-кэш. Про LiteSpeed-путь будет отдельный разбор CyberPanel с OpenLiteSpeed, а про Varnish есть статья о кэширующем прокси перед сайтом.
Минимальная рабочая настройка FastCGI-кэша для WordPress на nginx выглядит так. Первые две строки идут в блок http {} (на Debian и Ubuntu удобно положить их отдельным файлом в /etc/nginx/conf.d/), остальное в server {} твоего сайта:
# /etc/nginx/conf.d/fastcgi-cache.conf
fastcgi_cache_path /var/cache/nginx/site levels=1:2 keys_zone=SITE:50m inactive=60m max_size=1g;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
# внутри server {}
set $skip_cache 0;
if ($request_method = POST) { set $skip_cache 1; }
if ($query_string != "") { set $skip_cache 1; }
if ($request_uri ~* "/wp-admin/|/wp-login.php|/cart/|/checkout/|/my-account/") { set $skip_cache 1; }
if ($http_cookie ~* "wordpress_logged_in|comment_author|woocommerce_items_in_cart|wp_woocommerce_session") { set $skip_cache 1; }
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
fastcgi_cache SITE;
fastcgi_cache_valid 200 301 10m;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
add_header X-Cache $upstream_cache_status;
}Версию PHP в имени сокета посмотри командой ls /run/php/, у тебя она может отличаться. Дальше nginx -t для проверки синтаксиса и systemctl reload nginx. Проверка результата в два запроса:
curl -sI https://example.com/ | grep -i x-cache
curl -sI https://example.com/ | grep -i x-cacheПервый ответ покажет MISS, второй должен показать HIT. Если видишь BYPASS, сработало одно из условий пропуска, например ты проверяешь из браузера, где залогинен в админку. Если же MISS упорно держится на каждом запросе, почти наверняка сайт ставит cookie каждому посетителю. nginx не кэширует ответы с заголовком Set-Cookie, а также с Cache-Control: no-store или private. На клиентских серверах виновником в таких случаях обычно оказывается плагин, который стартует PHP-сессию для всех подряд: мультиязычность, баннер cookie, «последние просмотренные товары». Посмотреть, кто это делает, можно через curl -sI: строки Set-Cookie и Cache-Control видны сразу.
Строка add_header в nginx ведёт себя неочевидно, и спотыкаются на ней почти все. Заголовки из add_header наследуются с уровня server внутрь location только при условии, что в самом location своих add_header нет. Добавил X-Cache в блок PHP, и все заголовки безопасности, прописанные уровнем выше, со страниц тихо пропали. Их приходится повторять внутри location или выносить в общий файл и подключать через include.
Условия пропуска в конфиге не формальность. Забыть исключить корзину и cookie WooCommerce означает однажды показать одному покупателю закэшированную корзину другого. Для интернет-магазина набор исключений обычно шире, к этому вернёмся в статье про WooCommerce на VPS.
Остаётся очистка. Отредактировал запись, а посетители ещё до десяти минут видят старую версию, ведь столько живёт кэш по fastcgi_cache_valid. Для WordPress это обычно решают плагином Nginx Helper: он умеет удалять файлы кэша при обновлении записи. Для сайта, который правится раз в неделю, хватит и короткого срока жизни. Пять-десять минут кэша на посещаемом сайте снимают с PHP почти всю нагрузку, а свежесть контента страдает мало.
PHP: OPcache и число воркеров PHP-FPM
PHP при каждом запросе заново читает и компилирует файлы скриптов. OPcache хранит уже скомпилированный код в памяти, и на WordPress это обычно сокращает время работы PHP в два-три раза. На Debian и Ubuntu он включается вместе с пакетом PHP. На сборках из некоторых панелей и в официальных Docker-образах PHP его, как правило, нужно подключать отдельно.
Проверять стоит аккуратно. Команда php -i в терминале показывает настройки консольного PHP, а сайт работает через PHP-FPM со своим php.ini (на Debian это /etc/php/8.3/fpm/php.ini против /etc/php/8.3/cli/php.ini). Надёжнее спросить сам сайт:
echo '<?php var_dump(ini_get("opcache.enable"));' > /var/www/html/oc.php
curl -s https://example.com/oc.php
rm /var/www/html/oc.phpstring(1) "1" значит, что OPcache работает. bool(false) значит, что расширение не загружено. Путь к папке сайта подставь свой и не забудь третью строку: служебные файлы в корне сайта никому не нужны.
PHP-FPM держит пул процессов-обработчиков, и параметр pm.max_children ограничивает, сколько запросов к PHP выполняется одновременно. В стандартном файле пула www.conf там стоит 5. Шестой посетитель, пришедший в момент, когда пять процессов заняты, просто ждёт в очереди, и со стороны это выглядит как случайные подвисания сайта при нормальной средней нагрузке. Сам PHP-FPM об этом честно пишет в свой лог:
WARNING: [pool www] server reached pm.max_children setting (5), consider raising itПоднимать значение вслепую нельзя. Каждый процесс ест память, и считать нужно от неё:
ps --no-headers -o rss -C php-fpm8.3 | awk '{s+=$1; n++} END {print s/n/1024 " MB"}'Команда покажет средний размер процесса. Для WordPress это обычно 50–120 МБ в зависимости от плагинов. Дальше простая арифметика. Сервер на 2 ГБ: система берёт около 300 МБ, MySQL с разумными настройками ещё 500–700. На PHP остаётся примерно гигабайт, и при процессе в 80 МБ потолок получается около 12. Подробная настройка пула (dynamic против ondemand, запасные процессы) пойдёт в отдельную статью про оптимизацию PHP-FPM.
Если перестараться и выставить 50 на том же сервере, при первом наплыве посетителей память кончится и сработает OOM killer, механизм ядра, который убивает процесс, чтобы спасти систему. Выбирает он самый крупный по памяти, а на типичном VPS с сайтом это MySQL. Отсюда классическая картина: сайт отвечает «Error establishing a database connection», хотя полчаса назад всё работало, а в journalctl -k или dmesg находится строчка про убитый mysqld. Да и на одном vCPU лишние воркеры ничего не ускоряют, если процессор и так загружен на сто процентов: очередь просто переезжает из FPM к процессору.
База данных: буфер, медленные запросы и раздутый autoload
У MySQL и MariaDB главный параметр для скорости называется innodb_buffer_pool_size. Это память, в которой база держит данные и индексы, чтобы не ходить за ними на диск. По умолчанию там 128 МБ. Если база сайта весит гигабайт, большая часть запросов идёт на диск, и даже NVMe тут проигрывает памяти. Размер баз смотрится так:
SELECT table_schema, ROUND(SUM(data_length + index_length)/1024/1024) AS mb
FROM information_schema.tables GROUP BY table_schema;Буфер имеет смысл сделать примерно равным размеру базы, но не больше трети-половины памяти сервера, иначе снова встретишься с OOM killer. На 2 ГБ разумно 512–768 МБ. Параметр прописывается в секции [mysqld]: на Ubuntu с MySQL это /etc/mysql/mysql.conf.d/mysqld.cnf, на Debian с MariaDB /etc/mysql/mariadb.conf.d/50-server.cnf. После правки нужен перезапуск службы.
Включи заодно журнал медленных запросов (slow_query_log = 1, long_query_time = 1). Через сутки в нём видно, какой запрос тормозит, и почти всегда виноват какой-нибудь плагин: статистика, фильтр товаров, «похожие записи».
Таблица wp_options у WordPress хранит настройки, и часть из них помечена на автозагрузку: они грузятся в память целиком на каждом запросе, который доходит до PHP. Плагины любят складывать туда кэши и логи и не убирают за собой после удаления. Проверка:
SELECT ROUND(SUM(LENGTH(option_value))/1024) AS kb
FROM wp_options WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');Список значений длинный, т.к. с версии 6.6 WordPress вместо привычного yes пишет в этот столбец новые варианты, и старые инструкции с autoload = 'yes' показывают только часть картины. До мегабайта всё в порядке. Несколько мегабайт уже стоит разобрать, сортируя строки по размеру и выясняя, от какого плагина остались самые крупные.
Redis как объектный кэш тоже из этой области, и на нём ожидания часто расходятся с реальностью. Он ускоряет то, что проходит через PHP: админку, страницы для залогиненных, корзину и оформление заказа. Страницы, которые уже отдаются из кэша страниц, он не ускорит, ведь PHP там не запускается. Для блога с анонимными читателями выигрыш небольшой, для магазина с личными кабинетами заметный. Подробнее в статьях про Redis и Memcached и оптимизацию MySQL на небольшом сервере.
Сжатие, HTTP/2 и кэш статики в браузере
Умолчание в стандартном nginx.conf на Debian и Ubuntu, честно говоря, странное: строка gzip on; включена, а строка gzip_types закомментирована. В итоге сжимается только HTML, а стили и скрипты, которые весят в разы больше, уходят как есть. Проверь у себя:
curl -sI -H 'Accept-Encoding: gzip' https://example.com/wp-includes/css/dist/block-library/style.min.css | grep -i content-encodingПустой ответ значит, что сжатия нет. Добавь в блок http {}:
gzip on;
gzip_vary on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_types text/css text/plain text/xml application/javascript application/json application/xml image/svg+xml;text/html в список не добавляй: nginx сжимает его всегда и на повтор ругнётся предупреждением о дублирующемся MIME-типе. Уровень 5 даёт почти тот же размер, что максимальный 9, но заметно дешевле для процессора. Brotli сжимает текст ещё процентов на 15–20 лучше, однако в стандартной сборке nginx его нет, он ставится отдельным модулем. Если сайт и так стоит за Cloudflare, тот сам отдаёт браузерам Brotli. Детали в статье про Gzip и Brotli.
HTTP/2 позволяет браузеру тянуть десятки мелких файлов по одному соединению параллельно, и на сайтах с кучей стилей и скриптов это ощутимо. Работает он только поверх HTTPS, так что сначала нужен сертификат (Let’s Encrypt через Certbot решает это бесплатно). С версии nginx 1.25.1 HTTP/2 включается отдельной директивой http2 on; в блоке server, а старая запись listen 443 ssl http2; продолжает работать, но при каждой проверке конфига выдаёт предупреждение. Гайды в интернете в основном старые, поэтому это предупреждение видят почти все. Про HTTP/3 будет отдельная статья о HTTP/2 и HTTP/3 на своём сервере.
Срок хранения статики в браузере задаётся отдельным блоком:
location ~* \.(css|js|jpg|jpeg|png|gif|webp|avif|svg|ico|woff2)$ {
expires 30d;
access_log off;
}expires сам выставляет Cache-Control: max-age, добавлять его вручную не нужно. Долгий срок безопасен, пока у файлов есть версия в адресе: WordPress дописывает ?ver= к стилям и скриптам, и после обновления темы браузер скачает новый файл. А вот если поправить CSS руками прямо на сервере без смены версии, часть посетителей ещё месяц будет видеть старые стили. Знакомая история, когда «у меня всё исправилось, а у клиента нет».
Картинки, шрифты и скрипты: то, что сервер не вылечит
Если TTFB в норме, а страница всё равно появляется секунды за четыре, дело во фронтенде. Метрика, на которую тут смотрят, называется LCP: момент, когда отрисован самый крупный элемент первого экрана, обычно главная картинка или заголовок. Хорошим значением Google считает до 2,5 секунды.
Чаще всего LCP съедает картинка на первом экране, загруженная прямо с телефона: 3–5 МБ, 4000 пикселей в ширину, хотя показывается она в 1200. Перевод в WebP или AVIF и нормальный размер дают выигрыш больше, чем любая настройка сервера из этой статьи. С ленивой загрузкой (loading="lazy") обратная ловушка: она полезна для картинок ниже экрана и вредна для первой, потому что браузер откладывает загрузку самого важного изображения. Свежие версии WordPress стараются не ставить lazy на первую картинку контента, но темы и конструкторы страниц нередко этот механизм обходят.
Со скриптами сложнее. Конструкторы страниц и тяжёлые темы тащат на каждую страницу по мегабайту-полтора JavaScript, и пока телефон его разбирает и выполняет, страница не реагирует на касания. Серверной настройкой это не исправить в принципе: можно только убрать лишнее, отложить загрузку скриптов или сменить тему. Аналогично с шрифтами: пять начертаний с Google Fonts означают пять лишних запросов к чужому серверу на первом экране.
Когда упираешься в сам сервер
Бывает, что всё настроено, а сайт временами всё равно задумывается. Тогда стоит посмотреть, что происходит с ресурсами. В top есть строка вида:
%Cpu(s): 23.1 us, 4.2 sy, 0.0 ni, 60.3 id, 9.8 wa, 0.0 hi, 0.4 si, 2.2 stИз неё интересны два последних смысловых поля. wa показывает долю времени, когда процессор ждал диск. Если это значение держится выше 10–20 процентов, узкое место в дисковой подсистеме, и разница между HDD, SSD и NVMe здесь ощущается напрямую (подробнее в статье SSD, NVMe или HDD). st, или steal, показывает время, которое гипервизор отдал другим виртуальным машинам на том же физическом сервере, хотя твоя в этот момент хотела работать. Пара процентов это норма. Стабильные 10 и выше означают, что соседи по железу съедают твой процессор: так выглядит оверселлинг, т.е. продажа провайдером большего числа ядер, чем есть на сервере. Про то, как это связано с типом тарифа, есть разбор shared и dedicated CPU.
Третий признак: активный swap. Команда vmstat 1 5 выводит столбцы si и so; если там не нули, сервер прямо сейчас перекладывает память на диск и обратно, и всё работает в разы медленнее. Сам по себе занятый swap ничего не значит, плохо именно постоянное движение. Чем грозит и как его настроить, расскажет статья про swap-файл на VPS, а следить за всеми этими показателями в динамике помогает мониторинг нагрузки.
Нехватку памяти лечит тариф побольше у того же провайдера. Высокий steal и медленный диск на соседних тарифах обычно никуда не деваются, они лечатся только сменой провайдера. Если дошло до этого, сравнить варианты по реальным тестам можно в рейтинге VPS, а перед оплатой новый сервер стоит прогнать по чек-листу из статьи как протестировать VPS перед покупкой.
Локация тоже ложится в эту категорию. Вернись к первому замеру: если connect больше 0,1 секунды, сервер далеко. Каждое новое соединение до первого байта стоит несколько обходов туда-обратно (установка соединения плюс TLS), и сервер в США для аудитории из Украины добавляет к каждому такому соединению заметную долю секунды, которую никакой кэш не уберёт. От Киева до Франкфурта пакет идёт туда и обратно обычно за 30–45 мс, до восточного побережья США порядка 110–140. Как выбирать площадку под свою аудиторию, разобрано в статье о выборе дата-центра и будет в отдельном материале о влиянии локации на скорость.
Что трогать не стоит
На форумах гуляют «оптимизированные» конфиги: worker_connections 65535, полсотни строк sysctl из статьи про высоконагруженные системы, отключённые журналы ради скорости. На сайте с несколькими тысячами посетителей в день всё это не меняет ровным счётом ничего, потому что упирается такой сайт в PHP и базу, до сетевого стека ядра дело просто не доходит. Значение по умолчанию worker_connections 768 в Debian-конфиге означает 768 одновременных соединений на процесс, и маленький сайт до этого потолка практически не добирается. По-моему, самый вредный из таких советов касается копирования чужого sysctl.conf: пользы ноль, а через полгода никто не помнит, откуда взялись странные значения, когда что-то начинает вести себя непредсказуемо. Время для этих настроек приходит, когда трафик вырастает на порядки, и тогда им посвящены статьи про тюнинг ядра через sysctl и нагрузочное тестирование.
Если сайт на WordPress и хочется пройти всю цепочку под него с конкретными плагинами, это отдельный разговор в статье об оптимизации WordPress на VPS. Порядок там тот же: сначала замер, потом кэш страниц, потом PHP и база, и только в самом конце всё остальное…
Источники
- web.dev: Time to First Byte (TTFB)
- web.dev: Largest Contentful Paint (LCP)
- Chrome UX Report: документация
- nginx: модуль ngx_http_fastcgi_module (fastcgi_cache)
- nginx: модуль ngx_http_headers_module (add_header, expires)
- nginx: модуль ngx_http_gzip_module
- nginx: модуль ngx_http_v2_module
- PHP Manual: настройки OPcache
- PHP Manual: конфигурация PHP-FPM
- MySQL Reference Manual: настройка размера InnoDB buffer pool
- WordPress Core: изменения autoload в версии 6.6
