Сайт, который ставит cookie посетителям (аналитика, метрики, рекламные пиксели, авторизация), по 152-ФЗ должен получить согласие до установки не-необходимых cookie. РКН разъяснял: строго необходимое (сессия, корзина, безопасность) — можно без баннера; аналитика и реклама — только после явного согласия. Плюс с 2025 года ужесточился контроль за рекламными cookie и передачей данных рекламным системам.
Серия экспериментов на четырёх живых сайтах (один VPS с CloudPanel: nginx, PHP 8.5, Redis, MySQL 8.4; сайты от 68 до 315 МБ базой, от 1 500 до 9 300 записей, 13–17 активных плагинов на тяжёлом). Все замеры — ab под нагрузкой плюс серия одиночных запросов, в одном часовом окне для каждой пары сравнений, с прогретым OPcache.
Хостинговые инструкции по оптимизации WordPress почти всегда содержат пункт «почистите базу»: ревизии, спам-комментарии, протухшие транзиенты. Обещают лёгкость и скорость. Я прогнал такую чистку на трёх своих живых сайтах (один VPS, WordPress, MySQL 8.4, от 68 до 315 МБ на базу) с замерами до и после — и результаты оказались показательными, хотя и не такими, как ждёшь.
Четыре оптимизации, которые стоят в конце любого чек-листа: локальные шрифты вместо Google Fonts, preload ключевых ресурсов, font-display и критический CSS. По отдельности каждая даёт 50–300 мс, вместе — заметное ускорение первой отрисовки. Разбираю каждую: что даёт, как настроить, где грабли. Проверено на живых сайтах (включая сайт с системными шрифтами — для него половина списка неактуальна, и это тоже результат).
Хостинговые инструкции по оптимизации WordPress почти всегда советуют плагин Heartbeat Control: «Heartbeat API — самый ресурсоёмкий процесс в WordPress, отключите или замедлите его». Совет рабочий, но прежде чем ставить ещё один плагин, проверьте два факта: сколько ваш сайт реально генерирует heartbeat-запросов, и — главное — нет ли контроль Heartbeat уже встроен в плагины, которые у вас стоят.
Классический совет «поставьте плагин оптимизации изображений» скрывает главный вопрос: будет ли экономия и сколько именно. На одном из моих сайтов — каталоге отзывов с библиотекой 50 922 файла и 13,6 ГБ картинок — я проверил это замерами: контрольной конвертацией образцов и полным прогоном всех файлов картинок одной реальной страницы.
Memcached — классический кэш в ОЗУ: проще Redis, многопоточный, без персистентности. Для объектного кэша WordPress на одном сервере возможности сравнимы с Redis. Здесь — замер трёх состояний на живом сайте и две ловушки, из-за которых связка не заработала «из коробки».
Сайт тормозит. Первая мысль — «поставить плагин кэширования». Но кэш лечит симптом: чтобы понять, что именно тормозит, нужно profiling — разложить загрузку страницы на этапы и посмотреть, где теряется время. Query Monitor для этого отличный, но требует работы в админке и держать его на проде постоянно не хочется.
Объектный кэш — второй уровень кэширования после кэша страниц. Если кэш страниц сохраняет готовый HTML, то объектный кэш хранит в ОЗУ результаты SQL-запросов: опции, термины, транзиенты, произвольные данные плагинов. Каждый просмотр страницы перестаёт гонять эти запросы в MySQL.
Ключевое свойство, из-за которого он стоит особняком: объектный кэш кэширует данные, а не HTML. Значит он не нарушает DONOTCACHEPAGE — заголовок «не кэшировать страницу» относится к страничному кэшу, а данные в ОЗУ кэшировать можно всегда. Это единственный способ ускорить сайт, где стоит обязательный экран согласия или другой HTML-гейт.
Хостинговые инструкции часто советуют полностью отключить ревизии WordPress — мол, они распухают и тормозят. Совет рабочий ровно наполовину: на сайте из моей серии замеров у одного сайта было 2 907 ревизий, у другого — 1, у третьего — 244. И только у одного из них это реально было проблемой. Полное отключение ревизий — слишком грубый инструмент: вы теряете историю правок, а это для автора текстов страховка от потери кусков текста. Правильный инструмент — лимит.
