Главная

Оптимизация сайта и веб-сервера

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

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

Зачем ускорять сайт

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

Оптимизация позволяет:

  • уменьшить время ответа сервера;
  • ускорить отображение основного содержимого;
  • снизить потребление процессора и оперативной памяти;
  • увеличить количество одновременных посетителей;
  • сократить объём передаваемых данных;
  • уменьшить вероятность ошибок 502 и 504;
  • улучшить работу сайта на мобильных устройствах;
  • снизить расходы на серверную инфраструктуру.

С чего начинать оптимизацию

Начинать следует не с случайного изменения конфигурации, а с измерений. Оптимизация без диагностики может не дать результата или даже ухудшить работу проекта.

Перед началом работ рекомендуется зафиксировать:

  • время ответа сервера;
  • полное время загрузки страницы;
  • объём HTML, CSS, JavaScript и изображений;
  • количество HTTP-запросов;
  • нагрузку на процессор;
  • потребление оперативной памяти;
  • скорость выполнения SQL-запросов;
  • количество процессов PHP-FPM;
  • частоту ошибок в журналах;
  • поведение сайта при одновременных запросах.

После каждого изменения следует повторять измерения. Так можно понять, какая настройка действительно принесла результат.

Уровни оптимизации сайта

Условно работы можно разделить на несколько уровней:

  1. оптимизация HTML, CSS, JavaScript и изображений;
  2. настройка браузерного и серверного кеширования;
  3. оптимизация PHP-кода и PHP-FPM;
  4. оптимизация базы данных;
  5. настройка Nginx или Apache;
  6. оптимизация операционной системы и оборудования;
  7. использование CDN и внешних сервисов;
  8. постоянный мониторинг производительности.

Оптимизация изображений

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

Для оптимизации изображений необходимо:

  • уменьшать изображение до фактического размера отображения;
  • выбирать подходящий формат;
  • настраивать разумную степень сжатия;
  • удалять ненужные метаданные;
  • использовать WebP или AVIF при наличии поддержки;
  • создавать отдельные размеры для мобильных устройств;
  • применять атрибуты srcsetи sizes;
  • включать отложенную загрузку изображений вне первого экрана;
  • не использовать большое изображение в качестве маленькой иконки.

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

Lazy Loading

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

Для обычных изображений можно использовать:

<img src="/images/photo.webp"
     alt="Описание изображения"
     loading="lazy"
     width="800"
     height="600">

Атрибуты ширины и высоты помогают браузеру заранее зарезервировать место под изображение и уменьшают смещение содержимого во время загрузки.

Оптимизация CSS

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

Основные способы оптимизации CSS:

  • удаление неиспользуемых правил;
  • минификация файлов;
  • разделение стилей по страницам или компонентам;
  • уменьшение количества тяжёлых библиотек;
  • предварительная загрузка критически важных ресурсов;
  • встраивание небольшого объёма критического CSS;
  • отложенная загрузка второстепенных стилей;
  • сокращение чрезмерно сложных селекторов.

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

Оптимизация JavaScript

JavaScript может блокировать отображение страницы и занимать основной поток браузера. Особенно сильно влияют тяжёлые frontend-библиотеки, виджеты, рекламные системы, чаты, карты и счётчики аналитики.

Рекомендуемые меры:

  • удалить неиспользуемые скрипты;
  • не подключать библиотеку ради одной небольшой функции;
  • использовать атрибуты deferили asyncтам, где это допустимо;
  • разделять код и загружать его по необходимости;
  • откладывать запуск второстепенных виджетов;
  • сократить количество сторонних скриптов;
  • избегать тяжёлых операций при прокрутке страницы;
  • не выполнять повторно одинаковые вычисления;
  • проверять ошибки в консоли браузера.

Атрибут deferобычно подходит скриптам, которым необходим готовый HTML-документ и которые должны выполняться в порядке подключения:

<script src="/js/app.js" defer></script>

Атрибут asyncиспользуется для независимых скриптов, порядок выполнения которых не имеет значения.

Оптимизация шрифтов

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

Для ускорения шрифтов рекомендуется:

  • оставить только необходимые гарнитуры и начертания;
  • использовать формат WOFF2;
  • создавать подмножества символов при необходимости;
  • настраивать font-display;
  • предварительно загружать только критически важные файлы;
  • не загружать весь набор иконок ради нескольких символов;
  • рассмотреть системные шрифты для простых проектов.

Браузерное кеширование

Браузерное кеширование позволяет повторно использовать CSS, JavaScript, изображения и шрифты без повторного скачивания при каждом посещении страницы.

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

/css/app.8f31a2.css
/js/app.27c82d.js

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

Сжатие передаваемых данных

HTML, CSS, JavaScript, JSON и SVG хорошо сжимаются. На сервере можно использовать Gzip или Brotli. Уже сжатые форматы изображений, видео и архивов обычно не получают заметной выгоды от повторного сжатия.

Пример базовой настройки Gzip в Nginx:

gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_comp_level 5;

gzip_types
    text/plain
    text/css
    text/javascript
    application/javascript
    application/json
    application/xml
    image/svg+xml;

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

HTTP/2 и HTTP/3

Современные протоколы позволяют эффективнее передавать несколько ресурсов в рамках одного соединения. Поэтому старые рекомендации обязательно объединять все CSS и JavaScript в один огромный файл не всегда актуальны.

Однако переход на новый протокол не исправит медленный PHP-код, тяжёлые SQL-запросы или неоптимизированные изображения. HTTP/2 и HTTP/3 являются частью общей оптимизации, а не заменой остальных работ.

Кеширование страниц

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

Кешировать можно:

  • полную HTML-страницу;
  • отдельные фрагменты;
  • результаты SQL-запросов;
  • объекты приложения;
  • ответы API;
  • сформированные изображения;
  • результаты сложных вычислений.

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

FastCGI Cache в Nginx

FastCGI Cache позволяет Nginx сохранять ответы PHP-FPM и при повторном запросе отдавать их без запуска PHP.

Упрощённый пример:

fastcgi_cache_path /var/cache/nginx
    levels=1:2
    keys_zone=PHP_CACHE:100m
    inactive=60m;

server {
    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php-fpm.sock;

        fastcgi_cache PHP_CACHE;
        fastcgi_cache_valid 200 10m;
        fastcgi_cache_use_stale error timeout updating;
    }
}

Реальная конфигурация должна учитывать cookies, авторизацию, административные страницы, POST-запросы, корзину, персональные данные и механизм очистки кеша.

Redis и объектный кеш

Redis или другой сервер хранения данных в памяти можно использовать для кеширования объектов, результатов запросов, сессий и временной информации.

Объектный кеш особенно полезен для CMS и приложений, которые при каждом запросе повторно получают одинаковые настройки, меню, категории и другие данные.

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

Оптимизация PHP

Производительность PHP зависит от версии языка, качества программного кода, установленных расширений, настроек OPcache и конфигурации PHP-FPM.

Основные рекомендации:

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

Настройка OPcache

OPcache хранит скомпилированный байт-код PHP в общей памяти. Без него PHP приходится повторно читать, разбирать и компилировать файлы при выполнении запросов.

Пример базовых параметров:

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=50000
opcache.validate_timestamps=1
opcache.revalidate_freq=2
opcache.save_comments=1

Значения следует подбирать по размеру проекта и количеству PHP-файлов. Если памяти недостаточно или таблица кешируемых файлов заполнена, OPcache не сможет эффективно хранить весь код.

Отключение opcache.validate_timestampsможет уменьшить количество проверок файлов, но после обновления кода потребуется вручную сбрасывать кеш или перезапускать PHP-FPM. Такой режим допустим только при контролируемом процессе развёртывания.

Настройка PHP-FPM

PHP-FPM управляет рабочими процессами, которые выполняют PHP-код. Слишком малое количество процессов создаёт очередь запросов, а слишком большое может полностью занять оперативную память.

Основные режимы:

  • static— постоянное число процессов;
  • dynamic— число процессов изменяется в заданных пределах;
  • ondemand— процессы запускаются по мере поступления запросов.

При настройке необходимо учитывать средний объём памяти одного PHP-процесса, общий объём RAM, нагрузку базы данных и другие сервисы.

Для диагностики полезны параметры:

pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers
pm.max_requests
request_slowlog_timeout
slowlog
request_terminate_timeout

Журнал медленных запросов PHP-FPM помогает определить скрипты, которые выполняются слишком долго.

Оптимизация PHP-кода

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

Следует проверять:

  • количество запросов к базе данных;
  • повторное выполнение одинаковых функций;
  • загрузку больших массивов в память;
  • неограниченные циклы;
  • обработку больших файлов;
  • внешние HTTP-запросы;
  • синхронную отправку почты;
  • создание изображений при каждом запросе;
  • работу автозагрузчика;
  • избыточное журналирование.

Долгие операции лучше выполнять в очереди или по расписанию, а пользователю сразу возвращать результат принятия задачи.

Оптимизация MySQL и MariaDB

База данных часто является причиной медленной генерации страниц. Простое увеличение памяти сервера не всегда решает проблему: сначала необходимо найти медленные запросы и проверить их план выполнения.

Основные направления оптимизации:

  • включение журнала медленных запросов;
  • анализ запросов через EXPLAIN;
  • создание необходимых индексов;
  • удаление лишних индексов;
  • сокращение количества возвращаемых строк;
  • отказ от ненужного SELECT *;
  • оптимизация соединений таблиц;
  • архивация старых данных;
  • очистка служебных таблиц CMS;
  • настройка InnoDB с учётом доступной памяти.

Индексы базы данных

Индексы ускоряют поиск строк по условиям, сортировку и соединение таблиц. Особенно важны поля, которые регулярно используются в WHERE, JOIN, ORDER BYи GROUP BY.

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

Пример анализа запроса:

EXPLAIN
SELECT id, title
FROM articles
WHERE category_id = 5
ORDER BY created_at DESC
LIMIT 20;

Результат необходимо изучить: какие индексы доступны, какой индекс выбран, сколько строк предполагается проверить и используются ли временная таблица или дополнительная сортировка.

Проблема N+1 запросов

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

Например, страница показывает 100 товаров и дополнительно запрашивает производителя каждого товара. В результате вместо одного или двух запросов выполняется 101 запрос.

Проблему можно решить с помощью:

  • соединения таблиц;
  • предварительной загрузки связанных данных;
  • группового запроса;
  • кеширования;
  • изменения структуры получения данных.

Настройка InnoDB

Для серверов MySQL и MariaDB важен размер буферного пула InnoDB. Он используется для хранения страниц данных и индексов в оперативной памяти.

Размер нельзя назначать по универсальному шаблону. На выделенном сервере базы данных можно использовать значительную часть памяти, а на одном VPS с Nginx, PHP-FPM, Redis и другими сервисами необходимо оставить RAM для остальных процессов и операционной системы.

Оптимизация Nginx

Nginx эффективно обслуживает статические файлы, работает как reverse proxy и передаёт PHP-запросы в PHP-FPM. Но стандартная конфигурация не всегда оптимальна для конкретного проекта.

Следует проверить:

  • количество worker-процессов;
  • лимиты соединений;
  • таймауты;
  • размеры буферов;
  • кеширование статических файлов;
  • сжатие;
  • логи доступа и ошибок;
  • настройки FastCGI;
  • ограничение слишком больших запросов;
  • защиту от медленных соединений.

Не следует без измерений увеличивать все буферы и таймауты. Большие значения могут повысить потребление памяти и скрыть проблему медленного backend-приложения.

Оптимизация Apache

При использовании Apache необходимо учитывать выбранный MPM, способ подключения PHP, количество процессов и использование файлов .htaccess.

Для производительного сервера PHP обычно запускают через PHP-FPM, а не через устаревшую схему встраивания интерпретатора в каждый процесс Apache.

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

Связка Nginx и Apache

В некоторых конфигурациях Nginx принимает внешние запросы, обслуживает статические файлы и передаёт динамические страницы Apache. Такая схема используется панелями управления и сайтами, которым необходимы правила .htaccess.

Она может работать эффективно, но добавляет ещё один уровень обработки. Если Apache не нужен приложению, более простая связка Nginx и PHP-FPM часто требует меньше ресурсов и легче диагностируется.

Оптимизация CMS

WordPress, Drupal, Joomla, 1С-Битрикс и другие CMS имеют собственные механизмы кеширования и типичные причины замедления.

Общие рекомендации:

  • удалить ненужные модули и плагины;
  • не устанавливать несколько расширений с одинаковыми функциями;
  • обновлять CMS и расширения;
  • очищать устаревшие служебные данные;
  • проверять фоновые задачи;
  • ограничивать чрезмерное журналирование;
  • использовать встроенное кеширование;
  • проверять запросы, создаваемые расширениями;
  • оптимизировать поиск и фильтры каталога;
  • не кешировать персональные страницы как общедоступные.

Оптимизация WordPress

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

Следует проверить:

  • какие плагины создают больше всего запросов;
  • размер таблицы опций;
  • автоматически загружаемые настройки;
  • частоту выполнения WP-Cron;
  • ревизии записей;
  • транзиентные данные;
  • запросы к внешним сервисам;
  • работу кеша страниц и объектов;
  • нагрузку административной панели.

Оптимизация Drupal

В Drupal необходимо включить встроенное кеширование, агрегирование CSS и JavaScript, а также проверить работу модулей и представлений.

Особое внимание следует уделять:

  • сложным Views;
  • избыточным модулям;
  • кешу рендеринга;
  • кешу динамических страниц;
  • очередям и Cron;
  • таблицам кеша;
  • индексам базы данных;
  • внешним интеграциям.

Оптимизация 1С-Битрикс

В 1С-Битрикс производительность зависит от управляемого кеша, композитного режима, структуры инфоблоков, фоновых агентов и базы данных.

Необходимо проверять:

  • встроенный монитор производительности;
  • настройку кеширования компонентов;
  • композитный сайт;
  • агенты и Cron;
  • размер служебных таблиц;
  • индексы;
  • обмен с внешними системами;
  • настройки OPcache;
  • конфигурацию PHP и базы данных.

CDN

CDN размещает копии статических ресурсов на распределённых узлах и отдаёт их пользователям с ближайшей точки. Это может сократить задержку для посетителей из разных регионов и уменьшить нагрузку на основной сервер.

Через CDN обычно распространяют:

  • изображения;
  • CSS и JavaScript;
  • шрифты;
  • видео;
  • файлы для скачивания;
  • в некоторых случаях закешированные HTML-страницы.

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

Core Web Vitals

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

Для улучшения показателей необходимо:

  • быстро отдавать HTML;
  • оптимизировать главное изображение;
  • не блокировать отображение тяжёлыми CSS и JavaScript;
  • задавать размеры изображений и встроенных элементов;
  • уменьшать длительные задачи JavaScript;
  • сокращать количество сторонних скриптов;
  • не вставлять новые блоки над уже отображённым содержимым;
  • проверять реальные данные пользователей, а не только лабораторный тест.

TTFB и время ответа сервера

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

Для диагностики необходимо разделить время на этапы:

  • DNS-разрешение;
  • установка TCP-соединения;
  • TLS-согласование;
  • ожидание ответа приложения;
  • передача содержимого.

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

Нагрузочное тестирование

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

Следует измерять:

  • количество запросов в секунду;
  • среднее время ответа;
  • медиану и высокие процентили;
  • процент ошибок;
  • нагрузку процессора;
  • потребление памяти;
  • очередь PHP-FPM;
  • соединения базы данных;
  • дисковый ввод-вывод.

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

Мониторинг сервера

Однократная оптимизация не гарантирует постоянную скорость. Количество данных, посещаемость, расширения и код со временем меняются.

Полезно отслеживать:

  • доступность сайта;
  • время ответа;
  • нагрузку CPU;
  • использование RAM и swap;
  • свободное место на дисках;
  • дисковую задержку;
  • количество процессов PHP-FPM;
  • число соединений с базой данных;
  • ошибки Nginx, Apache и PHP;
  • срок действия SSL-сертификата;
  • успешность резервного копирования.

Журналы ошибок

Перед изменением конфигурации следует проверить журналы. Они часто прямо указывают на причину проблемы.

Основные журналы:

  • Nginx access log и error log;
  • Apache access log и error log;
  • PHP-FPM error log и slow log;
  • MySQL или MariaDB error log;
  • журнал медленных SQL-запросов;
  • системный журнал;
  • журналы приложения и CMS.

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

Аппаратные ресурсы

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

При выборе сервера следует учитывать:

  • производительность одного ядра;
  • количество доступных ядер;
  • объём оперативной памяти;
  • скорость NVMe или SSD;
  • лимиты дискового ввода-вывода;
  • скорость сетевого подключения;
  • ограничения виртуализации;
  • расположение дата-центра.

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

Типичные ошибки при оптимизации

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

Порядок оптимизации сайта

Практическую работу удобно выполнять в следующем порядке:

  1. создать резервную копию;
  2. измерить исходные показатели;
  3. проверить ошибки и журналы;
  4. обновить поддерживаемые версии программ;
  5. оптимизировать изображения и frontend-ресурсы;
  6. включить браузерное кеширование и сжатие;
  7. проверить кеширование страниц и объектов;
  8. настроить OPcache и PHP-FPM;
  9. найти медленные SQL-запросы;
  10. проверить конфигурацию Nginx или Apache;
  11. выполнить нагрузочное тестирование;
  12. настроить постоянный мониторинг.

Вывод

Оптимизация сайта и веб-сервера не сводится к одной настройке. Быстрый проект требует согласованной работы frontend-кода, PHP, базы данных, веб-сервера, кеша и серверного оборудования.

Сначала необходимо измерить производительность и определить реальное узкое место. Если сервер быстро отдаёт HTML, но страница долго отображается, следует оптимизировать изображения, CSS и JavaScript. Если высокий TTFB, нужно анализировать PHP, SQL-запросы, кеширование и конфигурацию сервера.

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

Ваша оценка: Нет Средняя: 3.6 (7 голосов)

Опрос

Лучшая система для веб-сервера:

Вход в систему

phpspb.ru. Журнал веб-разработчиков