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, із живими замірами та налаштуванням: