Активирайте компресията Gzip и Brotli в WordPress

Ако някога сте виждали „Активиране на компресията на текст“ в PageSpeed ​​​​Insights, въпреки че сайтът ви „изглежда бърз“, вероятно използвате некомпресиран HTML/CSS/JS. А на мобилни устройства това бързо води до рязко спадане на LCP и TTFB, който няма никакъв шанс.

Проблемът с производителността

Когато HTTP компресията (Gzip или Brotli) не е активирана, всяка HTML страница, всеки CSS стилов лист и всеки JS файл се изпращат „сурови“ по мрежата. На страница WordPress 6.9.4 типични (тема + плъгини + страница строител), това може да представлява няколкостотин ненужни килобайта при всяко посещение.

Най-видимият симптом: приемливо време за зареждане през оптичен кабел, но катастрофално през 4G/3G. Можете да го видите в инструментите: висок мрежов трансфер, липсваща опция „Кодиране на съдържание“ и спадащ резултат за Core Web Vitals, особено на мобилни устройства.

Въздействие на бетона:

• SEO Ранг Google взема предвид скоростта и CWV сигналите (LCP/INP/CLS) при разглеждането на страницата.
• Степен на отпадане Колкото повече време отнема на страницата, за да стане използваема, толкова повече посетители я напускат.
• Цена на сървъра : без Компресията консумира повече честотна лента (а понякога и повече CPU от страна на CDN/прокси).

В крайна сметка ще знаете:

• activer Brotli ако вашият стек го позволява, в противен случай Gzip правилно чрез .htaccess (Apache/LiteSpeed)
• проверете чрез код/CLI дали компресията действително се прилага.
• избягвайте често срещани клопки (двойна компресия, неправилни MIME типове, кеширане, което маскира промените),
• внедрете резервно решение от страна на PHP, когато доставчикът на хостинг услуги заключи конфигурацията на сървъра (с ограниченията, които това предполага).

Бързо обобщение

• Brotli като цяло е по-ефективен от Gzip, но зависи от сървъра (често Nginx/Cloudflare/Apache чрез модул).
• В Apache/LiteSpeed, Gzip се активира чисто от mod_deflate в .htaccess.
• „Компресия чрез wp-config.php„съществува (zlib), но е план Б : по-малко контролируем, понякога несъвместим с определени кешове/проксита.
• Измерване преди/след с HTTP заявка, която показва Кодиране на съдържанието и прехвърленият размер.
• След модификация, изчистване на кешовете (кеш на плъгини, кеш на сървъра, CDN, браузър), в противен случай тествате стар отговор.

Диагностичен код

Предварителни Направете резервно копие (файлове + база данни) преди да промените .htaccess ou wp-config.phpНикога не модифицирайте ядрото на WordPress. Работете в тестова среда, ако е възможно.

1) Разбиране на това, което измерваме

HTTP компресията може да се провери чрез заглавката на отговора. Кодиране на съдържанието :

• br = Бротли
• gzip = Gzip
• липсва = няма компресия (или компресията се управлява другаде, но не е обявена, което е рядко и проблематично)

Браузърът изпраща заглавката Приемане-кодиране (Например, br, gzipСървърът избира какво да поддържа.

2) Проверете от вашата машина (cURL)

Най-надеждният тест се извършва в терминала. Той избягва разширенията на браузъра и „невидимите“ кешове.

# Remplacez par votre URL (idéalement une page publique non protégée)
URL="https://example.com/"

# Affiche uniquement les en-têtes et force une demande Brotli + Gzip
curl -I -H "Accept-Encoding: br,gzip" "$URL"

# Variante : afficher aussi la taille téléchargée et le type d'encodage reçu
curl -s -o /dev/null 
  -H "Accept-Encoding: br,gzip" 
  -w "http_code=%{http_code}ncontent_type=%{content_type}nsize_download=%{size_download}nsize_header=%{size_header}n" 
  "$URL"

Какво търсиш на изхода curl -I :

• Content-Encoding: br (или gzip)
• Vary: Accept-Encoding (важно е кешовете да съхраняват правилно компресирани варианти)

3) Инструментирайте WordPress (измервайте „времето на сървъра“)

Компресията намалява предимно тегло на мрежатаНо също така измервам времето за генериране на WordPress, за да избегна „празнуването“ на активирана компресия, когато back-end системата остава бавна.

Поставете този код в mu-плъгин (препоръчително): създаване wp-content/mu-plugins/perf-timing.phpmu-плъгин (задължителен за употреба) се зарежда автоматично, независимо от темата.

<?php
/**
 * Plugin Name: Perf Timing (MU)
 * Description: Ajoute des en-têtes de debug pour mesurer le temps serveur. À désactiver en production si inutile.
 * Author: Vous
 */

if (!defined('ABSPATH')) {
	exit;
}

add_action('send_headers', function () {
	// Mesure simple : temps depuis le début de l'exécution PHP (WordPress définit généralement $_SERVER['REQUEST_TIME_FLOAT'])
	$start = isset($_SERVER['REQUEST_TIME_FLOAT']) ? (float) $_SERVER['REQUEST_TIME_FLOAT'] : microtime(true);
	$elapsed_ms = (microtime(true) - $start) * 1000;

	// Attention : n'exposez pas trop d'infos sur un site sensible. Ici on reste minimal.
	header('X-WP-Elapsed-MS: ' . number_format($elapsed_ms, 2, '.', ''));

	// Indique si WordPress pense servir une page en mode "is_admin" (utile pour éviter de tester /wp-admin/)
	header('X-WP-Is-Admin: ' . (is_admin() ? '1' : '0'));
}, 9999);

тест:

curl -I -H "Accept-Encoding: br,gzip" "https://example.com/" | grep -i "x-wp-elapsed|content-encoding|vary"

4) WP_DEBUG и лог файлове (откриване на „скрито забавяне“)

Ако вашият сайт изпитва нередовни забавяния, често съм виждал предупреждения от PHP или блокиране на външни извиквания. Активирайте регистриране (не показване) в wp-config.php :

/** Sauvegardez avant modification. À placer au-dessus de "That's all, stop editing!" */

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);      // Log dans wp-content/debug.log
define('WP_DEBUG_DISPLAY', false); // Ne pas afficher aux visiteurs
@ini_set('display_errors', '0');

След това, наблюдавайте wp-content/debug.log по време на тестовете за компресия. Ако видите някакви грешки, коригирайте ги: компресията никога няма да компенсира бавна работа на сървъра.

5) Монитор на заявки и забавен лог на заявки (когато TTFB остава висок)

Монитор на заявките Това е първият плъгин, който инсталирам на бавен уебсайт. Той показва SQL заявки, куки, скриптове, HTTP повиквания и др. Източник: Монитор на заявки в WordPress.org.

За да се задълбочите в работата с базата данни, активирайте бавното регистриране на заявки в MySQL/MariaDB на ниво сървър (ако имате достъп). Тъй като това ръководство е ориентирано към кода, няма да описвам подробно конфигурацията на MySQL тук, но имайте го предвид, ако вашият TTFB остане висок след компресия.

6) WP-CLI: Проверка на средата

WP-CLI ви помага да проверявате активните версии и разширения. В хостинг план, който го позволява:

# Version WordPress (vous êtes sur 6.9.4)
wp core version

# Version PHP vue par WordPress
wp eval 'echo PHP_VERSION . PHP_EOL;'

# Lister les plugins actifs (un cache ou un plugin sécurité peut interférer)
wp plugin list --status=active

---

Стъпка 1: Активиране на компресия от страна на сървъра (Gzip/Brotli)

принципът: компресиране на текстовите отговори (HTML, CSS, JS, JSON, XML, SVG) преди изпращане. Изображенията (JPEG/PNG/WebP/AVIF) вече са компресирани: включването им в Gzip често е ненужно и понякога контрапродуктивно.

Преди (бавно): без кодиране, тежки трансфери

Пример за тест „преди“:

curl -I -H "Accept-Encoding: br,gzip" "https://example.com/"

Типична разходка:

HTTP/2 200
content-type: text/html; charset=UTF-8
# Pas de Content-Encoding
# Parfois pas de Vary: Accept-Encoding non plus

След (оптимизирано): Gzip чрез Apache/LiteSpeed ​​​​(.htaccess)

Къде да поставите кода: в .htaccess в корена на WordPress (на същото ниво като wp-config.php), по-горе от блока на WordPress (# BEGIN WordPress / # END WordPress), или точно отдолу, ако вашият доставчик на хостинг услуги пренаписва файла. Тези директиви работят и на LiteSpeed ​​​​(много често срещано при споделения хостинг).

Добавете това:

# === Compression Gzip (Apache/LiteSpeed via mod_deflate) ===
<IfModule mod_deflate.c>
	# Compresser les contenus texte
	AddOutputFilterByType DEFLATE text/plain
	AddOutputFilterByType DEFLATE text/html
	AddOutputFilterByType DEFLATE text/xml
	AddOutputFilterByType DEFLATE text/css
	AddOutputFilterByType DEFLATE text/javascript
	AddOutputFilterByType DEFLATE application/javascript
	AddOutputFilterByType DEFLATE application/x-javascript
	AddOutputFilterByType DEFLATE application/json
	AddOutputFilterByType DEFLATE application/xml
	AddOutputFilterByType DEFLATE application/rss+xml
	AddOutputFilterByType DEFLATE application/atom+xml
	AddOutputFilterByType DEFLATE image/svg+xml
	AddOutputFilterByType DEFLATE font/ttf
	AddOutputFilterByType DEFLATE font/otf
	AddOutputFilterByType DEFLATE application/font-woff
	AddOutputFilterByType DEFLATE application/font-woff2

	# Éviter quelques bugs d'anciens proxies/navigateurs (rare en 2026, mais sans risque)
	BrowserMatch ^Mozilla/4 gzip-only-text/html
	BrowserMatch ^Mozilla/4.0[678] no-gzip
	BrowserMatch bMSIE !no-gzip !gzip-only-text/html

	# Très important : caches/CDN doivent varier selon Accept-Encoding
	<IfModule mod_headers.c>
		Header append Vary Accept-Encoding
	</IfModule>
</IfModule>

Мярка „след“:

curl -I -H "Accept-Encoding: br,gzip" "https://example.com/" | grep -i "content-encoding|vary"

Очакван :

Content-Encoding: gzip
Vary: Accept-Encoding

Brotli: Какво можете (и не можете) да правите чрез .htaccess

Brotli не е „универсален“ за Apache в споделен хостинг. Технически, Apache може да се справи с него чрез mod_brotliМного доставчици на хостинг услуги обаче не го позволяват. LiteSpeed ​​​​може да обслужва и Brotli, а Cloudflare го прави много добре на периферията.

На практика (2026 г.) най-често получавам Brotli чрез:

• CDN (Cloudflare, Fastly и др.): Brotli е активиран на периферията.
• Nginx : конфигурация на сървъра (не чрез .htaccess).
• LiteSpeed ​​Enterprise : опция за сървър/хост.

И така: чрез .htaccessСтремете се към чист Gzip файл. За Brotli, отидете в раздела „Конфигурация на сървъра“ по-долу (Nginx/CDN) или попитайте вашия доставчик на хостинг услуги.

---

Стъпка 2: Избягвайте двойно компресиране и неправилни MIME типове

Активирането на компресията може да влоши ситуацията, ако се приложи два пъти (или към вече компресирано съдържание). Често съм виждал това в стекове, включващи плъгин за кеширане, обратен прокси и .htaccess правила, копирани от стар урок.

1) Не компресирайте изображения и архиви

Ако насилите компресията image/jpeg, image/png, image/webp, image/avif, .zip, .mp4Печелите малко и изразходвате процесор. Кодът в стъпка 1 вече избягва този капан, като е насочен към текстови типове.

2) Проверете MIME типовете (в противен случай няма да има компресия)

Ако вашият сървър изпраща JS с Content-Type: text/plain или SVG с неправилен тип, може да не отговаря на правилата. Проверете CSS/JS файл:

curl -I -H "Accept-Encoding: br,gzip" "https://example.com/wp-content/themes/votre-theme/style.css"

Трябва да видите:

• Content-Type: text/css
• Content-Encoding: gzip (или br)

3) Откриване на двойно компресиране

симптоми:

• „Повредени“ CSS/JS файлове в браузъра,
• Грешки „Декодирането на съдържанието е неуспешно“
• отговори с Content-Encoding: gzip но прокси сървърът нагоре по веригата компресира отново.

Полезен тест: възстановяване на тялото и опит за декомпресия (опростен подход):

# Télécharge et affiche les en-têtes + quelques octets
curl -s -D - -H "Accept-Encoding: gzip" "https://example.com/" | head -n 40

Ако подозирате двойно компресиране, временно деактивирайте:

• минимизиране/компресиране на кеша на плъгините
• компресия на ниво CDN/прокси,
• или вашите .htaccess правила,

... след това активирайте отново само по едно ниво наведнъж.

---

Стъпка 3: Компресия от страна на PHP (когато нямате директен достъп до сървъра)

Често ще виждате „активиране на Gzip в wp-config.phpДа, съществува чрез zlib, но е решение за резервно копие.

Защо го смятам за план Б:

• Компресирате на ниво PHP, а не на ниво сървър: ако имате кеш на страниците нагоре по веригата (Varnish, Nginx fastcgi_cache, CDN), поведението може да стане объркващо.
• Имате по-малко прецизно разбиране за MIME типовете.
• В случай на неправилна конфигурация може да се задействат грешки в заглавките („заглавките вече са изпратени“).

Вариант А: zlib.output_compression в wp-config.php

Къде да се постави: в wp-config.php, преди реда „Това е всичко, спрете редактирането!“.

<?php
// ... wp-config.php

/** 
 * Compression de sortie PHP (plan B).
 * À éviter si votre serveur/CDN compresse déjà, ou si vous utilisez un cache agressif.
 */
@ini_set('zlib.output_compression', 'On');
@ini_set('zlib.output_compression_level', '6'); // 1-9, 6 est un bon compromis CPU/ratio

Мярка:

curl -I -H "Accept-Encoding: gzip" "https://example.com/" | grep -i "content-encoding"

Вариант Б: Принудително компресиране чрез WordPress hook (още по-скоро като „план Б“)

Un кука е точка за разширение на WordPress. A действие е кука, която изпълнява код в даден момент (за разлика от Филтър което променя стойност).

Ако не можете да докоснете wp-config.php Но можете да добавите mu-плъгин и да активирате gzip буферирането. Забележка: ако плъгинът вече е започнал да извежда, ще получите „заглавките вече са изпратени“.

създавам wp-content/mu-plugins/gzip-fallback.php :

<?php
/**
 * Plugin Name: Gzip Fallback (MU)
 * Description: Active un buffering gzip côté PHP en dernier recours. À utiliser seulement si la compression serveur est impossible.
 */

if (!defined('ABSPATH')) {
	exit;
}

add_action('init', function () {
	// Ne rien faire si zlib n'est pas dispo
	if (!function_exists('ob_gzhandler')) {
		return;
	}

	// Éviter la double compression si un encodage est déjà prévu
	if (headers_sent()) {
		// Trop tard pour modifier les en-têtes proprement
		return;
	}

	// Si le serveur a déjà décidé d'un encodage, on n'intervient pas
	foreach (headers_list() as $h) {
		if (stripos($h, 'Content-Encoding:') === 0) {
			return;
		}
	}

	// Démarrer le buffer gzip
	ob_start('ob_gzhandler');
}, 1);

Повтарям: този код е полезен, когато сте заседнали, но най-добрият резултат идва от компресия на ниво сървър/CDN.

---

Конфигурация на сървъра

Този раздел е умишлено копиран и поставен. Зависи от вашия стек. Ако използвате Divi 5, Elementor или Avada : това не променя нищо, компресията е на ниво HTTP, а не на ниво конструктор.

Apache/LiteSpeed: .htaccess (Gzip + заглавки)

Вече имате основния блок в стъпка 1. Ето по-строг вариант, който добавя и правила, които предотвратяват премахването от прокси сървъри. Vary :

# === Gzip + Vary (Apache/LiteSpeed) ===
<IfModule mod_deflate.c>
	AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
	AddOutputFilterByType DEFLATE text/javascript application/javascript application/json
	AddOutputFilterByType DEFLATE image/svg+xml
</IfModule>

<IfModule mod_headers.c>
	# Vary est crucial pour CDN/cache navigateur
	Header merge Vary Accept-Encoding
</IfModule>

Nginx: Brotli/Gzip (примерна конфигурация)

Nginx не чете .htaccessНеобходима е конфигурация на сървъра. Ако използвате VPS, ето пример (който ще трябва да адаптирате). Ако използвате споделен хостинг, попитайте вашия доставчик на хостинг услуги.

# /etc/nginx/conf.d/compression.conf (exemple)
gzip on;
gzip_comp_level 6;
gzip_min_length 1024;
gzip_vary on;
gzip_proxied any;
gzip_types
  text/plain
  text/css
  text/xml
  application/json
  application/javascript
  application/xml
  application/rss+xml
  image/svg+xml;

# Brotli (nécessite module brotli)
brotli on;
brotli_comp_level 5;
brotli_types
  text/plain
  text/css
  text/xml
  application/json
  application/javascript
  application/xml
  application/rss+xml
  image/svg+xml;

CDN (напр. Cloudflare): Brotli от страната на периферията

Когато CDN обслужва Brotli, вашият източник (WordPress сървър) може да остане в Gzip и CDN ще оптимизира доставката. Това често е най-добрата комбинация: компресия + кеширане на ръбовете.

Важна забележка: ако използвате плъгин за кеширане и CDN, проверете това Vary: Accept-Encoding е наличен, в противен случай можете да предоставите компресирана версия на клиент, който не го приема (рядко през 2026 г., но се случва при някои ботове/инструменти).

PHP.ini / .user.ini: активирайте zlib (ако е разрешено)

При някои хостинг планове можете да активирате zlib чрез файл .user.ini (PHP-FPM):

; .user.ini (exemple)
zlib.output_compression = On
zlib.output_compression_level = 6

Ако правите това, избягвайте да го правите в wp-config.php (двойно активиране = странно поведение).

---

Проверка на резултатите

Не разчитайте на „Аз поставих фрагмента“. Проверете действителното поведение на HTTP и извършете измерване преди/след.

1) Проверете кодирането на съдържанието в HTML, CSS, JS

BASE="https://example.com"

# HTML
curl -I -H "Accept-Encoding: br,gzip" "$BASE/" | grep -i "content-encoding|vary|content-type"

# CSS (adaptez l'URL)
curl -I -H "Accept-Encoding: br,gzip" "$BASE/wp-includes/css/dist/block-library/style.min.css" | grep -i "content-encoding|content-type"

# JS (adaptez l'URL)
curl -I -H "Accept-Encoding: br,gzip" "$BASE/wp-includes/js/jquery/jquery.min.js" | grep -i "content-encoding|content-type"

2) Измерете усилването (предаден размер)

Този тест сравнява размера на изтегленото съдържание със и без прието кодиране. Не е перфектен (HTTP/2/3, кеш), но дава приблизителна представа.

URL="https://example.com/"

echo "== Sans compression demandée =="
curl -s -o /dev/null -H "Accept-Encoding: identity" 
  -w "size_download=%{size_download}n" "$URL"

echo "== Avec br,gzip =="
curl -s -o /dev/null -H "Accept-Encoding: br,gzip" 
  -w "size_download=%{size_download}n" "$URL"

3) Реалистични очаквания (какво трябва да видите)

• HTML/CSS/JS: често -60% до -85% на прехвърления размер.
• TTFB: понякога малко по-добре, понякога същото (компресията не ускорява генерирането на PHP).
• LCP мобилни устройства: често по-добри, защото е необходимо да се прехвърлят по-малко данни преди рендериране.

4) Изчистете кеша (в противен случай ще тествате по-стара версия)

След модификация:

• изчистете кеша на плъгина си (ако имате такъв),
• изчистете кеша на сървъра (LiteSpeed ​​​​Cache, Nginx cache, Varnish).
• изчистете кеша на CDN.
• Изпробвайте го в режим на частно сърфиране или с curl (което игнорира кеша на браузъра ви).

---

Ако производителността не се подобри

Ако можеш да виждаш ясно Content-Encoding: gzip (или brНо ако PageSpeed ​​​​остане лош, проблемът е другаде. Често съм виждал тези случаи:

1) Основната тежест идва от изображенията или шрифтовете

Компресията на текст не влияе на вашите JPEG/WebP/AVIF файлове. Ако страницата ви съдържа 6 MB изображения, Gzip няма да промени нищо. Бързо проверете:

# Liste les 30 ressources les plus lourdes (nécessite un outil type lighthouse/har + parsing)
# Ici, approche simple : récupérez la page et cherchez les images (indicatif seulement)
curl -s "https://example.com/" | grep -Eo 'src="[^"]+.(jpg|jpeg|png|webp|avif)[^"]*"' | head -n 30

2) Висок TTFB: Бавен PHP, бавна база данни, външни извиквания

Независимо дали е компресирана или не, ако генерирането на страницата ви отнема 1,5 секунди, значи имате проблем с back-end системата.

• Инсталирайте Query Monitor и потърсете бавни заявки.
• Regardez debug.log предупреждения/рекурсии/HTTP повиквания.
• Ако имате APM (New Relic, Datadog), използвайте го.

3) Прикритието ви крие реалността

Често срещан случай: вие модифицирате .htaccessОбратният прокси сървър обаче предоставя по-стар, некомпресиран отговор. Тествайте това, като добавите параметър „cache buster“:

curl -I -H "Accept-Encoding: br,gzip" "https://example.com/?nocache=$(date +%s)" | grep -i "content-encoding|age|x-cache|cf-cache-status"

4) „Заключено“ настаняване

Някои планове за споделен хостинг деактивират mod_deflateВ този случай:

• Заявете активиране от доставчика на хостинг услуги.
• Използвайте CDN, която компресира (Brotli).
• или използвайте PHP решението (с повишено внимание) от стъпка 3.

---

Често срещани капани и грешки

Ето грешките, които най-често срещам при настройването на Gzip/Brotli на WordPress (всички последни версии, включително 6.9.4).

симптом	Вероятна причина	проверка	Решение
Не Content-Encoding след добавяне на фрагмента	Nginx сървър (игнорира .htaccess) или mod_deflate инвалиди	curl -I + попитайте доставчика на хостинг услуги за стека	Конфигурирайте Nginx, активирайте mod_deflate или използвайте CDN/Brotli
Грешка 500 след промяна на .htaccess	Директивата не се поддържа / блокът не е правилно затворен	Apache/LiteSpeed ​​​​лог файлове, тествани чрез премахване на последния блок	Възстановете файла, постепенно го добавете отново и проверете. <IfModule>
CSS/JS „счупен“, грешка в декодирането	Двойна компресия (CDN + PHP + .htaccess)	Сравнете заглавките от страната на произхода с тези от CDN, търсене Content-Encoding	Запазете само едно ниво на компресия, изчистете всички кешове
Тестваш го, нищо не се променя	Кешът на браузъра/CDN предоставя стар отговор	Тествайте с curl + параметър ?nocache=	Изчистване на кеша на плъгина/сървъра/CDN, повторно тестване
„Заглавките вече са изпратени“ след добавяне към wp-config.php	Интервали/UTF-8 BOM преди <?php или преждевременно излизане от плъгин	PHP лог файлове, проверете началото на файла	Премахнете интервалите/BOM, избягвайте PHP компресията, предпочитайте сървъра
Компресията е ОК в HTML, но не и в CSS/JS	Неправилни MIME типове или файлове, обслужвани от различен vhost/CDN	curl -I на точния URL адрес на файла	Коригиране на MIME от страна на сървъра, проверка на CDN правилата, разширяване AddOutputFilterByType
Поставил си кода на грешното място	Фрагментът е поставен в functions.php вместо .htaccess	Корекция: mod_deflate няма място в PHP	Поставете инструкциите в .htaccess или конфигурация на сървъра

Две „глупави“, но истински бележки

• Забравяне на точка и запетая в wp-config.php Това нарушава работата на сайта. Направете резервно копие и използвайте редактор, който подчертава синтаксиса.
• Тестване в производство без предпазна мрежа: вече съм виждал една .htaccess Невалидно, изключете сайта от интернет. Най-малкото, направете копие на файла и запазете FTP/SSH достъп.

---

Съвети за поддръжка

• Проведете cURL тест в бележките си (или скрипт) и го изпълнявайте след всяка смяна на хостинг, CDN или кеш плъгин.
• Следете заглавките си Промяната на прокси сървър може да изтрие Vary или да наложите кодиране.
• Избягвайте „вълшебни откъси“ открити в стари статии: много от тях датират отпреди HTTP/2 да стане широко разпространен и добавят ненужни или рисковани директиви.
• Ако използвате Divi 5 / Elementor / Avada Компресията е независима от конструктора. Тези инструменти обаче често добавят много JS/CSS: компресията помага, но също така помислете за деактивиране на ненужните модули и оптимизиране на зареждането (defer/async) в отделен проект.
• След основна актуализация (WordPress, кеш, CDN), изпълнете друга проверка: Content-Encoding, Varyи мобилен тест.

---

ресурси

• Ресурси за разработчици на WordPress – Производителност (API и най-добри практики)
• Query Monitor (официален плъгин в WordPress.org)
• PHP.net – zlib конфигурация (zlib.output_compression)
• Developer.WordPress.org – wp-config.php (препратка)
• GitHub – Официално хранилище за WordPress и Develop (за проверка на поведението на ядрото)
• Developer.WordPress.org – WP-CLI команди

---

Често задавани въпроси

Gzip или Brotli: кой да изберем през 2026 г.?

Ако можете да активирате Brotli на ниво CDN/сървър, изберете Brotli. В противен случай използвайте Gzip чрез .htaccess остава солидна и до голяма степен съвместима оптимизация.

WordPress 6.9.4 има ли вградена настройка за Gzip?

Не. WordPress не „контролира“ HTTP компресията от страна на сървъра. В най-добрия случай може да предложи PHP решения, но стандартният подход е конфигурация на сървър/CDN.

Защо моят доставчик на хостинг услуги казва „Gzip е активиран“, но аз не виждам нищо?

Защото тествате различен ресурс (напр. компресирана HTML страница, но CSS файлове, обслужвани от поддомейн/CDN без компресия) или защото кешът обслужва стар отговор. Тествайте множество URL адреси (HTML + CSS + JS) с curl -I.

Трябва ли да активирам компресия за шрифтове (woff2)?

Като цяло, не. woff2 Вече е компресирано. Можете да го оставите в списъка без особена вреда, но ползата е минимална. Ако търсите прецизна оптимизация, фокусирайте се върху HTML/CSS/JS/JSON/SVG.

„Опасно“ ли е активирането на zlib в wp-config.php?

Това може да се случи, ако вече имате компресия нагоре по веригата (CDN/прокси) или ако изходите започват твърде рано (грешки в заглавките). Използвайте го само ако не можете да конфигурирате сървъра.

Поставих .htaccess кода във functions.php и сайтът ми все още не е по-бърз.

Това е нормално: functions.php се изпълнява от PHP, докато .htaccess конфигуриране на Apache/LiteSpeed. Указанията <IfModule mod_deflate.c> нямат ефект в PHP. Върнете ги обратно .htaccess.

Защо е необходимо да се използва „Vary: Accept-Encoding“?

Защото кешът (CDN, прокси, кеш на браузъра) трябва да съхранява варианти в зависимост от приетото кодиране. Без VaryКешът може да предостави gzip версия на клиент, който не я приема, или обратното.

Компресията подобрява ли TTFB?

Понякога малко, но това не е основната му цел. Основно намалява времето за трансфер и ускорява показването. Ако вашият TTFB е висок, проверете вместо това в PHP/DB/object cache/page cache.

Променят ли Elementor/Divi/Avada нещо по отношение на компресията?

Не. Те често увеличават количеството CSS/JS, така че компресията става още по-рентабилна, но активирането остава на ниво сървър/CDN.

Използвам HTTP/3 (QUIC). Компресията работи ли по същия начин?

Да. Brotli/Gzip остават HTTP кодировки за съдържание. Транспортирането (HTTP/2/3) не замества компресията на тялото на отговора.

Как мога да съм сигурен, че получавам Brotli, а не Gzip?

Сила Accept-Encoding: br и проверете Content-Encoding: br :

curl -I -H "Accept-Encoding: br" "https://example.com/" | grep -i "content-encoding"