Szybkość ładowania strony zależy od wielu czynników – od jakości hostingu i wydajności aplikacji, przez optymalizację bazy danych, aż po sposób dostarczania obrazów, arkuszy CSS i skryptów JavaScript. W przypadku serwerów Apache część optymalizacji można przeprowadzić również za pomocą pliku .htaccess.
Odpowiednio skonfigurowany .htaccess pozwala między innymi włączyć kompresję przesyłanych danych, ustawić pamięć podręczną przeglądarki, ograniczyć zbędne przekierowania oraz odpowiednio skonfigurować nagłówki HTTP.
Nie oznacza to jednak, że im więcej dyrektyw umieścimy w .htaccess, tym szybsza będzie strona. Niektóre ustawienia mogą być niedostępne na hostingu współdzielonym, inne powinny znajdować się w głównej konfiguracji Apache, a część popularnych porad dotyczących optymalizacji .htaccess jest już przestarzała.
Dlatego każdą zmianę należy wdrażać świadomie i sprawdzać jej rzeczywisty wpływ na wydajność witryny.
1. Kompresja GZIP za pomocą mod_deflate
Jedną z podstawowych metod ograniczenia ilości danych przesyłanych pomiędzy serwerem a przeglądarką jest kompresja.
W Apache można wykorzystać moduł mod_deflate:
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/json
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE image/svg+xml
</IfModule>
Kompresowanie HTML, CSS, JavaScript, JSON, XML czy SVG może znacząco ograniczyć ilość przesyłanych danych.
Nie ma natomiast większego sensu ponownie kompresować formatów, które już wykorzystują własną kompresję, takich jak JPEG, PNG, WebP, AVIF, ZIP czy większość materiałów wideo.
2. Kompresja Brotli
Jeżeli serwer obsługuje mod_brotli, można wykorzystać kompresję Brotli:
<IfModule mod_brotli.c>
AddOutputFilterByType BROTLI_COMPRESS text/html
AddOutputFilterByType BROTLI_COMPRESS text/plain
AddOutputFilterByType BROTLI_COMPRESS text/css
AddOutputFilterByType BROTLI_COMPRESS application/javascript
AddOutputFilterByType BROTLI_COMPRESS application/json
AddOutputFilterByType BROTLI_COMPRESS application/xml
AddOutputFilterByType BROTLI_COMPRESS image/svg+xml
</IfModule>
Brotli może zapewnić bardzo dobrą kompresję zasobów tekstowych i jest obsługiwany przez współczesne przeglądarki.
Możliwość jego zastosowania zależy jednak od konfiguracji serwera. Na hostingu współdzielonym moduł może nie być dostępny.
3. Cache przeglądarki za pomocą mod_expires
Przeglądarka nie musi pobierać tych samych zasobów przy każdej kolejnej wizycie użytkownika.
Za pomocą mod_expires można określić, jak długo wybrane typy plików powinny pozostawać w pamięci podręcznej:
<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"
ExpiresByType font/woff2 "access plus 1 year"
ExpiresByType text/css "access plus 1 year"
ExpiresByType application/javascript "access plus 1 year"
ExpiresByType text/html "access plus 0 seconds"
</IfModule>
Długie okresy cache są szczególnie korzystne dla zasobów statycznych.
Jest jednak jeden ważny warunek: pliki CSS, JavaScript, obrazy czy fonty przechowywane przez rok powinny posiadać mechanizm wersjonowania nazw lub adresów URL.
Przykładowo po zmianie:
style.css
możemy wygenerować:
style.a82f91.css
Dzięki temu przeglądarka rozpozna nowy plik i pobierze aktualną wersję zamiast korzystać ze starego zasobu znajdującego się w cache.
4. Cache-Control dla zasobów statycznych
Oprócz Expires warto odpowiednio skonfigurować Cache-Control.
Przykład dla wersjonowanych zasobów statycznych:
<IfModule mod_headers.c>
<FilesMatch "\.(css|js|jpg|jpeg|png|gif|webp|avif|svg|ico|woff|woff2)$">
Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>
</IfModule>
Dyrektywa immutable informuje przeglądarkę, że dany zasób nie zmieni się w okresie ważności cache.
Z tego powodu należy ją stosować przede wszystkim wtedy, gdy aplikacja korzysta z wersjonowanych nazw plików.
5. Cache dla dokumentów HTML
Dokumenty HTML wymagają innego podejścia niż obrazy, fonty czy wersjonowane pliki CSS.
Przykładowo:
<IfModule mod_headers.c>
<FilesMatch "\.(html|htm)$">
Header set Cache-Control "no-cache"
</FilesMatch>
</IfModule>
no-cache nie oznacza całkowitego zakazu przechowywania odpowiedzi. Informuje klienta, że przed ponownym wykorzystaniem zapisanej kopii powinien sprawdzić jej aktualność.
W przypadku dynamicznych stron sposób cache’owania HTML powinien być dostosowany do działania aplikacji, CMS-a oraz ewentualnej warstwy cache.
6. ETag – usuwać czy pozostawić?
W starszych poradnikach dotyczących optymalizacji Apache często można znaleźć:
FileETag None
Header unset ETag
Historycznie wyłączenie ETagów mogło mieć sens w niektórych konfiguracjach wieloserwerowych. Nie oznacza to jednak, że ETag jest z definicji szkodliwy dla wydajności.
ETag służy do sprawdzania, czy zasób znajdujący się w pamięci podręcznej nadal jest aktualny. Może więc być przydatnym elementem mechanizmu cache.
Zamiast automatycznie go wyłączać, warto najpierw sprawdzić sposób generowania ETagów oraz konfigurację infrastruktury.
7. Ograniczenie zbędnych przekierowań
Każde przekierowanie oznacza dodatkowe żądanie HTTP, dlatego warto unikać ich niepotrzebnych łańcuchów.
Przykładowo zamiast:
http://www.example.com
→ http://example.com
→ https://example.com
lepiej od razu kierować użytkownika do adresu docelowego:
http://www.example.com
→ https://example.com
Przykładowa konfiguracja może wyglądać następująco:
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]
Regułę trzeba oczywiście dostosować do wybranej wersji domeny i konfiguracji HTTPS.
W przypadku korzystania z CDN, reverse proxy lub load balancera sposób wykrywania HTTPS może być inny.
8. Wyłączenie listowania katalogów
Można również wyłączyć automatyczne generowanie listy zawartości katalogów:
Options -Indexes
Jest to przede wszystkim ustawienie związane z bezpieczeństwem. Może również zapobiec niepotrzebnemu generowaniu przez Apache stron zawierających listę plików.
Nie należy jednak oczekiwać, że samo Options -Indexes zauważalnie poprawi wynik Core Web Vitals czy czas ładowania standardowej podstrony.
9. Vary: Accept-Encoding
Podczas korzystania z kompresji istotny jest nagłówek:
Vary: Accept-Encoding
Informuje on mechanizmy cache, że odpowiedź może różnić się w zależności od obsługiwanej przez klienta metody kodowania.
W większości poprawnych konfiguracji mod_deflate lub mod_brotli odpowiedni nagłówek jest obsługiwany automatycznie.
Nie ma więc potrzeby bezrefleksyjnego dodawania go ręcznie do każdej odpowiedzi.
10. Ograniczenie kompresji już skompresowanych formatów
Kompresowanie JPEG, PNG, WebP, AVIF, MP4 czy ZIP za pomocą GZIP zazwyczaj nie przynosi korzyści.
Jeżeli jest to konieczne ze względu na konkretną konfigurację serwera, można wykluczyć wybrane rozszerzenia:
<IfModule mod_setenvif.c>
SetEnvIfNoCase Request_URI "\.(?:gif|jpe?g|png|webp|avif|zip|gz|mp4|mp3|pdf)$" no-gzip
</IfModule>
Najczęściej jednak wystarczy skonfigurować kompresję wyłącznie dla odpowiednich typów MIME.
11. LimitRequestBody
Można również ograniczyć maksymalny rozmiar danych przesyłanych w żądaniu:
LimitRequestBody 10485760
W tym przykładzie limit wynosi 10 MB.
Nie jest to typowa optymalizacja szybkości ładowania strony, ale może pomóc ograniczyć zużycie zasobów związane z niepotrzebnie dużymi żądaniami.
Wartość trzeba dostosować do funkcjonalności witryny. Zbyt niski limit może uniemożliwić użytkownikom przesyłanie prawidłowych plików.
12. Blokowanie agresywnych botów
Boty generujące dużą liczbę zapytań mogą obciążać serwer i pośrednio wpływać na szybkość działania strony dla prawdziwych użytkowników.
Możliwe jest blokowanie wybranych User-Agentów:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (BadBot|EvilScraper) [NC]
RewriteRule ^ - [F,L]
</IfModule>
Trzeba jednak pamiętać, że User-Agent można łatwo zmienić.
Przy większej skali ruchu lepszym rozwiązaniem będzie zastosowanie WAF, CDN, reverse proxy lub systemu rate limiting działającego przed Apache.
13. Czy .htaccess może włączyć HTTP/2?
Często spotykana porada sugeruje dodanie:
Protocols h2 http/1.1
do .htaccess.
Nie jest to jednak właściwe miejsce do konfigurowania protokołów serwera.
Obsługę HTTP/2, podobnie jak HTTP/3, konfiguruje się na poziomie infrastruktury, serwera WWW, VirtualHosta, reverse proxy lub CDN.
W przypadku hostingu współdzielonego HTTP/2 jest zazwyczaj włączane przez administratora hostingu i użytkownik nie musi wykonywać żadnych zmian w .htaccess.
14. KeepAlive – ważny, ale nie w .htaccess
Keep-Alive pozwala wykorzystać jedno połączenie do obsługi większej liczby żądań.
W starszych poradnikach można spotkać próby jego wymuszania za pomocą:
Header set Connection keep-alive
Nie jest to właściwy sposób konfigurowania Keep-Alive.
Ustawienia takie jak:
KeepAlive
MaxKeepAliveRequests
KeepAliveTimeout
należą do konfiguracji serwera Apache, a nie do standardowych optymalizacji wykonywanych za pomocą .htaccess.
Dodatkowo w przypadku HTTP/2 mechanizm obsługi połączeń wygląda inaczej niż w klasycznym HTTP/1.1.
15. Preload i prefetch – nie za pomocą kodu HTML w .htaccess
Nie można umieścić w .htaccess kodu HTML:
<link rel="dns-prefetch" href="//example.com">
Taki zapis powinien znaleźć się w dokumencie HTML.
.htaccess może natomiast w określonych przypadkach ustawić nagłówek Link, np.:
<IfModule mod_headers.c>
Header add Link "</fonts/main.woff2>; rel=preload; as=font; type=font/woff2; crossorigin"
</IfModule>
Preload należy jednak stosować bardzo selektywnie.
Wstępne pobieranie zbyt wielu zasobów może przynieść efekt odwrotny do zamierzonego i konkurować o przepustowość z zasobami rzeczywiście potrzebnymi do pierwszego renderowania strony.
16. Async i defer nie są ustawieniami .htaccess
Atrybuty:
<script src="script.js" async></script>
oraz:
<script src="script.js" defer></script>
są elementami kodu HTML, a nie konfiguracji Apache.
Nie powinny więc znajdować się w poradniku jako dyrektywy .htaccess.
Odpowiednie wykorzystanie async, defer, modułów JavaScript oraz właściwej kolejności ładowania zasobów może znacząco poprawić wydajność strony, ale powinno być realizowane na poziomie kodu aplikacji.
17. Minifikacja CSS i JavaScript
Podobnie wygląda kwestia minifikacji.
Reguła przekierowująca:
style.css → style.min.css
nie minifikuje automatycznie kodu.
Minifikację najlepiej wykonywać na etapie budowania aplikacji lub za pomocą narzędzia optymalizacyjnego, CMS-a albo CDN.
Dzięki temu można rzeczywiście usunąć zbędne spacje, komentarze i inne elementy zwiększające rozmiar pliku.
18. Nie usuwaj globalnie nagłówka Set-Cookie
Nie należy stosować jako uniwersalnej optymalizacji:
Header unset Set-Cookie
Usunięcie Set-Cookie może uszkodzić sesje użytkowników, logowanie, koszyk zakupowy, personalizację oraz inne funkcje aplikacji.
Jeżeli zasoby statyczne nie powinny wykorzystywać cookies, najlepiej odpowiednio zaprojektować architekturę aplikacji lub sposób ich dostarczania, zamiast globalnie usuwać nagłówek.
19. CORS nie przyspiesza strony
Nagłówek:
Access-Control-Allow-Origin
służy do kontrolowania dostępu do zasobów pomiędzy różnymi originami.
CORS jest mechanizmem bezpieczeństwa i kontroli dostępu, a nie techniką przyspieszającą stronę.
Nie należy więc włączać:
Header set Access-Control-Allow-Origin "*"
wyłącznie w celu poprawy wydajności.
CORS powinien być skonfigurowany tylko wtedy, gdy rzeczywiście wymaga tego sposób udostępniania zasobów.
20. HTTP/2 Server Push – rozwiązanie historyczne
W starszych konfiguracjach Apache można spotkać:
H2PushResource /css/styles.css
HTTP/2 Server Push był kiedyś przedstawiany jako sposób na przyspieszenie dostarczania krytycznych zasobów.
Obecnie nie należy budować strategii wydajnościowej witryny w oparciu o Server Push. Współczesne przeglądarki i infrastruktura internetowa odeszły od praktycznego wykorzystania tego mechanizmu.
Zamiast tego warto skupić się na odpowiednim cache, preloadzie używanym z umiarem oraz optymalizacji kolejności ładowania zasobów.
21. Konfiguracja MPM nie należy do .htaccess
Apache może korzystać z różnych modułów MPM, takich jak:
mpm_prefork,mpm_worker,mpm_event.
Ich odpowiednia konfiguracja może mieć bardzo duży wpływ na wydajność serwera.
Parametry takie jak:
StartServers
ThreadsPerChild
MaxRequestWorkers
MaxConnectionsPerChild
nie są jednak ustawieniami, które standardowo konfiguruje się w .htaccess.
Powinny być zarządzane na poziomie konfiguracji Apache przez administratora serwera.
22. Timeout i ProxyTimeout
Podobna zasada dotyczy ustawień:
Timeout
ProxyTimeout
Mogą mieć znaczenie dla sposobu wykorzystania zasobów serwera, ale należą do konfiguracji Apache lub odpowiednich VirtualHostów.
Nie należy przedstawiać ich jako uniwersalnych dyrektyw optymalizacyjnych do wklejenia do .htaccess.
Samo zmniejszenie timeoutu również nie sprawi automatycznie, że strona zacznie szybciej odpowiadać.
23. FastCGI i PHP-FPM
Sposób komunikacji Apache z PHP-FPM może mieć ogromny wpływ na wydajność witryny.
Konfiguracje wykorzystujące między innymi:
mod_proxy_fcgi
PHP-FPM
FastCGI
powinny być jednak przygotowywane na poziomie konfiguracji serwera.
W przypadku WordPressa czy innych aplikacji PHP znacznie większe znaczenie dla szybkości mogą mieć odpowiednio skonfigurowany PHP-FPM, OPcache oraz cache aplikacyjny niż rozbudowywanie .htaccess.
24. Limitowanie liczby połączeń i rate limiting
Ograniczenie agresywnego ruchu może poprawić stabilność serwera pod dużym obciążeniem.
Nie należy jednak traktować przypadkowych wartości w rodzaju:
MaxConnPerIP 10
jako uniwersalnej konfiguracji wydajnościowej.
Współczesne strony wykonują wiele równoległych operacji, a dodatkowo wielu użytkowników może korzystać z tego samego publicznego adresu IP.
Rate limiting najlepiej konfigurować na podstawie rzeczywistego charakteru ruchu i – jeśli to możliwe – na wcześniejszej warstwie infrastruktury.
25. ModSecurity a wydajność
ModSecurity jest przede wszystkim rozwiązaniem związanym z bezpieczeństwem aplikacji internetowych.
Nie należy wyłączać istotnych elementów kontroli bezpieczeństwa wyłącznie po to, aby potencjalnie zmniejszyć obciążenie serwera.
Przykładowo wyłączenie analizy treści żądań POST może ograniczyć możliwości wykrywania niektórych ataków.
Jeżeli ModSecurity powoduje problemy wydajnościowe, lepszym rozwiązaniem jest optymalizacja zestawu reguł oraz analiza logów niż globalne wyłączanie mechanizmów ochronnych.
26. Logi serwera – nie wyłączaj ich tylko dla wydajności
Konfiguracje typu:
CustomLog /dev/null common
nie powinny być traktowane jako standardowa metoda przyspieszania strony.
Logi są niezwykle istotne podczas diagnostyki błędów, analizowania ruchu, wykrywania ataków oraz rozwiązywania problemów z serwerem.
W środowiskach generujących bardzo duże ilości danych można zoptymalizować sposób zapisywania, rotacji i przechowywania logów, ale całkowite ich wyłączenie zazwyczaj nie jest dobrym rozwiązaniem.
27. Co naprawdę warto umieścić w .htaccess?
Jeżeli celem jest poprawa szybkości typowej strony działającej na Apache, lista rzeczywiście przydatnych ustawień jest znacznie krótsza, niż sugeruje wiele poradników.
Najczęściej warto zainteresować się przede wszystkim:
- kompresją Brotli lub GZIP,
- odpowiednimi nagłówkami
Cache-Control, mod_expires,- długim cache dla wersjonowanych zasobów statycznych,
- ograniczeniem zbędnych przekierowań,
- prawidłową obsługą HTTPS,
- ewentualnym ograniczeniem ruchu generowanego przez agresywne boty.
Pozostałe elementy optymalizacji powinny być realizowane na odpowiedniej warstwie technologicznej.
.htaccess to tylko jeden z elementów optymalizacji
Plik .htaccess może pomóc poprawić sposób dostarczania zasobów, ale nie jest uniwersalnym narzędziem do przyspieszania strony internetowej.
Jeżeli witryna działa wolno z powodu długiego czasu generowania dokumentu HTML, nieoptymalnych zapytań SQL, ciężkich wtyczek WordPressa czy przeciążonego hostingu, dodanie kolejnych kilkudziesięciu reguł do .htaccess nie rozwiąże problemu.
W praktyce największe korzyści wydajnościowe często przynoszą:
- cache strony i aplikacji,
- cache obiektowy,
- PHP OPcache,
- optymalizacja bazy danych,
- ograniczenie liczby ciężkich zapytań,
- optymalizacja obrazów,
- wykorzystanie formatów WebP i AVIF,
- odpowiednie wymiary obrazów,
- lazy loading,
- ograniczenie ilości JavaScript,
- usunięcie nieużywanego CSS i JS,
- optymalizacja fontów,
- CDN,
- szybki hosting,
- prawidłowo skonfigurowany PHP-FPM,
- HTTP/2 lub HTTP/3,
- ograniczenie liczby zewnętrznych skryptów.
Dlatego zamiast kopiować ogromny zestaw „optymalizacyjnych” dyrektyw .htaccess, najlepiej najpierw zmierzyć wydajność witryny i znaleźć rzeczywiste wąskie gardło.
Dopiero wtedy można zdecydować, czy problem znajduje się w konfiguracji Apache, aplikacji, bazie danych, frontendzie, hostingu czy sposobie dostarczania zasobów.
Czy duży plik .htaccess może spowolnić stronę?
Warto zwrócić uwagę również na sam sposób działania .htaccess.
Apache musi odczytywać i interpretować konfigurację .htaccess podczas obsługi żądań. Rozbudowany plik zawierający dziesiątki skomplikowanych wyrażeń regularnych i reguł mod_rewrite może więc powodować dodatkowe obciążenie.
Jeżeli administrator posiada pełny dostęp do konfiguracji serwera, Apache zaleca przenoszenie ustawień do głównej konfiguracji zamiast korzystania z .htaccess, gdy jest to możliwe.
Na hostingu współdzielonym użytkownik zazwyczaj nie ma jednak takiego dostępu, dlatego .htaccess pozostaje wygodnym sposobem zarządzania wybranymi ustawieniami witryny.
Najważniejsza zasada jest więc prosta: używaj tylko tych dyrektyw, których rzeczywiście potrzebuje Twoja strona.
Przed każdą zmianą wykonaj kopię pliku .htaccess, wprowadzaj modyfikacje pojedynczo i sprawdzaj działanie witryny po ich wdrożeniu. Błędna lub niedozwolona dyrektywa może doprowadzić między innymi do pojawienia się błędu 500 Internal Server Error.
Optymalizacja powinna opierać się na pomiarach, a nie na liczbie reguł znajdujących się w pliku konfiguracyjnym.