- Опубликовано: 31 июл 2026
- 30
Сайт тормозит на хостинге: виноват тариф, код, база или внешний сервис
Часть 11 из 14 · Серия «Хостинг без магии»
Сайт открывается пять секунд.
Владелец пишет в поддержку:
Ускорьте сервер. Раньше всё работало нормально.
Поддержка предлагает более мощный тариф. После перехода страницы действительно начинают открываться быстрее — примерно две секунды вместо пяти.
Через месяц сайт снова тормозит.
Тариф увеличивают ещё раз. Улучшение держится несколько дней, после чего административная панель опять зависает, импорт товаров занимает двадцать минут, а во время оформления заказа часть покупателей видит ошибку 503.
Кажется, что проекту постоянно не хватает мощности.
Но затем разработчик отключает один модуль, который при каждом открытии страницы обращался к внешнему сервису доставки. Время ответа падает с пяти секунд до трёхсот миллисекунд.
Сервер всё это время почти не был занят. PHP-процессы ждали удалённый API.
Другой сайт показывает похожий симптом, но причина уже иная: запрос к базе перебирает несколько миллионов строк без подходящего индекса.
На третьем проекте код и база работают быстро, однако одновременно разрешено слишком мало PHP-процессов. Каждый отдельный запрос занимает двести миллисекунд, но во время рекламной кампании новые запросы встают в очередь.
Фраза «сайт тормозит» не является диагнозом.
Сначала нужно определить:
- что именно медленно;
- где проходит основное время;
- происходит ли проблема постоянно или во время пика;
- исчерпывается ли ресурс тарифа;
- какой компонент изменился перед появлением проблемы.
Только после измерений можно ответить, что требуется сайту:
- оптимизация кода;
- индекс в базе;
- кэширование;
- перенос тяжёлой задачи в очередь;
- ограничение ботов;
- исправление внешней интеграции;
- больше PHP-процессов;
- более мощный тариф;
- переход на VPS;
- или просто уменьшение изображений на странице.
«Сайт медленный» может означать разные проблемы
Пользователь воспринимает страницу целиком, но её загрузка состоит из нескольких этапов:
DNS
↓
TCP-соединение
↓
TLS
↓
ожидание ответа сервера
↓
загрузка HTML
↓
загрузка CSS, JavaScript и изображений
↓
отрисовка
↓
выполнение JavaScript
↓
готовность интерфейса к работе
Проблема может находиться на любом из них.
Медленно начинается загрузка
Пользователь несколько секунд видит пустую вкладку, а затем страница появляется быстро.
Вероятные области:
- серверная обработка;
- база данных;
- внешний API;
- очередь PHP-запросов;
- DNS;
- TLS;
- сеть между пользователем и сервером.
HTML приходит быстро, но страница долго собирается
Вероятные причины:
- тяжёлые изображения;
- слишком много JavaScript;
- блокирующие CSS-файлы;
- большое число сторонних скриптов;
- медленный браузерный код;
- шрифты;
- реклама;
- виджеты;
- слишком большое DOM-дерево.
Главная страница быстрая, административная панель медленная
Публичная часть может работать из кэша, а административная — каждый раз обращаться к базе и внешним системам.
Сайт тормозит только при оформлении заказа
Проверяем:
- платёжный сервис;
- расчёт доставки;
- CRM;
- остатки;
- отправку писем;
- создание документов;
- блокировки базы.
Сайт медленный только в определённое время
Проверяем:
- посещаемость;
- cron;
- резервное копирование;
- импорт;
- генерацию отчётов;
- поисковых ботов;
- массовую рассылку;
- соседние процессы аккаунта.
Нельзя оптимизировать «сайт вообще». Сначала нужен конкретный медленный сценарий.
Зафиксируйте симптом до изменений
Запишите:
URL:
https://example.com/catalog/laptops
Время:
25 июля 2026, 14:32
Состояние:
пользователь не авторизован
Результат:
первый ответ — 4,8 секунды
полная загрузка — 6,2 секунды
Повторный запрос:
первый ответ — 0,7 секунды
Последние изменения:
обновлён модуль фильтрации
Полезно также проверить:
- другую страницу;
- авторизованного пользователя;
- приватное окно;
- мобильную сеть;
- статический файл;
- повторный запрос;
- время без активных посетителей.
Если просто написать:
Иногда сайт работает медленно,
поиск причины придётся начинать с нуля.
Разделяем серверную и клиентскую скорость
Одним из первых ориентиров служит TTFB — Time to First Byte.
Это время от начала навигации до получения первого байта ответа. В браузерном измерении оно включает поиск DNS, установление TCP-соединения, TLS для HTTPS и ожидание начала ответа сервера.
Высокий TTFB не доказывает, что медленный именно PHP. Но он показывает, что задержка возникает до начала получения основного содержимого страницы.
Если TTFB высокий
Проверяем:
- сеть;
- серверную очередь;
- PHP;
- базу;
- внешний API;
- файловую систему;
- перенаправления;
- кэш;
- загруженность ресурсов.
Если TTFB низкий, но страница визуально медленная
Проверяем:
- изображения;
- CSS;
- JavaScript;
- шрифты;
- сторонние виджеты;
- браузерные вычисления;
- объём страницы.
Не следует увеличивать серверный тариф, если HTML приходит за 150 миллисекунд, а браузер ещё семь секунд выполняет JavaScript.
Измеряем этапы через curl
Команда:
curl \
--silent \
--show-error \
--output /dev/null \
--write-out '
DNS: %{time_namelookup}s
TCP: %{time_connect}s
TLS: %{time_appconnect}s
First byte: %{time_starttransfer}s
Total: %{time_total}s
HTTP: %{http_code}
Size: %{size_download} bytes
' \
https://example.com/catalog
curl --write-out позволяет вывести время DNS, подключения, TLS, начала передачи и полного запроса. Параметр time_starttransfer показывает время от начала операции до момента, непосредственно предшествующего получению первых данных ответа.
Пример:
DNS: 0.012s
TCP: 0.034s
TLS: 0.081s
First byte: 4.762s
Total: 4.770s
HTTP: 200
Size: 42118 bytes
DNS, TCP и TLS завершились быстро.
Основная задержка находится между установленным соединением и первым байтом:
примерно 4,68 секунды
Это уже повод проверять серверную обработку.
Другой пример:
DNS: 1.840s
TCP: 1.912s
TLS: 2.100s
First byte: 2.280s
Total: 2.310s
Само приложение ответило примерно за 180 миллисекунд после TLS. Главная задержка возникла раньше — возможно, в DNS или сети.
Проверьте несколько запросов подряд
Один результат недостаточен.
for i in {1..5}; do
curl \
--silent \
--output /dev/null \
--write-out \
"$i: %{time_starttransfer} %{time_total}\n" \
https://example.com/catalog
done
Пример:
1: 3.820 3.840
2: 0.280 0.295
3: 0.260 0.274
4: 0.270 0.284
5: 0.255 0.270
Первый запрос значительно медленнее.
Возможные причины:
- прогрев кэша;
- холодный файловый кэш;
- создание контейнера приложения;
- первый запрос к внешнему сервису;
- DNS-кэш приложения;
- генерация данных;
- истёкший кэш, который пересчитывается одним из посетителей.
Другой результат:
1: 4.2
2: 4.1
3: 4.3
4: 4.1
5: 4.2
Проблема стабильна и не объясняется только холодным кэшем.
Сравните статический и динамический файл
Создайте в публичном каталоге небольшой файл:
public/health-static.txt
С содержимым:
static-ok
Проверка:
curl \
--silent \
--output /dev/null \
--write-out \
'First byte: %{time_starttransfer}s
Total: %{time_total}s
' \
https://example.com/health-static.txt
Затем сравните с приложением:
curl \
--silent \
--output /dev/null \
--write-out \
'First byte: %{time_starttransfer}s
Total: %{time_total}s
' \
https://example.com/
Статика быстрая, приложение медленное
Сеть и веб-сервер в целом отвечают. Проверяем:
- PHP;
- базу;
- кэш;
- приложение;
- внешние сервисы;
- очередь процессов.
Медленны и статический файл, и приложение
Возможны:
- сеть;
- CDN;
- TLS;
- перегрузка веб-сервера;
- дисковая подсистема;
- инфраструктурная проблема;
- неверный маршрут;
- очень удалённое расположение сервера.
После теста файл удаляется.
Не путайте время ответа и пропускную способность
Один запрос может выполняться быстро, а сайт всё равно падать под нагрузкой.
Представим:
время одного запроса — 200 мс
PHP-процессов — 5
При небольшом числе посетителей всё работает.
Но если одновременно приходит двадцать динамических запросов:
5 выполняются
15 ждут
Пользователи в очереди видят увеличенный TTFB, хотя сам PHP-код не стал медленнее.
И наоборот, сайт может иметь двадцать свободных процессов, но каждый запрос ждать внешний API пять секунд. Под нагрузкой все двадцать быстро окажутся заняты.
Нужно измерять одновременно:
- длительность одного запроса;
- количество параллельных запросов;
- занятые PHP-процессы;
- CPU;
- память;
- базу;
- внешние зависимости.
Посмотрите графики ресурсов
Полезнее всего сопоставить время проблемы с графиком.
Например:
Сайт тормозил:
14:00–14:20
CPU:
25%
Память:
60%
PHP-процессы:
100%
I/O:
15%
Это не похоже на нехватку CPU.
Все PHP-процессы заняты, но процессор почти свободен. Вероятно, они ожидают:
- базу;
- внешний API;
- сеть;
- файловую блокировку;
- медленный диск;
- SMTP;
- другой процесс.
Другой пример:
CPU:
100%
PHP-процессы:
100%
Память:
70%
I/O:
20%
Запросы, вероятно, активно выполняют вычисления.
Проверяем:
- PHP-код;
- шаблоны;
- тяжёлые циклы;
- отсутствие кэша;
- ботов;
- cron;
- обработку изображений;
- заражение.
Как это устроено на Siteko. Ресурсы аккаунта учитываются CloudLinux LVE, и по этой статистике видно, какой именно ресурс и в какие минуты упирался в лимит — CPU, память, число процессов или диск. Если собственных измерений не хватает, напишите в поддержку и назовите время проблемы, как в примерах ниже: мы сверим его с LVE-статистикой аккаунта и скажем, ждали ли процессы внешний сервис или действительно упёрлись в тариф. Журналы доступа и ошибок ваших сайтов лежат прямо в аккаунте — их можно читать через файловый менеджер панели или по SSH, не обращаясь в поддержку.
Когда виноват CPU
Процессор может расходоваться на:
- интерпретацию PHP;
- работу фреймворка;
- сериализацию;
- шифрование;
- генерацию изображений;
- архивирование;
- Composer;
- frontend-сборку;
- SQL;
- поиск;
- вредоносный код.
Характерные признаки:
- CPU достигает лимита;
- медленны многие динамические страницы;
- скорость ухудшается пропорционально нагрузке;
- статические файлы работают быстрее;
- после завершения фоновой задачи сайт оживает;
- переход на более мощный тариф временно помогает.
Но высокая загрузка CPU не означает, что тариф обязательно мал.
Причиной может быть один ошибочный цикл:
while (true) {
// условие завершения потеряно
}
или запрос, который загружает огромный набор данных и затем фильтрует его в PHP.
Сначала найдите потребителя, затем решайте, требуется ли больше процессора.
Когда виноваты PHP-процессы
Характерная картина:
CPU не заполнен
память не заполнена
PHP workers заняты полностью
TTFB растёт во время параллельных запросов
Причиной может быть долгий запрос, который почти ничего не вычисляет:
$response = $client->get(
'https://delivery-provider.example/calculate'
);
Если внешний сервис отвечает пять секунд, PHP-процесс остаётся занят все пять секунд.
Десять одновременно открытых страниц занимают десять процессов.
Новый тариф с двадцатью workers отложит проблему, но не устранит пятисекундное ожидание.
Нужно:
- установить тайм-аут;
- кэшировать результат;
- выполнять независимые запросы параллельно;
- не обращаться к API при каждом просмотре страницы;
- переносить необязательную операцию в очередь;
- предусмотреть fallback.
Когда виновата память
Признаки:
- процессы завершаются;
- появляется
Allowed memory size exhausted; - Composer или Node.js не заканчивает работу;
- во время импорта сайт становится недоступным;
- общее потребление резко растёт при параллельности;
- worker постепенно увеличивает память.
Один обычный запрос может использовать:
60 МБ
А импорт:
600 МБ
Если импорт выполняется внутри HTTP-запроса и одновременно открываются страницы, общий лимит аккаунта заканчивается быстрее.
Проверяйте:
- выборку всех строк вместо обработки пакетами;
- загрузку большого файла целиком;
- хранение крупных коллекций;
- изображения;
- бесконечно растущий массив;
- долгоживущий worker;
- одновременный запуск нескольких задач.
Laravel и другие фреймворки позволяют обрабатывать данные порциями, а очереди — разделять большую операцию на отдельные задания. Само увеличение memory_limit не исправляет алгоритм, который загружает всю базу в память.
Когда виноват диск
Дисковая нагрузка может появляться из-за:
- базы данных;
- файлового кэша;
- сессий;
- логов;
- резервного копирования;
- распаковки архивов;
- Composer;
node_modules;- генерации миниатюр;
- антивирусного сканирования;
- большого числа мелких файлов.
Симптомы:
- I/O достигает лимита;
- Composer работает очень долго;
- административная панель тормозит во время бэкапа;
- очистка кэша занимает минуты;
- сайт замедляется при записи логов;
- база ждёт диск;
- процессор при этом загружен слабо.
Если медленность появляется ежедневно в одно время, проверьте расписание резервного копирования и cron.
Не запускайте одновременно:
резервную копию
импорт
генерацию изображений
очистку кэша
индексацию
только потому, что все задачи удобно поставить на 03:00.
Проверьте свободное место и inode
Переполненный диск может не только останавливать загрузку файлов, но и замедлять или ломать:
- кэш;
- сессии;
- логи;
- временные таблицы;
- обновления;
- базу;
- очередь;
- резервное копирование.
Проверка:
df -h
Если доступно:
df -i
Размер каталогов:
du -sh \
storage \
var \
public/uploads \
public/wp-content/uploads \
2>/dev/null
Большой лог:
storage/logs/laravel.log — 18 ГБ
может одновременно:
- занять место;
- увеличить время резервирования;
- создать лишнюю запись;
- усложнить поиск реальной ошибки.
Настройте ротацию и разумный уровень журналирования.
Проверьте OPcache
Без OPcache PHP должен загружать и разбирать скрипты заново при каждом запросе.
OPcache сохраняет предварительно скомпилированный байт-код PHP в общей памяти, уменьшая необходимость повторного чтения и разбора файлов.
Проверка CLI:
php -i | grep -iE 'opcache.enable|opcache.memory_consumption'
Но настройки CLI и веб-обработчика могут различаться.
Временная web-проверка:
<?php
var_dump([
'enabled' => ini_get('opcache.enable'),
'status' => function_exists('opcache_get_status')
? opcache_get_status(false)
: null,
]);
После проверки файл удаляется.
На управляемом хостинге OPcache обычно настраивает провайдер.
На VPS администратор должен:
- включить расширение;
- выделить достаточно памяти;
- учитывать количество PHP-файлов;
- выбрать корректную стратегию проверки изменений;
- перезапускать обработчики после релиза при необходимости.
Не копируйте агрессивные настройки без тестирования: некоторые параметры OPcache могут ломать приложения, которые используют комментарии-аннотации или ожидают определённое поведение проверки файлов.
Убедитесь, что production действительно работает как production
На рабочем сайте не должны постоянно работать:
- debug-режим;
- подробная трассировка;
- dev-контейнер;
- profiler для всех запросов;
- отключённые production-кэши;
- сбор отладочной информации;
- лишнее журналирование каждого SQL-запроса.
Для Symfony официальный production-чек-лист рекомендует OPcache, оптимизированный Composer autoloader и production-настройки контейнера. Symfony Profiler предназначен для разработки и не должен быть публично включён в production из-за серьёзных рисков безопасности.
Для Laravel проверьте:
APP_ENV=production
APP_DEBUG=false
После деплоя:
php artisan optimize
Но не пытайтесь ускорять сайт командами наугад. Сначала убедитесь, что кэш не скрывает старую конфигурацию или ошибку.
Измеряйте приложение изнутри
Внешний curl показывает общее время, но не объясняет, куда оно ушло.
Нужно разделить серверную обработку:
bootstrap приложения
контроллер
SQL
внешние API
шаблон
сериализация
отправка ответа
Laravel: журнал SQL-запросов
Можно временно зарегистрировать слушатель:
<?php
namespace App\Providers;
use Illuminate\Database\Events\QueryExecuted;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\ServiceProvider;
use Illuminate\Support\Facades\Log;
class AppServiceProvider extends ServiceProvider
{
public function boot(): void
{
DB::listen(function (QueryExecuted $query): void {
if ($query->time < 200) {
return;
}
Log::warning('Slow SQL query', [
'time_ms' => $query->time,
'sql' => $query->toRawSql(),
]);
});
}
}
Не записывайте все запросы без ограничений на нагруженном production-сайте: журнал сам может создать нагрузку и сохранить чувствительные параметры.
Laravel также поддерживает DB::whenQueryingForLongerThan(), который позволяет реагировать, если суммарное время запросов к базе в рамках одного web-запроса превысило заданный порог.
Пример:
use Illuminate\Database\Connection;
use Illuminate\Database\Events\QueryExecuted;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Log;
DB::whenQueryingForLongerThan(
500,
function (
Connection $connection,
QueryExecuted $event
): void {
Log::warning('High cumulative DB time', [
'connection' => $connection->getName(),
'last_query_ms' => $event->time,
]);
}
);
Symfony
В development-окружении Symfony Profiler показывает время запросов к базе, рендеринга шаблонов и других частей обработки. Для собственных участков кода можно использовать компонент Stopwatch.
Пример:
use Symfony\Component\Stopwatch\Stopwatch;
$stopwatch->start('delivery-api');
$result = $deliveryClient->calculate($order);
$event = $stopwatch->stop('delivery-api');
$logger->info('Delivery API timing', [
'duration_ms' => $event->getDuration(),
'memory_bytes' => $event->getMemory(),
]);
На production лучше применять безопасное выборочное измерение, трассировку или APM, а не открывать web-profiler посетителям.
Частая проблема базы: слишком много запросов
Страница каталога показывает 100 товаров.
Приложение сначала выполняет:
SELECT * FROM products LIMIT 100;
Затем для каждого товара отдельно:
SELECT * FROM brands WHERE id = ?;
Получается:
1 запрос товаров
100 запросов брендов
= 101 запрос
Это классическая схема N+1.
На локальной базе каждый запрос может занимать одну миллисекунду, и проблема кажется незаметной.
На сервере:
101 × 3 мс = 303 мс
Добавьте сетевые задержки, блокировки, шаблоны и остальные таблицы — страница легко превращается в секундную.
Используйте:
- eager loading;
- JOIN;
- пакетное получение;
- кэширование;
- правильную структуру данных.
Для Laravel, например:
$products = Product::query()
->with(['brand', 'category'])
->paginate(50);
Проверяйте не только самый долгий SQL, но и суммарное число запросов.
Частая проблема базы: отсутствующий индекс
Запрос:
SELECT *
FROM orders
WHERE customer_id = 8123
ORDER BY created_at DESC
LIMIT 20;
может работать быстро на тысяче заказов и медленно — на десяти миллионах.
План:
EXPLAIN
SELECT *
FROM orders
WHERE customer_id = 8123
ORDER BY created_at DESC
LIMIT 20;
MySQL EXPLAIN показывает, как оптимизатор планирует выполнять запрос: порядок таблиц, способы доступа и использование индексов. EXPLAIN ANALYZE дополнительно выполняет запрос и показывает фактические времена и количество обработанных строк.
Возможный составной индекс:
CREATE INDEX idx_orders_customer_created
ON orders (customer_id, created_at);
Но индекс нельзя добавлять по одному только виду запроса.
Он:
- занимает диск;
- замедляет запись;
- требует обслуживания;
- может дублировать существующий;
- должен соответствовать реальным условиям выборки и сортировки.
Сначала изучите план и фактическую нагрузку.
Осторожно с EXPLAIN ANALYZE
Обычный EXPLAIN показывает план без выполнения SELECT.
EXPLAIN ANALYZE реально запускает запрос, чтобы собрать фактическую статистику.
Не запускайте его бездумно для:
- потенциально очень тяжёлого запроса;
- production-базы в час пик;
- запроса с блокировками;
- операций изменения данных;
- выборки, которая может работать минуты.
Начните с обычного EXPLAIN, копии базы или тестовой среды.
Другие причины медленной базы
Получение лишних столбцов
SELECT *
может загружать большие текстовые поля, JSON или BLOB, которые странице не нужны.
Выбирайте необходимое:
SELECT id, name, price
FROM products;
Слишком большая страница
1000 товаров за один запрос
создаёт нагрузку на:
- базу;
- PHP;
- память;
- шаблон;
- сеть;
- браузер.
Используйте пагинацию.
Дорогой COUNT(*)
Подсчёт общего количества строк для сложного фильтра иногда занимает больше времени, чем получение текущей страницы.
Проверьте, действительно ли интерфейсу необходим точный результат:
Найдено 18 472 913 товаров
Возможно, достаточно:
Показано более 10 000 результатов
Блокировки
Один долгий импорт может удерживать транзакцию и заставлять обычные запросы ждать.
Симптом:
CPU базы невысокий,
но запросы выполняются долго
Проверяйте активные транзакции, блокировки и длительность операций записи.
Индекс существует, но не используется
Причины:
- функция над индексированным полем;
- несовместимые типы;
- условие с неудачной избирательностью;
- сортировка;
- устаревшая статистика;
- другой порядок столбцов составного индекса.
Всегда проверяйте план.
Внешний сервис может быть медленнее всего сайта
Современная страница может обращаться к:
- платёжной системе;
- CRM;
- доставке;
- курсам валют;
- картам;
- складу;
- системе рекомендаций;
- сервису проверки адреса;
- API партнёра;
- SMTP;
- облачному хранилищу.
Плохая схема:
$stock = $stockApi->get($productId);
$delivery = $deliveryApi->calculate($address);
$recommendations = $recommendationApi->for($user);
$currency = $currencyApi->current();
Если вызовы выполняются последовательно:
склад 500 мс
доставка 1200 мс
рекомендации 800 мс
валюта 300 мс
----------------------
итого 2800 мс
Даже мгновенный PHP и быстрый SQL не сделают страницу быстрее 2,8 секунды.
У каждого внешнего запроса должен быть тайм-аут
Без явного тайм-аута приложение может ждать слишком долго.
Условный пример:
$response = $client->request(
'GET',
$url,
[
'connect_timeout' => 2,
'timeout' => 5,
]
);
Нужно различать:
- время установления соединения;
- общее время запроса.
Значения зависят от операции.
Для необязательного блока рекомендаций пять секунд могут быть недопустимы. Для подтверждения платёжной операции правила могут быть другими.
После тайм-аута приложение должно знать, что делать:
- показать данные из кэша;
- пропустить необязательный блок;
- поставить повтор в очередь;
- показать понятную ошибку;
- сохранить операцию для сверки;
- не создавать дубли.
Не вызывайте внешний API на каждой странице без необходимости
Данные, которые меняются раз в час, не нужно получать при каждом запросе посетителя.
Пример:
$rates = Cache::remember(
'currency-rates',
now()->addMinutes(30),
fn () => $currencyApi->getRates()
);
Laravel предоставляет единый cache API для разных хранилищ и позволяет получать значение из кэша либо вычислять и сохранять его при отсутствии.
Но кэшировать нужно осознанно:
- определить допустимую устарелость;
- решить, что делать при сбое источника;
- не хранить персональные данные под общим ключом;
- предусмотреть очистку;
- избежать одновременного пересчёта сотнями процессов.
Эффект «стада» после истечения кэша
Представим популярную страницу.
В кэше хранится результат тяжёлого запроса. Срок истекает в 12:00:00.
В 12:00:01 приходит сто посетителей.
Если каждый видит пустой кэш и начинает пересчёт:
100 одинаковых SQL-запросов
100 обращений к API
100 генераций страницы
ресурсы резко заканчиваются.
Это называется cache stampede.
Решения:
- блокировка пересчёта;
- stale-while-revalidate;
- небольшой случайный разброс TTL;
- предварительный прогрев;
- фоновой пересчёт;
- сохранение старого значения при сбое.
Современный Laravel поддерживает подход, при котором устаревшее значение временно выдаётся пользователю, а обновление запускается отдельно, уменьшая задержку после истечения кэша.
Страничный кэш и объектный кэш решают разные задачи
Page cache
Сохраняет готовый HTML:
URL
↓
готовая страница
PHP и база могут вообще не запускаться для повторного анонимного запроса.
Хорошо подходит для:
- статей;
- каталогов;
- публичных страниц;
- лендингов.
Сложнее применяется для:
- корзины;
- личного кабинета;
- персонализации;
- авторизованных пользователей.
Object cache
Сохраняет данные:
настройки
результаты SQL
объекты
вычисления
Приложение продолжает работать, но реже обращается к базе или выполняет тяжёлую операцию.
WordPress указывает, что page cache может отдавать сохранённые страницы вместо полной генерации, а persistent object cache уменьшает количество повторных обращений веб-сервера к базе.
Не устанавливайте пять плагинов кэширования одновременно. Они могут:
- дублировать функции;
- конфликтовать;
- неверно очищать страницы;
- создавать лишние файлы;
- ломать персонализацию.
Redis — не универсальная кнопка ускорения
Redis полезен для:
- объектного кэша;
- сессий;
- очередей;
- блокировок;
- счётчиков;
- быстрых временных данных.
Но добавление Redis не ускорит автоматически:
- внешний API;
- неоптимальный запрос, который не кэшируется;
- тяжёлый JavaScript;
- огромные изображения;
- ошибочный цикл;
- медленный импорт;
- блокировку таблицы.
Кроме того, Redis требует:
- доступного сервера;
- настройки памяти;
- политики удаления данных;
- мониторинга;
- понимания персистентности;
- защиты доступа.
На обычном виртуальном хостинге может быть доступно PHP-расширение Redis, но отсутствовать отдельный Redis-сервер. Это разные компоненты.
Сессии могут стать узким местом
Файловые сессии часто используют блокировку.
Пользователь открывает страницу, которая держит сессию во время долгого внешнего запроса. Одновременно браузер отправляет AJAX-запросы с той же сессией.
Они могут ждать освобождения блокировки.
Симптом:
- сайт быстр для разных пользователей;
- несколько запросов одного авторизованного пользователя выполняются последовательно;
- административная панель кажется зависшей;
- CPU почти свободен.
Решения зависят от приложения:
- закрывать сессию после чтения;
- не держать блокировку во время API;
- изменить session handler;
- уменьшить объём сессии;
- избегать записи сессии на каждом запросе.
Не меняйте хранилище сессий, не проверив совместимость и влияние на авторизацию.
Cron и очередь могут конкурировать с посетителями
Фоновая задача использует те же ресурсы аккаунта:
CPU
RAM
процессы
диск
соединения с базой
Типичный сценарий:
каждую минуту запускается импорт
один импорт работает четыре минуты
блокировка отсутствует
Через несколько минут параллельно работают четыре копии.
Проверка процессов:
ps aux
Для защиты:
flock \
-n \
/tmp/example-import.lock \
php artisan app:import
Laravel scheduler также поддерживает механизмы предотвращения наложения задач, но конкретный вариант зависит от приложения и используемого cache driver.
Не отправляйте письма внутри критического запроса
Оформление заказа:
запись заказа
↓
письмо покупателю
↓
письмо менеджеру
↓
CRM
↓
служба доставки
↓
ответ пользователю
Если SMTP отвечает две секунды, CRM — три, а доставка — четыре, покупатель ждёт девять секунд.
Лучше критическую часть завершить быстро:
проверить данные
создать заказ
зафиксировать оплату
вернуть результат
А необязательные действия отправить в очередь:
письма
CRM
аналитика
генерация документов
уведомления
При этом очередь должна реально обрабатываться. Перенос задержки в неработающий worker не является оптимизацией.
Резервное копирование тоже создаёт нагрузку
Бэкап может:
- читать все файлы;
- архивировать их;
- создавать дамп базы;
- записывать большой архив;
- отправлять его во внешнее хранилище;
- удалять старые копии.
Если аккаунт содержит:
300 000 мелких файлов
резервирование может заметно использовать диск даже при небольшом общем объёме.
Проверьте:
- расписание;
- длительность;
- пересечение с cron;
- локальное и внешнее хранилище;
- влияние дампа на базу;
- число старых копий.
Не отключайте резервное копирование ради скорости. Перенесите его на подходящее время и оптимизируйте состав.
Боты могут создавать больше нагрузки, чем люди
В журнале доступа могут появляться тысячи запросов к:
- поиску;
- фильтрам;
- календарю;
- параметрам сортировки;
- несуществующим URL;
- входу в CMS;
- API;
- XML-RPC;
- страницам с дорогой генерацией.
Человек открывает пять страниц. Бот перебирает десятки тысяч комбинаций:
/catalog?color=red&size=1
/catalog?color=red&size=2
/catalog?color=red&size=3
...
Каждый URL может обходить page cache и запускать тяжёлый SQL.
Проверьте access log:
awk '{print $7}' access.log |
sort |
uniq -c |
sort -nr |
head -n 30
Частые IP:
awk '{print $1}' access.log |
sort |
uniq -c |
sort -nr |
head -n 30
Методы защиты:
- CDN;
- rate limiting;
- кэш;
- robots.txt для добросовестных роботов;
- блокировка вредоносных клиентов;
- ограничение дорогих фильтров;
- CAPTCHA;
- защита входа;
- закрытие технических URL.
Не блокируйте всех роботов вслепую: можно потерять поисковую индексацию и полезные интеграции.
Медленный frontend не лечится сервером
Представим:
TTFB 180 мс
HTML 80 КБ
JavaScript 4 МБ
Изображения 12 МБ
Сторонние скрипты 35 запросов
Сервер начинает ответ быстро, но мобильное устройство загружает и обрабатывает страницу долго.
Проверяйте:
- размер ресурсов;
- форматы изображений;
srcset;- lazy loading;
- минификацию;
- удаление неиспользуемого кода;
- разделение JavaScript;
- сторонние виджеты;
- кэш браузера;
- CDN;
- порядок загрузки.
Web performance включает не только сетевое получение, но и отрисовку, обработку и готовность интерфейса к взаимодействию.
Перед увеличением PHP-тарифа посмотрите Network и Performance в инструментах разработчика.
Проверьте редиректы
Цепочка:
http://example.com
↓
https://example.com
↓
https://www.example.com
↓
https://www.example.com/ru
↓
https://www.example.com/ru/
добавляет несколько последовательных запросов до начала загрузки страницы.
Проверить:
curl \
-IL \
--max-redirs 10 \
http://example.com/
Лучше сразу отправлять на окончательный адрес:
http://example.com
↓
https://www.example.com/ru/
Но не изменяйте каноническую структуру только ради одного редиректа без учёта SEO и существующих ссылок.
Сравните авторизованного и анонимного пользователя
Многие системы не кэшируют страницы для авторизованных пользователей.
Проверка:
Приватное окно:
300 мс
Административная сессия:
2,8 секунды
Причины:
- page cache обходится;
- загружается toolbar;
- выполняются дополнительные права;
- строятся персональные данные;
- плагины работают только для администраторов;
- сессия блокируется;
- административные запросы тяжелее.
Не оценивайте скорость публичного сайта только из аккаунта администратора.
Но и не игнорируйте медленную панель: она может указывать на реальную проблему базы.
Сравните production и копию проекта
Если локально сайт работает быстро, а на хостинге медленно, это ещё не доказывает нехватку тарифа.
Могут различаться:
- объём базы;
- число пользователей;
- реальные интеграции;
- latency внешних API;
- PHP-версия;
- OPcache;
- debug;
- кэш;
- диск;
- расширения;
- данные;
- география.
И наоборот, production может работать быстрее локального окружения благодаря OPcache, page cache и настроенному серверу.
Для сравнения нужны максимально похожие:
код
конфигурация
объём данных
сценарий запроса
Как понять, помогает ли старший тариф
Переход имеет смысл, если измерения показывают:
- CPU регулярно достигает лимита при нормальном коде;
- памяти не хватает при разумной параллельности;
- все PHP-процессы заняты быстрыми полезными запросами;
- I/O является реальным узким местом;
- текущие лимиты не позволяют обработать измеренный пик;
- после оптимизации остаётся недостаточный запас;
- проект стабильно растёт.
Переход, скорее всего, только скроет проблему, если:
- один SQL работает пять секунд без индекса;
- внешний API отвечает десять секунд;
- cron запускается параллельно;
- приложение находится в debug;
- каждую страницу генерируют сотни запросов;
- бот перебирает бесконечные фильтры;
- изображения весят десятки мегабайт;
- PHP-процесс ждёт SMTP;
- кэш настроен неверно.
Больше ресурсов полезно после того, как вы понимаете, какой ресурс увеличиваете и почему.
Вертикальное масштабирование не бесконечно
Последовательность:
оптимизировать запрос
↓
настроить кэш
↓
ограничить ботов
↓
разделить фоновые задачи
↓
увеличить тариф
обычно эффективнее:
увеличить тариф
↓
увеличить тариф
↓
увеличить тариф
Но оптимизация тоже имеет цену.
Иногда дешевле перейти на старший тариф, чем потратить несколько рабочих дней на ускорение редко используемого внутреннего инструмента.
Решение должно учитывать:
- стоимость ресурсов;
- стоимость разработки;
- критичность;
- будущий рост;
- риски;
- сложность поддержки.
Пошаговая диагностика медленного сайта
Шаг 1. Зафиксируйте URL и сценарий
Публичная страница?
Административная?
Авторизованный пользователь?
POST-запрос?
API?
Cron?
Шаг 2. Измерьте DNS, TCP, TLS, первый байт и полное время
curl \
--silent \
--output /dev/null \
--write-out '
DNS: %{time_namelookup}
Connect: %{time_connect}
TLS: %{time_appconnect}
First byte: %{time_starttransfer}
Total: %{time_total}
' \
https://example.com/
Шаг 3. Повторите тест
Сравните холодный и прогретый запрос.
Шаг 4. Сравните статический файл и приложение
Если статика быстрая, ищите внутри PHP-приложения.
Шаг 5. Откройте графики ресурсов
Сопоставьте конкретное время с:
CPU
RAM
PHP workers
I/O
процессы
соединения базы
Шаг 6. Проверьте фоновые задачи
cron
queue
backup
import
export
indexing
Шаг 7. Измерьте SQL
Проверьте:
- количество запросов;
- суммарное время;
- самые медленные запросы;
- N+1;
- планы
EXPLAIN; - блокировки.
Шаг 8. Измерьте внешние API
Для каждого вызова:
имя сервиса
время соединения
общее время
результат
тайм-аут
Шаг 9. Проверьте production-настройки
debug выключен
кэш включён
OPcache работает
autoload оптимизирован
логи не чрезмерны
Шаг 10. Проверьте frontend
Если сервер отвечает быстро, изучайте:
изображения
JS
CSS
шрифты
сторонние скрипты
Шаг 11. Внесите одно изменение
После него повторите тот же тест.
Шаг 12. Только затем меняйте тариф
Сформулируйте:
Какой ресурс заканчивается?
На сколько его нужно увеличить?
Какой запас получит проект?
Быстрый скрипт проверки
#!/usr/bin/env bash
set -u
URL="${1:-https://example.com/}"
echo "URL: $URL"
echo
for run in 1 2 3 4 5; do
curl \
--silent \
--show-error \
--output /dev/null \
--write-out \
"Run $run | HTTP %{http_code} | DNS %{time_namelookup}s | TCP %{time_connect}s | TLS %{time_appconnect}s | TTFB %{time_starttransfer}s | Total %{time_total}s | Size %{size_download}\n" \
"$URL" || {
echo "Request failed"
exit 1
}
done
Запуск:
chmod +x check-response.sh
./check-response.sh \
https://example.com/catalog
Сохраняйте результаты до и после изменения. Ощущение «стало вроде быстрее» хуже конкретных чисел.
Таблица: симптом, вероятная причина и проверка
| Симптом | Вероятная причина | Что проверить |
|---|---|---|
| Высокий TTFB, CPU 100% | Тяжёлый PHP или SQL | Профилирование и запросы |
| Высокий TTFB, CPU низкий, workers 100% | Ожидание API, базы или блокировки | Внешние вызовы и locks |
| Первый запрос медленный, остальные быстрые | Холодный кэш | Прогрев и stampede |
| Статика быстрая, PHP медленный | Приложение или база | Логи и profiler |
| Медленны и статика, и PHP | Сеть, диск или инфраструктура | I/O и маршрут |
| Медленно только при нагрузке | Недостаточная параллельность | Workers и очереди |
| Медленно только ночью | Бэкап или cron | Расписание процессов |
| Медленно только администратору | Обход кэша или сессии | Авторизованный сценарий |
| Медленно оформление заказа | Платёж, доставка, CRM, почта | Тайминги интеграций |
| Медленно после обновления | Новый код, плагин или миграция | Сравнить релизы |
| I/O 100%, CPU низкий | Диск, бэкап или мелкие файлы | Процессы и файловую активность |
| RAM 100% | Тяжёлый импорт или много процессов | Память каждого процесса |
| Ошибка 503 во время пика | Все workers заняты | Длительность запросов |
| Сайт быстрый, страница рисуется долго | Frontend | Network и Performance |
| Запросов к базе сотни | N+1 | ORM profiler |
| Один SQL занимает секунды | Нет индекса или блокировка | EXPLAIN и транзакции |
| Задержка ровно 5–10 секунд | Тайм-аут внешнего сервиса | HTTP-клиент |
| После очистки кэша всё медленно | Массовый пересчёт | Прогрев и блокировки |
| Тариф помог только ненадолго | Рост данных или скрытая проблема | Повторное измерение |
Грабли при ускорении сайта
| Грабля | Что происходит | Как избежать |
|---|---|---|
| Сразу повышают тариф | Причина остаётся | Сначала измерить |
| Смотрят только на CPU | Пропускают ожидание API | Сопоставлять все ресурсы |
| Оценивают только главную | Медленный сценарий остаётся | Проверять конкретные URL |
| Проверяют один запрос | Случайный результат принимают за норму | Делать серию измерений |
| Включают profiler в production публично | Утечка данных и новая нагрузка | Использовать безопасное профилирование |
| Логируют каждый SQL | Журнал сам замедляет сайт | Порог и выборка |
Добавляют индекс без EXPLAIN |
Запись замедляется, пользы нет | Изучить план |
Используют EXPLAIN ANALYZE вслепую |
Тяжёлый запрос реально выполняется | Начать с EXPLAIN |
| Ставят несколько cache-плагинов | Конфликты и устаревшие страницы | Одна понятная стратегия |
| Увеличивают workers без RAM | Процессы завершаются | Считать общую память |
| Увеличивают тайм-ауты | Медленные процессы дольше заняты | Исправлять операцию |
| Каждый запрос ждёт SMTP | Заказ оформляется секунды | Перенести письма в очередь |
| Cron запускается повторно | Копии конкурируют | Добавить блокировку |
| Redis считают универсальным решением | Реальное узкое место не меняется | Кэшировать конкретные данные |
| Оптимизируют сервер при тяжёлом frontend | Пользователь не замечает улучшения | Разделить backend и browser |
| Отключают бэкапы ради скорости | Ускорение ценой потери данных | Перенести и оптимизировать |
| Тестируют только как администратор | Результат не отражает посетителей | Проверить обе сессии |
| Меняют всё одновременно | Нельзя определить эффект | Одно изменение за тест |
Что приложить к обращению в поддержку
Плохое сообщение:
Сайт тормозит.
Ускорьте хостинг.
Полезное:
Домен:
example.com
Проблемный URL:
https://example.com/catalog
Время проблемы:
25 июля 2026, 14:00–14:20
Результаты curl:
DNS — 0,01 с
TCP — 0,03 с
TLS — 0,08 с
TTFB — 4,8 с
Total — 4,9 с
Статический файл:
TTFB — 0,09 с
Повторные запросы:
4,8 / 4,7 / 4,9 / 4,8 / 4,7 с
Графики в это время:
CPU — 22%
RAM — 61%
PHP-процессы — 100%
I/O — 18%
Cron и бэкапы в это время не запускались.
В журнале приложения внешний запрос к
delivery-provider занимает около 4 секунд.
Нужно проверить, ограничивается ли соединение
с внешним сервисом со стороны хостинга,
либо проблема полностью находится в приложении.
Для проблемы ресурсов:
В течение рекламной кампании:
CPU — 100%
PHP workers — 100%
RAM — 72%
Среднее время PHP-запроса после профилирования:
180–250 мс
Медленных внешних API нет.
SQL занимает около 40 мс на запрос.
Нагрузка стабильно превышает лимит тарифа.
Нужно уточнить ресурсы следующего тарифа:
CPU и число PHP-процессов.
Не прикладывайте:
- пароли;
- полный
.env; - персональные данные;
- токены API;
- необработанный дамп базы.
Минимальный чек-лист медленного сайта
Измерение
Какой URL медленный?
Какой TTFB?
Какое полное время?
Повторяется ли результат?
Сеть
Как долго DNS?
Как долго TCP и TLS?
Одинаков ли результат из разных сетей?
Хостинг
CPU достигает лимита?
RAM достигает лимита?
Все PHP workers заняты?
Есть ли I/O throttling?
PHP
Включён ли OPcache?
Выключен ли debug?
Есть ли тяжёлые циклы?
Какое потребление памяти?
База
Сколько SQL-запросов?
Какое суммарное время?
Есть ли N+1?
Что показывает EXPLAIN?
Есть ли блокировки?
Внешние сервисы
Какие API вызываются?
Каково время каждого?
Есть ли тайм-аут?
Есть ли fallback и кэш?
Кэш
Что кэшируется?
Какой TTL?
Что происходит после истечения?
Нет ли stampede?
Фоновые задачи
Когда запускаются cron и бэкапы?
Не пересекаются ли они?
Есть ли блокировка повторного запуска?
Frontend
Каков объём страницы?
Сколько JavaScript и изображений?
Какие сторонние сервисы загружаются?
Что в итоге
Когда сайт работает медленно, виноват не обязательно тариф.
Задержка может находиться в:
DNS
сети
TLS
очереди PHP
PHP-коде
базе данных
файловой системе
кэше
внешнем API
SMTP
cron
резервном копировании
ботах
JavaScript
изображениях
Правильная диагностика идёт по слоям:
1. Зафиксировать конкретный сценарий
↓
2. Измерить этапы запроса
↓
3. Отделить frontend от backend
↓
4. Сопоставить время с ресурсами
↓
5. Измерить PHP, SQL и внешние API
↓
6. Исправить одно узкое место
↓
7. Повторить тот же тест
↓
8. Решить, нужен ли более мощный тариф
Если CPU постоянно исчерпан полезной нагрузкой, старший тариф действительно поможет.
Если все PHP-процессы пять секунд ждут внешний API, увеличение их числа только позволит большему количеству процессов ждать одновременно.
Если база перебирает миллионы строк без индекса, дополнительная память даст временный запас, но не исправит запрос.
Если сервер отвечает быстро, а браузер загружает 15 МБ изображений и JavaScript, проблема находится не в PHP-хостинге.
Главный принцип:
Сначала найдите ресурс или операцию, на которой проходит время. Только потом покупайте больше мощности.
Но даже быстрый сайт остаётся уязвимым, если его невозможно восстановить.
В панели может быть написано, что резервные копии создаются ежедневно. Однако во время аварии выясняется, что база в архив не входила, копия повреждена, пароль шифрования потерян, а восстановление никогда не проверяли.
В следующей части разберём, почему наличие бэкапа ещё не означает возможность вернуть сайт к работе.
Была статья полезной:
