Як налаштувати робочий .htaccess для прискорення сайту

Привіт:) Файл .htaccess — один із найважливіших конфігураційних файлів для сайтів, які працюють на Apache. За його допомогою можна керувати перенаправленнями, кешуванням, стисненням файлів, HTTP-заголовками та іншими параметрами роботи вебсервера.

Правильно налаштований .htaccess може допомогти зменшити обсяг переданих даних, скоротити кількість повторних завантажень статичних ресурсів і покращити швидкість завантаження сторінок.

Особливо корисним він може бути для WordPress-сайтів, де через один файл можна реалізувати частину оптимізацій без встановлення додаткового плагіна.

Але важливо розуміти: .htaccess сам по собі не зробить повільний сайт швидким. Він не замінює оптимізацію зображень, кешування сторінок, оптимізацію PHP, бази даних або якісний хостинг.

У цій статті розгляну практичний варіант .htaccess, який можна адаптувати для сучасного сайту на Apache.

🧩 Що таке .htaccess

.htaccess — це конфігураційний файл Apache, директиви якого застосовуються до каталогу, де він розташований, та його підкаталогів. Apache дозволяє використовувати такі файли для зміни конфігурації без редагування основного конфігураційного файлу сервера.

Для WordPress .htaccess зазвичай знаходиться в кореневій директорії сайту:

/public_html/.htaccess

або:

/www/.htaccess

Назва файлу починається з крапки, тому на деяких FTP-клієнтах або файлових менеджерах він може бути прихований.

⚠️ Важливо перед редагуванням

Перед внесенням змін:

1. Зробіть резервну копію .htaccess.
2. Не видаляйте існуючі правила WordPress.
3. Додавайте нові директиви поступово.
4. Після кожної зміни перевіряйте сайт.
5. Якщо з'явилася помилка 500 Internal Server Error, поверніть останню зміну.

Не всі директиви дозволені в .htaccess. Це залежить від налаштувань Apache, зокрема AllowOverride та AllowOverrideList.

🚀 Що можна оптимізувати через .htaccess

Для прискорення сайту найчастіше використовують .htaccess для таких завдань:

• стиснення текстових ресурсів;
• Brotli або GZIP-компресії;
• браузерного кешування;
• налаштування Cache-Control;
• встановлення термінів життя статичних ресурсів;
• оптимізації HTTP-заголовків;
• перенаправлення HTTP → HTTPS;
• canonical-редиректів;
• деяких правил для статичних файлів.

При цьому важливо розділяти кешування браузера і серверне кешування сторінок.

.htaccess може допомогти з HTTP-кешуванням ресурсів, але це не означає, що WordPress перестане генерувати PHP-сторінку при кожному запиті.

📦 Готовий базовий .htaccess для оптимізації

Нижче наведено приклад конфігурації, яку можна використовувати як основу.

# ========================================================== 
# SPEED OPTIMIZATION 
# ==========================================================

<IfModule mod_expires.c>
    ExpiresActive On 

    # Images
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/png "access plus 1 year"
    ExpiresByType image/gif "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType image/avif "access plus 1 year"
    ExpiresByType image/svg+xml "access plus 1 year"

    # Fonts
    ExpiresByType font/woff "access plus 1 year"
    ExpiresByType font/woff2 "access plus 1 year"
    ExpiresByType font/ttf "access plus 1 year"
    ExpiresByType font/otf "access plus 1 year"

    # CSS and JavaScript
    ExpiresByType text/css "access plus 1 year"
    ExpiresByType text/javascript "access plus 1 year"
    ExpiresByType application/javascript "access plus 1 year"

    # Documents
    ExpiresByType application/pdf "access plus 1 month"

    # HTML
    ExpiresByType text/html "access plus 0 seconds"
</IfModule>

# ========================================================== 
# CACHE-CONTROL 
# ==========================================================

<IfModule mod_headers.c>
    <FilesMatch "\.(css|js|jpg|jpeg|png|gif|webp|avif|svg|woff|woff2|ttf|otf)$">
        Header set Cache-Control "public, max-age=31536000, immutable" 
    </FilesMatch> 
</IfModule>

# ==========================================================
# COMPRESSION 
# ==========================================================

<IfModule mod_brotli.c>
    AddOutputFilterByType BROTLI_COMPRESS \ 
        text/plain \
        text/html \
        text/css \
        text/xml \
        application/xml \
        application/xhtml+xml \
        application/javascript \
        text/javascript \
        application/json \
        image/svg+xml 
</IfModule>

<IfModule mod_deflate.c> 
    AddOutputFilterByType DEFLATE \
        text/plain \
        text/html \
        text/css \
        text/xml \
        application/xml \
        application/xhtml+xml \
        application/javascript \
        text/javascript \
        application/json \
        image/svg+xml
</IfModule>

# ========================================================== 
# HTTPS 
# ==========================================================

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Важливо: цей код не варто копіювати в .htaccess без перевірки. Конкретні модулі та дозволені директиви залежать від конфігурації сервера. Наприклад, Brotli використовує mod_brotli, а класичне стиснення через DEFLATE — відповідні модулі Apache.

🗜️ Стиснення файлів: Brotli та GZIP

Одна з найкорисніших оптимізацій — зменшення розміру текстових ресурсів перед передаванням користувачу.

До таких ресурсів належать:

• HTML;
• CSS;
• JavaScript;
• XML;
• JSON;
• SVG.

Наприклад, HTML-документ розміром 200 КБ після стиснення може передаватися значно меншим обсягом.

Apache підтримує різні способи стиснення. mod_brotli реалізує компресію Brotli через фільтр BROTLI_COMPRESS, а AddOutputFilterByType дозволяє застосовувати фільтр до певних MIME-типів.

Приклад:

<IfModule mod_brotli.c>
    AddOutputFilterByType BROTLI_COMPRESS \
        text/html \
        text/css \
        application/javascript \
        application/json \
        image/svg+xml
 </IfModule>

Якщо Brotli недоступний, можна використовувати mod_deflate:

<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE \
        text/html \
        text/css \
        application/javascript \
        application/json \
        image/svg+xml
</IfModule>

Apache документує AddOutputFilterByType як спосіб застосування фільтра до відповіді залежно від її MIME-типу.

❗ Не стискайте вже стиснуті формати

Не потрібно застосовувати GZIP або Brotli до:

• JPG/JPEG;
• PNG;
• WebP;
• AVIF;
• MP4;
• ZIP;
• PDF у більшості сценаріїв.

Ці формати вже використовують власні алгоритми стиснення.

🧠 Чи потрібно використовувати Brotli та GZIP одночасно?

Не слід бездумно накладати два алгоритми стиснення на один і той самий ресурс.

Завдання конфігурації — дозволити серверу вибрати відповідний метод залежно від того, що підтримує браузер.

Якщо сервер і хостинг уже автоматично налаштовують Brotli або GZIP, не потрібно дублювати цю функцію в .htaccess.

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

Перед додаванням компресії варто перевірити заголовки відповіді:

Content-Encoding: br

або:

Content-Encoding: gzip

🗄️ Браузерне кешування статичних файлів

Одна з найкорисніших функцій .htaccess — встановлення терміну кешування статичних ресурсів.

Наприклад:

<IfModule mod_expires.c>
    ExpiresActive On

    ExpiresByType text/css "access plus 1 year"
    ExpiresByType application/javascript "access plus 1 year"

    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/png "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType image/avif "access plus 1 year"

    ExpiresByType font/woff2 "access plus 1 year"
</IfModule>

Модуль mod_expires керує заголовком Expires та директивою max-age заголовка Cache-Control. Це дозволяє браузеру використовувати локальну копію ресурсу протягом заданого періоду.

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

Наприклад:

style.css?ver=2.5

або:

style.abc123.css

Якщо URL ресурсу змінюється після оновлення, браузер завантажує нову версію замість використання старої копії.

⏱️ Чому HTML не варто кешувати на рік

Для HTML-сторінок зазвичай не варто встановлювати такий самий тривалий кеш, як для CSS, JavaScript або зображень.

Наприклад, небажано робити:

ExpiresByType text/html "access plus 1 year"

для динамічного WordPress-сайту.

Сторінка може змінитися, а користувач продовжить бачити стару версію з кешу.

Для HTML краще використовувати значно коротший термін або керувати кешуванням через систему page cache/CDN.

🧾 Cache-Control для статичних файлів

Окрім Expires, можна використовувати Cache-Control.

Наприклад:

<IfModule mod_headers.c>
    <FilesMatch "\.(css|js|jpg|jpeg|png|gif|webp|avif|svg|woff|woff2)$">
        Header set Cache-Control "public, max-age=31536000, immutable"
    </FilesMatch>
</IfModule>

31536000 — це приблизно один рік у секундах.

Директива Header належить до mod_headers і може використовуватися в .htaccess, якщо це дозволено конфігурацією Apache.

🔄 Що означає immutable

Параметр:

immutable

повідомляє клієнту, що ресурс не повинен змінюватися протягом терміну його кешування.

Тому його краще застосовувати до файлів, URL яких змінюється після оновлення.

Наприклад:

/app.73a91.css

або:

style.css?ver=73a91

А ось для:

style.css

без версії або fingerprinting довгий immutable може бути небажаним.

🔐 Примусове перенаправлення на HTTPS

Якщо сайт повністю працює через HTTPS, можна перенаправити HTTP-запити:

<IfModule mod_rewrite.c>
    RewriteEngine On

    RewriteCond %{HTTPS} !=on
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Це дозволяє уникати доступу до сайту через незахищений HTTP.

Але якщо HTTPS-редирект уже налаштований на рівні хостингу, CDN або основної конфігурації Apache, дублювати його в .htaccess не потрібно.

🧹 Не додавайте зайві RewriteRule

В інтернеті можна знайти величезну кількість "оптимізованих" .htaccess, які містять десятки або навіть сотні правил.

Це не означає, що сайт стане швидшим.

Кожне правило потрібно оцінювати окремо.

Наприклад, не варто додавати:

RewriteRule ...

лише тому, що воно присутнє в чужому конфігураційному файлі.

mod_rewrite насамперед потрібен для маршрутизації та перенаправлень, а не як універсальний інструмент прискорення сайту.

⚡ .htaccess і WordPress

У WordPress файл .htaccess часто містить стандартні правила:

# BEGIN WordPress

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Ці правила не потрібно видаляти заради оптимізації.

Вони забезпечують роботу стандартної системи URL WordPress.

Додаткові правила краще розміщувати окремо від блоку, який WordPress може перезаписати під час зміни структури постійних посилань.

🖼️ Кешуйте зображення правильно

Зображення часто становлять значну частину ваги сторінки.

Для них можна встановити тривалий кеш:

<IfModule mod_expires.c>
    ExpiresActive On

    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/png "access plus 1 year"
    ExpiresByType image/gif "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType image/avif "access plus 1 year"
    ExpiresByType image/svg+xml "access plus 1 year"
</IfModule>

Але важливо пам'ятати: кешування не зменшує розмір першого завантаження зображення.

Якщо файл важить 2 МБ, .htaccess не перетворить його на 200 КБ.

Для цього потрібно:

• правильно підібрати роздільну здатність;
• використовувати WebP або AVIF;
• оптимізувати JPEG/PNG;
• використовувати responsive images;
• застосовувати lazy loading там, де це доречно.

🔤 Кешування шрифтів

Вебшрифти також можна кешувати тривалий час:

<IfModule mod_expires.c>

    ExpiresActive On

    ExpiresByType font/woff "access plus 1 year"
    ExpiresByType font/woff2 "access plus 1 year"
    ExpiresByType font/ttf "access plus 1 year"
    ExpiresByType font/otf "access plus 1 year"

</IfModule>

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

Водночас краще не підключати десятки накреслень, які фактично не використовуються.

🧪 Як перевірити, чи працює .htaccess

Після зміни конфігурації недостатньо просто відкрити головну сторінку.

Перевірте:

1. HTTP-код відповіді

Сторінка повинна повертати:

200 OK

а не:

500 Internal Server Error

2. Стиснення

У заголовках відповіді перевірте:

Content-Encoding: br

або:

Content-Encoding: gzip

3. Кешування

Перевірте:

Cache-Control

та:

Expires

4. HTTPS

Запит:

http://example.com

має перенаправляти на:

https://example.com

5. WordPress

Перевірте:

• головну сторінку;
• записи;
• сторінки;
• категорії;
• пошук;
• форми;
• авторизацію;
• адміністративну частину.

🚨 Що робити, якщо сайт показує помилку 500

Найчастіша помилка після редагування .htaccess — неправильна синтаксична конструкція або використання директиви, яка недоступна на конкретному сервері.

Перший крок — повернути резервну копію.

Якщо резервної копії немає, тимчасово перейменуйте:

.htaccess

наприклад у:

.htaccess-disabled

Якщо після цього сайт знову працює, проблема майже напевно пов'язана з правилами .htaccess.

Після цього додавайте зміни поступово.

Не потрібно одразу вставляти 200 рядків готового конфігураційного файлу з інтернету.

🛡️ Чому не варто копіювати чужий .htaccess

Конфігурація одного сервера може не працювати на іншому.

Причини:

• різні версії Apache;
• відсутність певних модулів;
• інші параметри AllowOverride;
• інша конфігурація PHP;
• використання CDN;
• налаштування хостингу;
• Nginx замість Apache;
• використання LiteSpeed;
• уже активоване стиснення;
• уже налаштоване кешування.

Apache прямо зазначає, що можливість використання директив у .htaccess залежить від конфігурації сервера та AllowOverride.

🧩 .htaccess не замінює серверну оптимізацію

Це одна з найважливіших речей, яку потрібно розуміти.

Якщо сайт повільний через:

• повільний PHP;
• велику кількість плагінів;
• неоптимізований SQL;
• важку тему;
• сторонні JavaScript-скрипти;
• великі зображення;
• відсутність page cache;
• повільний сервер;

додавання кількох правил до .htaccess не вирішить проблему.

Більше того, Apache зазначає, що .htaccess перевіряється при обробці запитів, а пошук таких файлів у директоріях створює додаткову роботу сервера.

Тому якщо є доступ до основної конфігурації Apache, частину правил доцільніше налаштовувати там, а не через .htaccess.

⚙️ Оптимальний підхід до .htaccess

Для більшості WordPress-сайтів достатньо дотримуватися простої схеми:

1. Зберегти стандартні правила WordPress

Не видаляйте блок:

# BEGIN WordPress
...
# END WordPress

2. Увімкнути компресію

Використовуйте Brotli або GZIP — залежно від того, що підтримує сервер.

3. Налаштувати кеш статичних файлів

Для CSS, JavaScript, зображень та шрифтів можна встановлювати тривале кешування.

4. Не кешувати динамічний HTML на рік

Для WordPress краще використовувати спеціалізований page cache, якщо потрібне повноцінне кешування HTML.

5. Не дублювати функції

Якщо хостинг уже забезпечує Brotli, HTTPS, кешування або редиректи, не потрібно створювати другу реалізацію тих самих правил.

6. Тестувати кожну зміну

.htaccess — не те місце, де варто експериментувати без резервної копії.

📋 Приклад компактного робочого .htaccess

Якщо потрібна саме мінімалістична конфігурація без десятків сумнівних правил, можна почати з такого варіанта:

# ==========================================================
# WordPress
# ==========================================================

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /

    RewriteRule ^index\.php$ - [L]

    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
</IfModule>


# ==========================================================
# Browser Cache
# ==========================================================

<IfModule mod_expires.c>
    ExpiresActive On

    ExpiresByType text/css "access plus 1 year"
    ExpiresByType application/javascript "access plus 1 year"

    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/png "access plus 1 year"
    ExpiresByType image/gif "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType image/avif "access plus 1 year"
    ExpiresByType image/svg+xml "access plus 1 year"

    ExpiresByType font/woff "access plus 1 year"
    ExpiresByType font/woff2 "access plus 1 year"

    ExpiresByType text/html "access plus 0 seconds"
</IfModule>


# ==========================================================
# Cache-Control
# ==========================================================

<IfModule mod_headers.c>
    <FilesMatch "\.(css|js|jpg|jpeg|png|gif|webp|avif|svg|woff|woff2)$">
        Header set Cache-Control "public, max-age=31536000, immutable"
    </FilesMatch>
</IfModule>


# ==========================================================
# Brotli
# ==========================================================

<IfModule mod_brotli.c>
    AddOutputFilterByType BROTLI_COMPRESS \
        text/html \
        text/plain \
        text/css \
        text/xml \
        application/xml \
        application/javascript \
        application/json \
        image/svg+xml
</IfModule>

Цей приклад потрібно адаптувати під конкретний сервер. Зокрема, не слід одночасно додавати Brotli та GZIP лише "для надійності", якщо сервер уже сам керує вибором алгоритму.

🔍 Як зрозуміти, чи .htaccess реально прискорив сайт

Порівнювати потрібно не тільки оцінку Lighthouse або PageSpeed.

До і після внесення змін варто перевірити:

• TTFB;
• розмір HTML;
• розмір CSS;
• розмір JavaScript;
• кількість HTTP-запитів;
• Content-Encoding;
• Cache-Control;
• Expires;
• час завантаження статичних ресурсів.

Особливо важливо перевірити перший і повторний візит.

Якщо після повторного відкриття сторінки CSS, JS, шрифти та зображення завантажуються з браузерного кешу, це означає, що налаштування кешування працює.

❓ Часті запитання

🎯 Висновок

Правильно налаштований .htaccess — це корисний інструмент оптимізації сайту на Apache, але не універсальний засіб прискорення.

Найбільшу практичну користь зазвичай дають:

• Brotli/GZIP для текстових ресурсів;
• довгий браузерний кеш для статичних файлів;
• правильний Cache-Control;
• коректна робота HTTPS;
• відсутність зайвих rewrite-правил;
• версіонування CSS і JavaScript;
• оптимізовані зображення;
• page cache на рівні WordPress, сервера або CDN.

Головне правило — не копіювати величезний .htaccess з інтернету без перевірки. Хороший конфігураційний файл — це не той, у якому найбільше директив, а той, у якому є лише потрібні правила, сумісні з конкретною конфігурацією сервера.

Для сучасного Apache це особливо актуально: .htaccess залишається зручним механізмом локальної конфігурації, але Apache рекомендує централізовану конфігурацію там, де є відповідний доступ, оскільки .htaccess обробляється під час запитів.