Jak zoptymalizować WordPress’a

WordPress ma opinię skryptu który obciąża serwery. Jeżeli blog ma zaledwie kilka odwiedzin dziennie to nie ma problemu. Gorzej jest gdy ilość odwiedzin jest już liczona w setkach czy tysiącach – wtedy optymalizacja WordPress’a jest już koniecznością.

Do wyboru jest kilka różnych metod – cache obiektów wbudowane w WordPress’a, pluginy cache’ujące i odpowiednie mechanizmy serwera, konfigurowane poprzez plik .htaccess.

Pierwszym mechanizmem jest cache obiektów wbudowane w WordPress’a. Służy ono  do przechowywania wyników zapytań SQL. Warto go włączyć aby odciążyć bazę danych. W tym celu należy do pliku wp-config.php dodać poniższą linijkę. Linijkę tę warto dodać gdzieś na początku tego pliku.

define('WP_CACHE', true);

Jeżeli chcesz zobaczyć statystyki wykorzystania object cache, to polecam zainstalować plugin WP Cache Inspect. Po włączeniu opcji „Data in Frontend” na stronach loga będzie wyświetlać się okienko ze statystykami. Polecam na czas testów wyłączyć też pluginy typu WP Super Cache, aby mieć pewność że zobaczysz te statystyki.

Drugą opcją są pluginy cache’ujące. Jednym z nich jest DB Cache DB Cache Reloaded. Pierwszy z nich służy do cache’owania wyników zapytań do bazy danych. Ponieważ nie wszystkie zapytania przechodzą przez wspomniany wcześniej object cache, warto go też zainstalować. Po instalacji trzeba go dodatkowo włączyć na stronie jego konfiguracji.

Drugim pluginem jest WP Super Cache. Plugin ten zapisuje wygenerowane strony na dysku. Dzięki temu przy kolejnych odwołaniach do serwera mogą one zostać użyte – serwowanie statycznych plików jest o wiele mniej kosztowne niż ich ponowne generowanie.

Po instalacji tego pluginu trzeba go włączyć na stronie jego konfiguracji, podobnie jak DB Cache. Aby w pełni wykorzystać jego możliwości, musisz jeszcze dodać odpowiednie wpisy do dwóch plików .htaccess: do tego umieszczonego w katalogu głównym (wpisy muszą być dodane powyżej tych dodanych przez WordPress’a), oraz do pliku /wp-content/cache/.htaccess. Reguły te znajdziesz na stronie konfiguracji pluginu WP Super Cache (aby je zobaczyć, musisz najpierw włączyć plugin).

Ostatnią metodą optymalizacji jest wykorzystanie możliwości jakie daje cache przeglądarek (trzeba wysłać odpowiednie nagłówki do przeglądarki), oraz użycie kompresji gzip dla statycznych plików tekstowych (m.in. skrypty i style css) – dzięki temu można ograniczyć generowany transfer. Aby to zrobić, należy dodać do pliku .htaccess poniższe linijki. Możesz je dodać na jego końcu:

FileETag none

<IfModule mod_deflate.c>
# Insert filters
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/atom+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE application/x-httpd-fastphp
AddOutputFilterByType DEFLATE application/x-httpd-php-source
AddOutputFilterByType DEFLATE image/svg+xml

<IfModule mod_setenvif.c>
# Drop problematic browsers
# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html
# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip
# MSIE masquerades as Netscape, but it is fine
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

# Don't compress images
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary

# Make sure proxies don't deliver the wrong content
<IfModule mod_headers.c>
Header append Vary User-Agent env=!dont-vary
</IfModule>
</IfModule>
</IfModule>

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/html A1
ExpiresByType application/xhtml+xml A1
# Add Expire header set to 30 days (far future)
ExpiresByType text/css A2592000
ExpiresByType text/javascript A2592000
ExpiresByType application/javascript A2592000
ExpiresByType application/x-javascript A2592000
ExpiresByType image/gif A2592000
ExpiresByType image/png A2592000
ExpiresByType image/jpg A2592000
ExpiresByType image/jpeg A2592000
ExpiresByType image/x-icon A2592000
ExpiresByType image/vnd.microsoft.icon A2592000
ExpiresByType image/svg+xml A2592000
ExpiresByType text/plain A2592000
# Add Expire header set to 1 day
ExpiresByType text/xml A108000
ExpiresByType application/x-httpd-php A108000
ExpiresByType application/x-httpd-fastphp A108000
ExpiresByType application/x-httpd-php-source A108000
# Add Expire header set to 1 hour
ExpiresByType application/xml A108000
ExpiresByType application/atom+xml A108000
ExpiresByType application/rss+xml A108000
</IfModule>

# Fallback - when there is no mod_expires, try to add far future expire headers using mod_headers
<IfModule !mod_expires.c>
<IfModule mod_headers.c>
<Files ~ "\.(gif|jpe?g|png|css|ico|js)$">
Header set Expires "Thu, 15 Apr 2020 20:00:00 GMT"
</Files>
</IfModule>
</IfModule>

Powyższe wpisy do .htaccess powstały w wyniku moich analiz stron internetowych dokonanych za pomocą pluginów YSlow i Page Speed do FireFox’a. Polecam je zainstalować i przeanalizować analizy stron za ich pomocą. Szczególnie polecam ten drugi – w trakcie analizy wykonuje on także optymalizację obrazków i skryptów, tak aby szybciej się ładowały.

Poza wymienionymi powyżej metodami można jeszcze skorzystać z możliwości optymalizacji konfiguracji serwerów WWW i baz danych. Wymaga do jednak dostępu do konfiguracji serwera, trzeba więc mieć coś więcej niż hosting współdzielony. Zainteresowanych odsyłam do Google – zapytanie wordpress performance zwraca wiele artykułów które poruszają m.in ten temat.

Update 12.08.2009: przez przypadek zauważyłem że po włączeniu DB Cache nie można dodawać tagów do wpisów. Zgłosiłem ten błąd autorowi pluginu. Do momentu aż on tego nie poprawi odradzam instalację DB Cache.

Update 21.02.2010: Ponieważ plugin DB Cache nie został poprawiony, początkiem września zeszłego roku zdecydowałem się na jego poprawienie we własnym zakresie i opublikowałem go jako DB Cache Reloaded. Dodałem więc linka do niego powyżej w tym wpisie. Uaktualniłem też reguły do dodania do .htaccess, zgodnie z tym co się dowiedziałem w międzyczasie.

Przeczytaj też mój kolejny wpis, gdzie piszę dlaczego favikonka jest bardzo ważna.

This entry was posted on sobota, Sierpień 8th, 2009 at 15:49 and is filed under Skrypty. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

14 komentarzy do “Jak zoptymalizować WordPress’a”

  1. Adrian Says:

    Bardzo przydatny artykuł, te regułki htaccess przetestuję na jednej ze swoich stron, która generuje trochę spore obciążenie.

  2. SirZooro Says:

    Spoko. Daj znać jakie będą wyniki tych testów :)

  3. Konri Says:

    nie ma się co martwić, obecnie na moich stronkach nie ma więcej niż 100u dziennie

  4. MarkOh Says:

    wszystko fajnie z tym wpisem do .htaccess przyspiesza faktycznie ale niekiedy staje przy ladowaniu objektow flash i strona stoi ponad 10s

  5. SirZooro Says:

    Hmm, ciekawe – pliki .swf są zwykle wysyłane z mime type application/x-shockwave-flash, a takiego te reguły nie dotykają. Nie ruszają też plików z rozszerzeniem .swf. Czy mógłbyś sprawdzić która z kilku sekcji dodanych do .htaccess powoduje te problemy? Dodawaj po prostu po jednej, aż problem wystąpi.

  6. Burak Says:

    Niestety nie ruszają plików z rozszerzeniem .swf.

    Jan Kołodyński vel Burak Cukrowy

  7. Masa Says:

    Witam, bardzo mi się przydadzą twoje porady, chociaż używałem tego DB_cache, ale w ostatnich wersjach ta wtyczka powodowała właśnie tak jak piszesz, problemy z tagami. Spróbuje wpisać tą funkcję do wp-config i ten drugi podany kod do htaccess.

    Pozdrawiam
    M. Masa

  8. Marcin Says:

    Cześć uratowałeś mi dupe tym wpisem, postawilem stronke na wordpresie – dla swoich celów by udostepniac tylko paru osobom pewne rzeczy i jak sie zebrało to sie uzbierał taki ruch że firma hostingowa zaczela az krzyczec ze ponad 2 krotnie przekroczylem wykorzystanie proca na serwerze. Tak wiec dzięki! Postaram sie wykorzystac wszystkie twoje tricki (jak cos to nawet moze i maila Ci puszcze) i podziwiam za aktualizacjie na swoja reke wtyczki!

  9. endriu Says:

    Do autora tekstu :)

    Testowales moze Hyper Cache?
    Rowniez mam strone na prohoscie, a ostatnimi czasy widoczny jest znaczny wzrost zuzycia CPU.
    Korzystam z Hyper Cache, bo przy Super Cache strona generowala u mnie wyzsze obciazenie. A moze to kwestia konfiguracji wtyczki?

    Obecnie strone odwiedza ok. 2000 osob dziennie, a CPU to po 10pkt na każdy dzień – 100% wzrost w ostatnich dniach, choc nie dokonywalem zadnych zmian po stronie serwera, a ogladalnosc jest niezmienna od dluzszego czasu…

    Nie mam pojecia co jest tego przyczyną…
    Moze masz jakies pomysly jak mozna jeszcze zoptymalizowac strone albo mozesz polecic jakis dobry hostting, ktory nei straszy klientow blokadą po przekroczeniu limitow CPU?

    Pozdr. :)

  10. rodakk Says:

    Zastosowałem wszystkie powyższe pomoce. Oby to mi uratowało tyłek :D Pozdrawiam

  11. _Brutus Says:

    Właśnie miałem zamiar postawić stronę na WP i naczytałem się, że to bardzo zasobożerny skrypt! Dzięki za porządną instrukcję optymalizacji ;)

    Na pewno się przyda.
    Dziękuję

  12. barry waters Says:

    @burak „Niestety nie ruszają plików z rozszerzeniem .swf.Jan Kołodyński vel Burak Cukrowy”i agree

  13. Radek Says:

    Świetny wpis, dzięki :) Sam używam DB Cache Reloaded i działa cuda jeśli chodzi o zapytania.

  14. Wiktoria Says:

    Super! Mega przyspieszenie :) Dzięki!

 

Dodaj komentarz

Zanim dodasz komentarz, zapoznaj się z zasadami korzystania z serwisu i polityką prywatności! Komentarze niezgodne z zasadami korzystania z serwisu będę usuwane.

Proszę pozostawić te dwa pola tak jak są: