GTmetrix выдаёт вашей странице 72/100, а в рекомендациях горит «Serve static content from a cookieless domain». Вы кликаете, и видите список из 40 CSS-файлов, каждый из которых тащит за собой Set-Cookie-заголовок. Картинки, шрифты, скрипты, десятки запросов, и в каждом болтается HTTP-заголовок, который этим файлам абсолютно не нужен.

Проблема не в вашем коде. Это архитектурная особенность: сервер устанавливает cookie на уровне домена, и браузер послушно прикрепляет их к каждому запросу, даже к тем, где авторизация и сессии не имеют смысла. Результат: лишние килобайты в каждом ответе, замедленная загрузка статики и красный флаг в отчётах GTmetrix и Pingdom.

Хорошая новость: за 15 минут это чинится без замены хостинга. Вам не нужен второй сервер, не нужен дорогой enterprise-тариф. Достаточно отдельного поддомена или CDN, и статические файлы пойдут без cookie, а балл в GTmetrix поднимется на 10-15 пунктов.

💡 Быстрый обзор:

• Разберитесь, почему cookie «протекают» на статику и когда это действительно проблема
• Настройте отдельный поддомен для wp-content через cPanel, пошагово, включая SQL-замену URL
• Подключите KeyCDN через плагин CDN Enabler как современную альтернативу (5 минут, от $4/мес)
• Узнайте, почему Cloudflare не снимает предупреждение GTmetrix, и когда на это можно забить

Почему cookie попадают на статику

Cookie устанавливаются на уровне домена. Но есть нюанс, который часто упускают: поддомены наследуют cookie-настройки родителя. Если сайт живёт на example.com и ставит cookie для этого домена, их автоматически получают www.example.com и static.example.com.

Именно поэтому недостаточно просто создать поддомен static.example.com. Пока основной сайт на голом домене, cookie «протекут» и на поддомен. Решение простое, но контринтуитивное: вынести сайт на www.example.com, а статику, на static.example.com. Тогда cookie действуют на www, а static остаётся чистым.

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

И ещё: на управляемых WordPress-хостингах вроде Kinsta, WP Engine или SiteGround проблема часто уже решена на уровне сервера. Если в тарифе есть «edge caching» или «CDN included», дополнительная настройка не требуется.

Способ 1. Отдельный поддомен для статики через cPanel

Базовый метод, который работает на любом хостинге с cPanel. Никаких сторонних сервисов, никаких ежемесячных платежей. Суть: создаём поддомен, привязываем его к /wp-content и говорим WordPress отдавать статику через него.

Создайте поддомен

Зайдите в cPanel → раздел «Domains» → «Subdomains». Создайте поддомен static.вашсайт.com. В поле Document Root укажите путь к wp-content: обычно это public_html/wp-content.

Проверьте: основной сайт должен быть на www.вашсайт.com. Если сидите на голом домене без www, сначала перенесите сайт на www, иначе метод не сработает.

Добавьте константы в wp-config.php

Откройте wp-config.php в корне сайта и добавьте две строки ПЕРЕД комментарием /* That's all, stop editing! Happy publishing. */:

1
define('WP_CONTENT_URL', 'https://static.вашсайт.com');
2
define('COOKIE_DOMAIN', 'www.вашсайт.com');

WP_CONTENT_URL говорит WordPress отдавать весь контент из /wp-content/ через новый поддомен. COOKIE_DOMAIN ограничивает зону действия cookie поддоменом www, не давая им расползтись на static.

Замените URL существующих файлов в базе

Уже опубликованные записи хранят ссылки на старые URL изображений. Их нужно заменить массово через phpMyAdmin.

Заходите в phpMyAdmin (cPanel → Databases), выбираете базу WordPress, вкладка SQL. Выполните:

1
UPDATE wp_posts SET post_content = REPLACE(post_content, 'www.вашсайт.com/wp-content/', 'static.вашсайт.com/');

Перед выполнением, бэкап базы. SQL-замена необратима. Ошибётесь в URL, картинки на сайте сломаются, восстанавливать придётся из копии.

Плюсы и минусы

Метод работает без сторонних сервисов и дополнительных расходов. Но: ручная правка wp-config.php и базы данных, риск ошибиться в SQL, необходимость поддерживать конфигурацию двух поддоменов. На VPS с NGINX нужно ещё править конфигурацию сервера, что добавляет сложности.

Для большинства сайтов сегодня есть вариант проще, CDN.

Способ 2. CDN как современное решение

Content Delivery Network забирает статику на свои серверы и по умолчанию не использует cookie для файлов. Вы получаете две вещи сразу: статика без cookie плюс глобальная сеть доставки, ускоряющая загрузку для посетителей из любой точки мира.

Сервис KeyCDN, pay-as-you-go CDN с ценой от $0,04/ГБ трафика и минимальным платежом $4/мес. Для среднего сайта расходы составляют $4-10 в месяц. 60+ точек присутствия, встроенная опция Strip Cookies, которая принудительно удаляет Set-Cookie-заголовки с ответов.

Подключение через CDN Enabler

CDN Enabler, официальный плагин KeyCDN для WordPress. Версия 2.0.8, 10 000+ активных установок, протестирован вплоть до WordPress 6.9. Он перехватывает страницы и переписывает URL статических файлов на домен CDN.

Шаги настройки:

• Создайте аккаунт KeyCDN. Сервис даёт пробный период, можно протестировать без оплаты.

• Установите CDN Enabler из репозитория WordPress: Plugins → Add New → поиск «CDN Enabler» → Activate.

• Создайте Pull-зону в дашборде KeyCDN. Зона определяет, какой контент CDN будет забирать с вашего сайта. Укажите origin URL, адрес сайта.

• Скопируйте URL зоны, он выглядит как https://вашазона.kxcdn.com, и вставьте в настройки CDN Enabler: Settings → CDN Enabler → CDN Hostname.

• Включите Strip Cookies в KeyCDN: Zone Settings → Strip Cookies = Enabled. Именно эта опция гарантирует, что статические файлы отдаются без Set-Cookie-заголовков.

• Очистите кеш сайта и проверьте результат в GTmetrix.

CDN Enabler работает с любым CDN. Если вы уже пользуетесь Cloudflare, BunnyCDN или StackPath, просто укажите CDN Hostname вашего провайдера.

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

Способ 3. Cloudflare, бесплатно, но с оговоркой

Cloudflare, крупнейший CDN с полностью бесплатным тарифом. Работает на уровне DNS: переключаете домен на неймсерверы Cloudflare, и весь трафик идёт через его сеть.

Но есть нюанс. Cloudflare использует служебный cookie _cfduid для каждого запроса в целях безопасности. Он критичен для защиты от DDoS и ботов, даже если включить опцию «Strip Cookies» на тарифе Pro, этот cookie не удаляется.

Из-за _cfduid GTmetrix продолжит показывать предупреждение «Serve static content from a cookieless domain». Добиться 100/100 в метрике YSlow с бесплатным Cloudflare технически невозможно. Но это ложное срабатывание: статика через Cloudflare всё равно грузится быстро, а один служебный cookie не влияет на реальную производительность.

Если вам важен максимальный балл в GTmetrix, KeyCDN со Strip Cookies. Если приоритет, бесплатность и защита от DDoS, Cloudflare справляется полностью.

Когда предупреждение GTmetrix можно игнорировать

Распространённая ситуация: CDN настроен, Strip Cookies включён, но GTmetrix всё равно показывает ошибку cookieless domain. Причина в том, что YSlow, движок GTmetrix, не проверяет, включена ли опция Strip Cookies на стороне CDN. Он видит URL, похожий на основной домен, и механически ставит предупреждение.

Проверка за 30 секунд: откройте Chrome DevTools (F12) → Network → выберите любой статический файл, CSS, JS или PNG → вкладка Headers → Request Headers. Если там нет строки Cookie:, статика уходит без cookie, предупреждение GTmetrix можете игнорировать.

Другой источник ложных срабатываний, серверные cookie аналитики и A/B-тестов (Google Analytics, Hotjar, VWO). Они тоже попадают в отчёт как «лишние», хотя на скорость страницы влияют минимально.

Реальное снижение трафика от удаления cookie со статики, порядка 5-15% от общего объёма запросов. Не революция, но каждая миллисекунда на счету: исследование Google показало, что задержка в 1 секунду снижает конверсию мобильных посетителей на 20%.

⁉️🤔 Частые вопросы

Обязательно ли настраивать домен без cookie?

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

Что делать, если после правки wp-config.php сайт перестал открываться?

Почти наверняка вы ошиблись в URL констант или разместили их ПОСЛЕ строки /* That's all, stop editing! */. Подключитесь к сайту по FTP, откройте wp-config.php и проверьте: константы должны быть ДО этого комментария. Если сайт всё равно не грузится, закомментируйте добавленные строки (// в начале каждой), сайт вернётся к исходному состоянию, после чего пробуйте снова с правильными URL.

Можно ли использовать CDN Enabler с другими плагинами кеширования?

Да, без проблем. CDN Enabler совместим с Cache Enabler, WP Rocket, W3 Total Cache и LiteSpeed Cache. Один нюанс: если у вас WP Rocket, CDN настраивается в самом WP Rocket, отдельный плагин CDN Enabler не нужен. С остальными кеширующими плагинами работает параллельно, конфликтов не зафиксировано.

Какой CDN выбрать для небольшого сайта?

Зависит от бюджета и приоритетов. Тарифами KeyCDN (от $0,04/ГБ, минимум $4/мес), хороший старт: pay-as-you-go, платите только за трафик. Cloudflare, бесплатный, но со служебным cookie и ложным предупреждением GTmetrix. BunnyCDN (от $0,01/ГБ на объёмном тарифе, от $1/мес минимум), дешевле, но с меньшим количеством точек присутствия. Для сайта с посещаемостью до 10 000 в месяц расходы на CDN составят $2-7.

Нужен ли домен без cookie, если хостинг современный?

Управляемые WordPress-хостинги, Kinsta, WP Engine, SiteGround, часто включают встроенный CDN или серверное кеширование, которое уже решает проблему cookie. Проверьте тариф: если в описании есть «edge caching» или «CDN included», дополнительная настройка не требуется. На дешёвом shared-хостинге без CDN настройка домена без cookie даст ощутимый прирост.

Что делать, если после SQL-запроса картинки пропали?

Либо ошиблись в URL (проверьте совпадение доменов в запросе и настройках поддомена), либо поддомен static.вашсайт.com указывает не на ту директорию. Восстановите базу из бэкапа и проверьте: Document Root поддомена должен быть public_html/wp-content, а домен в SQL-запросе, совпадать с созданным в cPanel (с www. или без, зависит от настройки основного сайта).

Какой метод выбрать под вашу задачу

Если сайт на дешёвом хостинге без CDN и без бюджета на платные сервисы, настройте отдельный поддомен через cPanel. Это 15 минут работы: поддомен, две строки в wp-config.php и один SQL-запрос. Статика пойдёт без cookie, GTmetrix поднимется. Минус, ручная поддержка и отсутствие глобального ускорения.

Если готовы платить $4-10 в месяц, ставьте связку KeyCDN + CDN Enabler. Та же задача решается автоматически, плюс вы получаете сеть доставки из 60+ точек, сжатие и ускорение для посетителей из любой точки мира. Для проекта, который зарабатывает или планирует зарабатывать, CDN окупается немедленно.

И главное, не зацикливайтесь на баллах GTmetrix. Реальная скорость для пользователя важнее цифр в отчёте. Если статика уходит без cookie (проверили через DevTools), а сайт грузится быстрее 2 секунд, задача решена.

Освежить картину целиком по ускорению WordPress поможет официальный гайд от команды WordPress.com, от кеширования до CDN, с живыми замерами и настройкой: