Веб-разработка

Ускорение сайта на уровне сервера: кэш, PHP, HTTP/2 и сжатие

Разбираем серверные способы ускорить сайт без переделки дизайна: кэш, OPcache, актуальный PHP, HTTP/2 и сжатие. С командами и чек-листом.

Ускорение сайта на уровне сервера: кэш, PHP, HTTP/2 и сжатие

Ускорить сайт на уровне сервера можно без переделки дизайна и кода: достаточно включить кэширование страниц и объектов, перейти на актуальную версию PHP с OPcache, включить HTTP/2 или HTTP/3, сжатие Gzip или Brotli и правильно настроить отдачу статики. Эти меры снижают время ответа сервера (TTFB) и объём передаваемых данных, а значит, страницы открываются быстрее и у посетителей, и у поисковых роботов.

Ниже разбираем, что именно настраивается на сервере, в каком порядке это делать и как проверить результат. Инструкции рассчитаны на владельца сайта или маркетолога, который готов выполнить несколько команд или попросить об этом поддержку хостинга.

Серверное оборудование в дата-центре: скорость сайта начинается здесь

Почему скорость зависит от сервера, а не только от вёрстки

Когда посетитель открывает страницу, браузер сначала ждёт ответ сервера. Пока PHP выполняет код, обращается к базе данных и собирает HTML, пользователь видит белый экран. Это время называется TTFB (Time To First Byte). Оптимизация картинок и скриптов на фронтенде помогает дальше, но если сервер отвечает 1,5–2 секунды, никакое сжатие изображений этого не компенсирует.

На скорость со стороны сервера влияют:

  • мощность и загруженность железа: процессор, оперативная память, тип дисков;
  • версия PHP и наличие OPcache;
  • кэширование готовых страниц и результатов запросов к базе;
  • настройки веб-сервера (nginx, Apache) и протокол передачи данных;
  • сжатие ответов и правила кэширования статики в браузере;
  • настройки базы данных MySQL или MariaDB.

Хорошая новость: большая часть этих пунктов настраивается за один-два вечера и не требует участия программиста.

Шаг первый: измерить текущую скорость

Прежде чем что-то менять, зафиксируйте исходные цифры. Иначе вы не поймёте, какая мера сработала. Полезно замерить:

  1. TTFB главной страницы и пары типовых страниц (карточка товара, статья блога);
  2. показатели PageSpeed Insights или Lighthouse для мобильной версии;
  3. нагрузку на сервер в пиковые часы: загрузку процессора и памяти.

Время ответа сервера быстро проверяется из командной строки:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}snВсего: %{time_total}sn" https://example.ru/

Запустите команду несколько раз: первый запрос может быть медленнее из-за холодного кэша. Ориентир для динамического сайта на CMS — TTFB до 0,5–0,6 секунды, для страниц из кэша — заметно меньше. Если вы видите 1–3 секунды, резерв для ускорения на сервере точно есть. Подробнее о диагностике мы писали в статье почему сайт тормозит и виноват ли хостинг.

Кэширование: самый большой выигрыш

Кэш — это сохранённый готовый результат работы, который не нужно вычислять заново. Для сайтов на WordPress, 1С-Битрикс и других CMS кэширование обычно даёт самый заметный эффект.

Кэш страниц

Сервер один раз собирает HTML-страницу и затем отдаёт её всем посетителям из готовой копии, не запуская PHP и не обращаясь к базе. Варианты реализации:

  • плагин или встроенный модуль CMS (для WordPress — плагины кэширования, в Битриксе — «Композитный сайт» и управляемый кэш);
  • FastCGI-кэш nginx — страницы кэширует сам веб-сервер, это быстрее любого плагина;
  • Varnish или аналогичный обратный прокси перед сайтом — для крупных проектов.

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

Объектный кэш

Даже когда страница не может быть закэширована целиком, повторяющиеся запросы к базе можно хранить в оперативной памяти через Redis или Memcached. Это особенно полезно интернет-магазинам и сайтам с личными кабинетами. На VPS Redis ставится одной командой:

sudo apt update && sudo apt install redis-server
sudo systemctl enable --now redis-server

Затем в CMS подключается соответствующий модуль или плагин. На виртуальном хостинге Redis доступен не на всех тарифах — уточняйте у провайдера.

OPcache

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

opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=10000
opcache.validate_timestamps=1
opcache.revalidate_freq=60

Совет: после изменения php.ini перезапустите PHP-FPM (например, sudo systemctl restart php8.3-fpm, имя службы зависит от версии). Без перезапуска новые параметры не применятся.

Настройка кэширования и PHP через терминал сервера

Актуальная версия PHP

Каждая новая ветка PHP обычно работает быстрее предыдущей и получает исправления безопасности. Сайт, который до сих пор работает на PHP 7.x, теряет и в скорости, и в защищённости: ветки 7.x давно не поддерживаются разработчиками языка. Переход на PHP 8.x часто заметно сокращает время генерации страниц, но конкретный прирост зависит от кода сайта.

Перед обновлением обязательно проверьте совместимость темы, плагинов и модулей на тестовой копии. Пошаговый порядок описан в отдельной статье: как безопасно обновить версию PHP.

Протокол, сжатие и кэш статики

HTTP/2 и HTTP/3

Протокол HTTP/1.1 загружает файлы по ограниченному числу соединений, из-за чего браузер выстраивает очередь из стилей, скриптов и картинок. HTTP/2 передаёт много файлов параллельно в одном соединении и сжимает заголовки. HTTP/3 работает поверх QUIC и лучше ведёт себя на нестабильном мобильном интернете.

Для HTTP/2 нужен HTTPS. В nginx он включается в блоке server (в версиях nginx 1.25.1 и новее используется отдельная директива http2 on;, в более старых — параметр в строке listen):

server {
    listen 443 ssl;
    http2 on;
    server_name example.ru;
    ...
}

Проверить, по какому протоколу отдаётся сайт, можно во вкладке «Сеть» инструментов разработчика браузера (колонка Protocol) или командой curl -I --http2 https://example.ru/.

Сжатие Gzip и Brotli

HTML, CSS, JavaScript и SVG хорошо сжимаются: размер текстовых файлов уменьшается в несколько раз. Gzip поддерживается везде, Brotli обычно сжимает ещё лучше, но требует отдельного модуля nginx. Минимальная настройка Gzip в nginx:

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

Картинки JPEG, PNG и WebP повторно сжимать на лету бессмысленно: они уже сжаты, а процессор потратит время впустую.

Кэширование статики в браузере

Если сервер сообщает браузеру, что логотип, шрифты и стили можно хранить долго, при повторном визите они не скачиваются заново. Для этого задают заголовки Cache-Control и Expires:

location ~* .(css|js|woff2|jpg|jpeg|png|webp|svg|ico)$ {
    expires 30d;
    add_header Cache-Control "public";
    access_log off;
}

Если после обновления дизайна посетители видят старые стили, добавляйте к файлам версию в адресе (например, style.css?v=2) — большинство CMS делает это автоматически.

Проверка скорости загрузки сайта после настройки сервера

Сравнение мер: что даёт каждая настройка

Мера На что влияет Сложность Где доступна
Кэш страниц TTFB, нагрузка на сервер Низкая (плагин) — средняя (nginx) Хостинг и VPS
Объектный кэш Redis Запросы к базе, личные кабинеты Средняя VPS, часть тарифов хостинга
OPcache Время выполнения PHP Низкая Почти везде
Новая версия PHP Скорость и безопасность Средняя (нужен тест) Хостинг и VPS
HTTP/2, HTTP/3 Загрузка множества файлов Низкая Зависит от веб-сервера
Gzip/Brotli Объём передаваемых данных Низкая Хостинг и VPS
Кэш статики в браузере Повторные визиты Низкая Хостинг и VPS

База данных и ресурсы сервера

Даже идеально настроенный кэш не спасёт, если сервер упирается в ресурсы. Признаки: высокая загрузка процессора в спокойное время, использование swap, медленные запросы в журнале MySQL. Что проверить:

  • размер буфера InnoDB и журнал медленных запросов — подробно в статье об оптимизации MySQL на сервере;
  • тип дисков: NVMe заметно быстрее SATA SSD при большом числе мелких операций;
  • число процессов PHP-FPM: слишком мало — запросы стоят в очереди, слишком много — заканчивается память;
  • фоновые задачи и cron, которые запускаются в часы пик.

Если сайт уже вырос из виртуального хостинга, следующий логичный шаг — VPS, где вы управляете всеми настройками. Облачные серверы, например у Timeweb Cloud или AdminVPS, позволяют увеличить процессор и память без переезда. Для небольших сайтов часто достаточно хорошего виртуального хостинга с актуальным PHP, например Timeweb; подробнее о его тарифах — в нашем обзор Timeweb и Timeweb Cloud.

Важно: перед изменением конфигурации nginx всегда проверяйте синтаксис командой sudo nginx -t и только потом перезагружайте службу через sudo systemctl reload nginx. Ошибка в конфигурации может уронить все сайты на сервере.

Порядок действий: чек-лист

  1. Замерьте TTFB и PageSpeed до изменений, сохраните цифры.
  2. Сделайте резервную копию файлов, базы и конфигурации сервера.
  3. Включите и настройте OPcache.
  4. Обновите PHP до поддерживаемой версии, предварительно проверив сайт на копии.
  5. Настройте кэш страниц с исключениями для корзины и личного кабинета.
  6. Подключите Redis или Memcached для объектного кэша, если сайт динамический.
  7. Включите HTTP/2, сжатие и заголовки кэширования статики.
  8. Проверьте настройки базы данных и ресурсы сервера.
  9. Повторите замеры и сравните с исходными.
Чек-лист настройки сервера для быстрого сайта

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

Можно ли всё это сделать на обычном виртуальном хостинге?

Частично. Версию PHP, кэш через плагин, сжатие и правила для статики обычно можно настроить в панели или через .htaccess. Тонкая настройка nginx, Redis и параметров MySQL чаще всего доступна только на VPS или по запросу в поддержку.

Не сломается ли сайт после включения кэша?

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

Сколько ускорения ждать?

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

Нужен ли CDN?

CDN полезен, если аудитория распределена по разным регионам или сайт отдаёт много тяжёлой статики. Для локального бизнеса с аудиторией в одном городе сначала стоит настроить сам сервер — подробнее в статье CDN для сайта.

Если не хотите разбираться сами

Мы в Pear Advert регулярно настраиваем серверы под сайты клиентов: проводим замеры, включаем кэширование, обновляем PHP и проверяем, что ничего не сломалось. Если не хотите разбираться сами — поможем подобрать и настроить сервер в рамках услуги аренда сервера и хостинга.

В статье есть партнёрские ссылки: если вы зарегистрируетесь по ним, студия получит вознаграждение, для вас цена не меняется.

Читать дальше

Статьи по теме

Начать проект

Давайте сделаем крутой проект вместе

Расскажите о задаче — мы бесплатно проанализируем нишу, предложим решение и назовём сроки со стоимостью. Без навязчивых звонков.

Телефон

8 (926) 837 76 68

Почта

info@pear-advert.ru

Офис

Москва, ул. Гиляровского, 57с1

Оставьте заявку

Ответим в течение рабочего дня

Выберите тип проекта

Данные используются только для ответа на заявку и хранятся не дольше трёх лет.