Przyśpieszanie strony za pomocą wtyczki WP Super Cache

WP Super CacheTego, jak ważna jest szybkość ładowania strony internetowej, nie trzeba nikomu tłumaczyć. Na temat wpływu czasu ładowania serwisu na współczynnik odrzuceń (czyli porzucenie strony przez odwiedzającego) powstało wiele opracowań, z których płynie jeden wniosek: każda sekunda, którą użytkownik spędza na czekaniu na otwarcie strony, zwiększa ryzyko zamknięcia przez niego karty przeglądarki. Czyli ruch w serwisie maleje, a współczynnik odrzuceń rośnie.

Najprostszym i jednocześnie bardzo skutecznym sposobem na skrócenie czasu ładowania strony (i jednocześnie zmniejszenie obciążenia serwera) jest zastosowanie mechanizmu cache. W przypadku WordPressa mamy do wyboru kilka wtyczek, z których najpopularniejszymi są W3 Total CacheWP Super Cache. O pierwszej z nich opowiadałem na ubiegłorocznym WordCampie, ale zwykłym użytkownikom polecam tę drugą.

Dlaczego WP Super Cache, a nie W3 Total Cache?

Wtyczka W3 Total Cache jest świetnym narzędziem, za pomocą którego można czynić cuda jeśli chodzi o skracanie czasu ładowania strony i zmniejszanie zużycia zasobów serwera. Niestety, jej konfiguracja jest bardzo rozbudowana, a co za tym idzie skomplikowana – niedoświadczony użytkownik może za jej pomocą narobić sporych problemów, szczególnie jeśli serwis, na którym eksperymentuje, obsługuje duży ruch.

Drugim argumentem przeciwko stosowaniu wtyczki W3 Total Cache jest to, że część jej funkcji będzie działać dobrze tylko na serwerze VPS (Virtual Private Server) lub dedykowanym, podczas gdy większość użytkowników korzysta z hostingu współdzielonego.
Ogólna zasada jest taka: na serwerach wirtualnych (współdzielonych) lepiej jest korzystać z WP Super Cache, a na serwerach VPS i dedykowanych – z W3 Total Cache. Oczywiście od każdej reguły są wyjątki i na pewno znajdą się tacy, którzy będą w stanie udowodnić, że w ich przypadku jest inaczej, ale jeśli nie mamy dużego doświadczenia z cacheowaniem, to po prostu trzymajmy się tej zasady.

W3 Total Cache udostępnia jednak kilka narzędzi, których brakuje we wtyczce WP Super Cache, a które mogą okazać się przydatne. Na szczęście bardzo łatwo uzupełnić te braki – niezbędne informacje zamieściłem na końcu tego wpisu.

Warto wspomnieć, że WP Super Cache jest od jakiegoś czasu współtworzona przez Automattic.

Jak działa wtyczka WP Super Cache?

Każde żądanie wyświetlenia strony powoduje, że WordPress pobiera sobie wszystkie potrzebne informacje z bazy danych, przetwarza je, a następnie generuje dokument HTML, który jest wysyłany do przeglądarki użytkownika. WP Super Cache zapisuje wygenerowane dokumenty HTML na dysku serwera, tak aby WordPress nie musiał za każdym razem generować ich od nowa. Przyśpiesza to znacząco ładowanie strony, a na dodatek zmniejsza obciążenie serwera, co nie jest bez znaczenia, szczególnie w przypadku tanich hostingów współdzielonych, gdzie administratorzy często nakładają limity wykorzystania czasu procesora i obciążenia bazy danych.

Dodatkowo WP Super Cache posiada kilka narzędzi nie związaych bezpośrednio z mechanizmem cache, ale pomagających w skróceniu czasu ładowania strony – na przykład obsługę CDN (Content Delivery Network) czy kompresję gzip.

Konfiguracja WP Super Cache

Konfiguracja wtyczki WP Super Cache nie jest szczególnie skomplikowana, aczkolwiek mniej doświadczeni użytkownicy mogą trafić na kilka opcji, których działanie nie będzie dla nich całkowicie jasne.

Na wszystkich zamieszczonych poniżej zrzutach ekranu pokazana jest polecana przeze mnie konfiguracja. Jest ona w miarę uniwersalna, ale w niektórych przypadkach może się nie sprawdzić i będzie wymagać drobnych modyfikacji.

Włączenie wtyczki

Po aktywacji wtyczki jest ona domyślnie wyłączona. Aby ją włączyć trzeba odwiedzić w panelu administracyjnym stronę Ustawienia → WP Super Cache i wybrać opcję Caching On, a następnie kliknąć przycisk Update Status.

WP Super Cache - ustawienia

Po włączeniu wtyczka WP Super Cache próbuje dodać dwie linie do pliku wp-config.php. Często plik ten jest zabezpieczony przed zapisem i konieczne jest dodanie tych linii ręcznie. Wyglądają one mniej więcej tak:

Oczywiście stała WPCACHEHOME powinna zawierać poprawną ścieżkę do katalogu wtyczki.

WP Super Cache - Cache TesterPo włączeniu wtyczki na głównej stronie jej ustawień (zakładka Easy) pojawi się nowa sekcja Cache Tester. To proste narzędzie służy do sprawdzenia czy mechanizm cache działa poprawnie. Po kliknięciu przycisku Test Cache zostanie wykonany test, którego wynikiem będzie raport podobny do widocznego na zamieszczonym obok zrzucie ekranu.

Może się jednak zdarzyć, że wynik testu będzie negatywny. Najczęstszy komunikat, jaki możemy zobaczyć, to The pages do not match! Timestamps differ or were not found!. Jeśli oba testowe pliki zostały poprawnie utworzone (obok każdego z nich widnieje zielone OK), to najprawdopodobniej wyłączyliśmy dołączanie do kodu strony komentarza z informacją o statusie cache (opcja Cache Status Messages w zakładce Debug). Możliwe są również problemy z plikiem .htaccess, najczęściej związane z nieprawidłowo dodanym kodem generowanym przez WP Super Cache. Jeśli natomiast któryś z plików nie został utworzony, to najprawdopodobniej oznacza to problem z uprawnieniami katalogu wp-content/cache.

Ostatnim elementem na stronie głównej ustawień wtyczki jest przycisk Delete cache. Jego kliknięcie spowoduje usunięcie całej zawartości cache, czyli wszystkich wygenerowanych plików. Jest to konieczne gdy na przykład zmodyfikujemy kod używanego motywu lub dodamy jakąś wtyczkę, która wyświetla coś na stronie.

Jeśli jesteśmy na etapie tworzenia naszej strony, lepiej jest całkowicie wyłączyć wtyczkę WP Super Cache. Dzięki temu będziemy zwolnieni z konieczności ciągłego czyszczenia cache.

Konfiguracja cache

Konfiguracja mechanizmu cache znajduje się w zakładce Advanced.

WP Super Cache - ustawienia

Opcja Cache hits to this website for quick access po prostu włącza mechanizm cache w naszym serwisie. Poniżej znajdują się opcje pozwalające na wybór metody działania cache.
Opcja Use mod_rewrite to serve cache files to metoda najwydajniejsza, korzystająca z modułu mod_rewrite serwera Apache do serwowania wygenerowanych plików HTML. Nie angażuje ona w ogóle interpretera PHP, przez co jest polecana dla serwisów z dużym ruchem. Jest jednak najtrudniejsza w konfiguracji, ponieważ wymaga modyfikacji pliku .htaccess (na szczęście wtyczka może to zrobić za nas).
Opcja Use PHP to serve cache files włącza metodę serwującą statyczne pliki za pośrednictwem wtyczki (która oczywiście korzysta z PHP). To metoda jest najprostsza w konfiguracji, a na dodatek pozwala na zachowanie dynamicznych fragmentów stron (czyli wyłączenie ich z cache).
Ostatnia opcja Legacy page caching włącza metodę, która tworzy cache głównie dla znanych (czyli w praktyce zalogowanych) użytkowników. Jest najwolniejsza i generalnie nie jest polecana.

Mimo że autor WP Super Cache poleca zwykłym użytkownikom drugą metodę (Use PHP to serve cache files), moim zdaniem warto mimo wszystko spróbować skorzystać z opcji pierwszej.

WP Super Cache - ustawienia

Sekcja Miscelanous zawiera kilka przydatnych opcji związanych z działaniem cache, z których kilka obowiązkowo trzeba włączyć.

Opcja Compress pages so they’re served more quickly to visitors włącza kompresję gzip dla wygenerowanych plików HTML. Oznacza to, że strony są przesyłane do przeglądarki w formie skompresowanej, czyli mają mniejszą wielkość i są pobierane szybciej. Jeśli korzystamy z pierwszej metody działania cache, to opcja ta do działania wymaga modułu mod_deflate, który jest dostępny na większości serwerów (ale nie na wszystkich – nie ma go na przykład na serwerach wirtualnych oferowanych przez Home.pl).
Warto zwrócić uwagę, że włączona w ten sposób kompresja obejmuje tylko pliki HTML – nie są kompresowane pliki CSS, skrypty JavaScript czy obrazki. Na końcu wpisu umieściłem instrukcję aktywowania kompresji gzip dla innych typów treści.

Włączenie opcji 304 Not Modified browser caching powoduje, że serwer zwraca do przeglądarki kod 304 jeśli żądana strona nie zmieniła się od ostatniej wizyty. Pozwala to na wykorzystanie cache przeglądarki i pominięcie pobierania strony. Opcja ta nie jest dostępna jeśli korzystamy z pierwszej metody działania cache (nawet jeśli jest zaznaczona).

Don’t cache pages for known users to opcja, której należy się nieco więcej uwagi. Działa w bardzo prosty sposób: po jej włączeniu wszyscy „znani” użytkownicy będą widzieć dynamicznie generowane wersje stron, a nie strony znajdujące się w cache. „Znani” użytkownicy to osoby zalogowane (w tym również administratorzy, którzy zawsze powinni widzieć aktualną wersję strony) i osoby, które zostawiły co najmniej jeden komentarz (przy założeniu, że korzystamy z wbudowanego w WordPressa systemu komentarzy, a nie na przykład z komentarzy Disqus). Opcja ta powinna być włączona, ponieważ w innym przypadku może się zdarzyć, że stronę wygenerowaną dla zalogowanego użytkownika (na przykład zawierającą jego imię i nazwisko) i umieszczoną w cache dostanie później ktoś inny.

Włączenie opcji Make known users anonymous so they’re served supercached static files powoduje, że „znani” użytkownicy będą otrzymywać strony z cache (tak jak użytkownicy anonimowi). Ta opcja może powodować problemy z personalizacją serwisu dla zalogowanych osób, dlatego też polecam ją wyłączyć.

Opcja Don’t cache pages with GET parameters. (?x=y at the end of a url) wyłącza cache dla stron, których adres URL zawiera parametry (na przykład http://domena.pl/?parametr=wartosc). Jest to przydatne gdy na przykład korzystamy z wtyczek, które w ten sposób przekazują jakieś dane i na ich podstawie zmieniają wygląd strony. Mimo że nie ma sensu włączać tej opcji bez wyraźnej potrzeby, to jej aktywacja nie powinna w niczym zaszkodzić.

Opcja Cache rebuild. Serve a supercache file to anonymous users while a new file is being generated. włącza sprytny sposób regeneracji cache. Pliki w cache po pewnym czasie od ich utworzenia są uznawane za wygasłe i przy pierwszej okazji są generowane ponownie. Jedną z takich okazji jest wyświetlenie danej strony przez użytkownika. Jednak gdy w trakcie trwania procesu generacji kolejni użytkownicy będą chcieli otworzyć tę stronę, zobaczą oni jej „starą” wersję. Daje to dwie korzyści. Po pierwsze, kolejne osoby nie uruchomiają kolejnych procesów regeneracji cache. Po drugie, nie będą musiały one czekać na zakończenie tworzenia cache, zainicjowanego przez pierwszego użytkownika. W praktyce opcja ta daje wymierne korzyści tylko w przypadku serwisów z dużym ruchem.

Opcja Proudly tell the world your server is Stephen Fry proof! nie robi nic poza dodaniem do stopki naszej strony tekstu promującego WP Super Cache („WPzen is Stephen Fry proof thanks to caching by WP Super Cache”).

WP Super Cache - ustawienia

Sekcja Advanced teoretycznie zawiera opcje przeznaczone dla zaawansowanych użytkowników, ale w praktyce znalazło się tam wszystko, co nie pasowało gdzie indziej.

Opcja Enable dynamic caching włącza dynamiczny cache. Funkcja ta pozwala na dynamiczne generowanie fragmentów strony. Jest to przydatne jeśli na przykład chcemy wyświetlać listę losowych wpisów, która normalnie przy pierwszym wyświetleniu strony zostałaby umieszczona w cache i nie zmieniała się do momentu wygaśnięcia cache. Opcja ta nie będzie działać jeśli włączyliśmy tryb cache korzystający z mod_rewrite.

Niestety, korzystanie z dynamicznego cache nie jest proste. Musimy korzystać z filtra wpsc_cachedata, w którym możemy zamieniać jakąś treść (na przykład specjalnie przygotowany znacznik) na inną. Przykłady można znaleźć w tym pliku. Problematyczne jest również to, że w kodzie podpiętym do wspomnianego filtra nie możemy korzystać z funkcji WordPressa – aby było to możliwe należy włączyć opcję Late init, która ma swoje wady (o nich za chwilę).

Opcję tę należy wyłączyć jeśli nie mamy zamiaru korzystać z dynamicznego cache.

Opcja Mobile device support włącza wsparcie dla urządzeń mobilnych. Funkcja ta do działania wymaga instalacji wtyczki wyświetlającej wersję mobilną naszej strony. W tej chwili obsługiwane są rozszerzenia Jetpack (moduł Mobile Theme), WPtouch, WordPress Mobile Edition i WordPress Mobile Pack. Jeśli nasz motyw jest responsywny (dostosowuje się automatycznie do rozdzielczości ekranu) i nie mamy osobnej mobilnej wersji strony, to opcję tę należy wyłączyć.

Opcja Clear all cache files when a post or page is published or updated to jedna z najważniejszych opcji w całej konfiguracji. Gdy ją włączymy, po publikacji lub aktualizacji wpisu czy strony cały cache zostanie automatycznie wyczyszczony (domyślnie czyszczony jest tylko cache dla aktualizowanej treści). Polecam włączenie tej opcji, chyba że nasz serwis zawiera bardzo dużo treści, mamy ustawiony bardzo długi czas życia cache i/lub na stronie pojawia się bardzo dużo nowych wpisów w krótkim czasie.

Wyłączenie tej opcji w połączeniu z włączeniem omawianej wcześniej opcji Don’t cache pages for known users prowadzi do tragicznych w skutkach pomyłek. Autor, który właśnie opublikował nowy wpis, widzi go na stronie głównej, ponieważ cache nie działa dla znanych użytkowników. W tym samym czasie niezalogowani użytkownicy widzą wersję z cache, a więc bez nowego wpisu. Stan ten trwa tak długo, jak długo cache nie wygaśnie.

Działania opcji Extra homepage checks nie do końca rozumiem. W jej opisie jest ostrzeżenie, że może ona okazjonalnie wyłączać cache strony głównej – u mnie zdarzało się to dość często i dlatego mam tę opcję wyłączoną.

Włączenie opcji Only refresh current page when comments made powoduje, że po publikacji nowego komentarza odświeżany jest cache tylko dla strony, na której ten komentarz został dodany. Ma to oczywiste zalety z punktu widzenia wydajności, ale spowoduje, że nowe komentarze nie będą od razu widoczne na przykład w widgecie „Najnowsze komentarze”.

Opcja List the newest cached pages on this page włącza wyświetlanie listy stron, dla których wygenerowano ostatnio plik cache. Lista ta znajduje się w żółtej ramce po prawej stronie.

Opcja Coarse file locking włącza blokowanie pliku cache na czas jego regeneracji. Podobno czasem pomaga ona gdy nasz serwer jest przeciążony, ale sam autor nie jest chyba co do tego przekonany. Opcja ta prawdopodobnie zostanie wkrótce usunięta z wtyczki.

Włączenie opcji Late init spowoduje, że pliki z cache będą przesyłane do przeglądarki dopiero po załadowaniu WordPressa. Może to być przydatne gdy chcemy korzystać z funkcji WordPressa w dynamicznym cache. W każdym innym przypadku należy ją wyłączyć, aby zyskać nieco na wydajności – domyślnie pliki z cache są serwowane bez ładowania całego WordPressa, co pozwala na zaoszczędzenie zasobów serwera (czas procesora i pamięć).

Na dole sekcji Advanced znajdziemy DO NOT CACHE PAGE secret key. Jest to specjalny kod, za pomocą którego możemy obejrzeć dowolną stronę z pominięciem cache. Wystarczy do adresu strony dodać parametr donotcachepage, na przykład w taki sposób: http://nasza-strona.pl/?donotcachepage=nasz_sekretny_kod.

WP Super Cache - Mod Rewrite Rules

Jeśli włączyliśmy obsługę cache za pomocą modułu mod_rewrite, to po każdej aktualizacji ustawień wtyczki na zakładce Advanced pojawi się sekcja Mod Rewrite Rules. Zawiera ona żółtą ramkę (jej fragment widać na zamieszczonym wyżej zrzucie ekranu), w której znajduje się kod, jaki powinien zostać dopisany do naszych plików .htaccess. Pliki te są dwa: jeden znajduje się w katalogu głównym naszej strony (tam, gdzie jest zainstalowany WordPress), a drugi w katalogu /wp-content/cache/ (są w nim zapisywane pliki cache). Jeśli uprawnienia na to pozwalają, wtyczka sama dokona odpowiednich zmian w plikach – wystarczy kliknąć przycisk Update Mod_Rewrite Rules. W przeciwnym wypadku będziemy musieli wykonać zmiany ręcznie.

WP Super Cache - garbage collector

Sekcja Expiry Time & Garbage Collection jest bardzo ważna, ale jednocześnie działanie znajdujących się w niej opcji jest dość skomplikowane. Pozwala ona na konfigurację mechanizmu automatycznego czyszczenia cache z „przeterminowanych” stron oraz na określenie czasu, po jakim strony w cache są uważane za „przeterminowane”.

Usuwanie starych wersji stron z cache ma sens tylko wtedy, gdy w naszym serwisie znajdują się elementy dynamiczne, zmieniające się co jakiś czas, przy czym zmiany te nie wynikają z publikacji lub edycji wpisów. Takimi elementami mogą być na przykład listy najczęściej czytanych wpisów, ostatnich tweetów czy najpopularniejszych towarów w sklepie. Odpowiednio częste odświeżanie cache spowoduje, że elementy te wciąż będą się zmieniać, tyle że nie w czasie rzeczywistym, a co określony przez nas czas. Jeśli nasza strona takich elementów nie posiada, możemy spokojnie wyłączyć mechanizm usuwania „przeterminowanych” stron z cache i włączyć opcję Clear all cache files when a post or page is published or updated, która wyczyści cały cache po publikacji lub aktualizacji jakiegoś wpisu.

Pole Cache Timeout umożliwia określenie czasu (w sekundach), po jakim strony znajdujące się w cache są uznawane za „przeterminowane” i przeznaczone do usunięcia z cache. Wprowadzenie cyfry 0 (zero) całkowicie wyłącza mechanizm automatycznego usuwania starych stron z cache. Nie ma idealnej wartości tego parametru, bo dużo zależy od konkretnego serwisu, ale zaleca się aby rozpocząć eksperymenty od 3600 sekund (jedna godzina).

Opcja Scheduler określa sposób, w jaki uruchamiany jest mechanizm czyszczenia cache. Może on aktywować się co określony czas (Timer) lub co określony czas (Interval) rozpoczynając od wprowadzonej godziny (Clock).

I tu zwykle pojawiają się dwie wątpliwości.

Skoro „czas życia” cache jest ustawiony na godzinę (3600 sekund), to po co uruchamiać mechanizm czyszczący co pół godziny (1800 sekund)?
Plik cache danej strony jest tworzony przy pierwszym jej otwarciu (lub przez preloader – o czym za chwilę). Oznacza to, że w przypadku większości serwisów pliki cache nie są tworzone jednocześnie, ani nawet w krótkich odstępach czasu, a co za tym idzie czas ich wygaśnięcia nie jest zbytnio zbliżony. Jeśli mamy 4 strony, których pliki cache wygasają o godzinie 12:05, 12:20, 12:35 i 12:50, to przy uruchomieniu mechanizmu czyszczącego o godzinie 12:30 zostaną usunięte trzy pierwsze pliki, a przy drugim uruchomieniu – dwa kolejne. Dzięki temu proces czyszczenia wykona się szybciej (ma mniej do zrobienia), a jednocześnie unikamy utworzenia zbyt wielu plików cache o zbliżonym czasie wygaśnięcia.

Czy serwer nie ulegnie przeciążeniu jeśli będzie musiał co pół godziny lub godzinę regenerować cache?
Usunięcie plików z cache nie oznacza ich natychmiastowej regeneracji. W praktyce może się okazać, że z usuniętych 10 stron nowy plik cache zostanie wygenerowany tylko dla jednej, bo reszta nie zostanie odwiedzona (chyba że działa preloader – o czym za chwilę).
W serwisach o dużym ruchu i dużej liczbie stron/wpisów warto trochę poeksperymentować z różnymi wartościami czasu życia cache i czasu uruchamiania mechanizmu czyszczącego, tak aby rozłożyć usuwanie plików cache w czasie. Warto również rozważyć całkowite wyłączenie usuwania cache i robić to tylko w momencie publikacji lub aktualizacji treści (tak jak to opisałem wyżej).

Ostatnia opcja związana z mechanizmem czyszczenia cache (Notification Emails) pozwala na włączenie wysyłania wiadomości e-mail za każdym razem gdy mechanizm ten zostanie uruchomiony. Nie warto jej włączać gdy proces ten działa co godzinę, bo zostaniemy zasypani bezużytecznymi e-mailami.

Kolejne sekcje zakładki Advanced pozwalają nam na wykluczenie określonych stron z cache oraz wymuszenie tworzenia cache dla stron, dla których normalnie nie jest to robione. Z tymi ustawieniami należy obchodzić się ostrożnie – jeśli nie mamy potrzeby ich używania, to lepiej zostawić je w spokoju.

WP Super Cache - Conditional Tags

Pokazana wyżej sekcja pozwala na wykluczenie z cache określonych typów stron. Wyjaśnienie dla poszczególnych znaczników (podanych w nawiasach) znaleźć można w dokumentacji.

  • Single Posts – strona wpisu
  • Pages – strona
  • Front Page – strona główna
  • Home – strona z listą wpisów (nie musi być stroną główną)
  • Archives – strona archiwum (każdego – tagu, kategorii, autora, miesiąca itd.)
  • Tags – archiwum tagów
  • Category – archiwum kategorii
  • Feed – kanał RSS
  • Search Pages – wyniki wyszukiwania
  • Author Pages – strona autora

WP Super Cache - wykluczone strony

Tutaj możemy wprowadzić fragmenty adresów URL, dla których cache nie będzie aktywny. Przykładowo, jeśli chcemy wyłączyć cache dla archiwum roku 2014, to wystarczy wpisać /2014/.

WP Super Cache - pliki

Tutaj z kolei możemy wprowadzić nazwy plików, dla których cache będzie włączony, niezależnie od tego, co wprowadziliśmy w dwóch wcześniejszych sekcjach.

WP Super Cache - wykluczone user agents

A tutaj możemy wprowadzić ciągi znaków, które będą wyszukiwane w nagłówku User Agent. Dla żądań z takimi nagłówkami nie będą generowane pliki cache. Domyślnie na liście znajdują się boty popularnych wyszukiwarek. Warto zwrócić uwagę, że opcja ta blokuje tylko generację nowych plików cache – jeśli plik cache już istnieje, to zostanie on użyty.

Zakładka Preload zawiera ustawienia preloadera – narzędzia, które pozwala na masowe generowanie plików cache dla wszystkich podstron naszego serwisu.

Gdy użytkownik odwiedza naszą stronę, wtyczka WP Super Cache sprawdza czy w cache istnieje wygenerowany plik HTML dla otwieranej podstrony. Jeśli pliku nie ma, to strona jest generowana tak jak zwykle, a jednocześnie tworzony jest odpowiedni plik w cache. Druga odsłona tej samej strony będzie już obsłużona przez cache. Jeśli więc spodziewamy się zwiększonego ruchu i nasza strona posiada dużo podstron, to warto jest skorzystać z preloadera, który wcześniej przygotuje pliki w cache.

WP Super Cache - Preload

Opcja Refresh preloaded cache files every X minutes określa co jaki czas uruchamiany będzie preloader. Minimalną wartością jest 30 minut. Wprowadzenie zera wyłącza mechanizm.

Opcja Preload X posts pozwala na określenie liczby wpisów, które zostaną przetworzone podczas każdego uruchomienia preloadera. W praktyce jest to wybór liczby najnowszych wpisów, dla których wygenerowane zostaną pliki cache. Jeśli korzystamy z hostingu współdzielonego, to lepiej nie szaleć i wybrać mniejszą liczbę (sugeruję maksymalnie kilkaset, ale można poeksperymentować) – proces masowej generacji cache jest dość zasobożerny i może zdarzyć się, że firma hostingowa zwróci uwagę na zbyt duże obciążenie serwera, a w najgorszym wypadku nawet zablokuje nasze konto. Pliki cache dla wpisów, które nie zostaną przetworzone przez preloader, będą generowane w standardowy sposób.

Włączenie opcji Preload mode spowoduje, że mechanizm czyszczący cache będzie pomijał pliki wygenerowane przez preloader (zostaną one odświeżone podczas kolejnego uruchomienia procesu). Jest to opcja zalecana, ponieważ jej wyłączenie burzy tak naprawdę całą ideę.

Opcja Preload tags, categories and other taxonomies włącza generowanie cache również dla archiwów tagów, kategorii i własnych taksonomii (domyślnie preloader generuje tylko pliki cache dla stron i wpisów).

Opcja Send me status emails when files are refreshed włącza wysyłanie powiadomień e-mail o uruchomieniu procesu generacji cache. Ma ona trzy warianty: w pierwszym otrzymamy 2 wiadomości na każde 100 przetworzonych wpisów, w drugim wiadomość będzie tylko jedna, a w trzecim zostaniemy powiadomieni tylko o rozpoczęciu i zakończeniu procesu. Jeśli koniecznie chcemy otrzymywać takie powiadomienia, to polecam wariant trzeci.

Konfiguracja CDN

W zakładce CDN znajdziemy opcje pozwalające na skorzystanie na naszej stronie z serwerów CDN (Content Delivery Network). Konfiguracja jest bardzo prosta i w praktyce sprowadza się do wprowadzenia adresu dla plików trzymanych w CDN.

CDN nie ma wiele wspólnego z cache. To sieć serwerów, z których przesyłane są do naszych użytkowników wybrane rodzaje statycznych plików (najczęściej są to pliki multimedialne, ale mogą to być również pliki CSS i JavaScript). Serwery te są szybkie i zoptymalizowane do serwowania plików statycznych. Na dodatek w porządnych sieciach CDN serwery są rozrzucone po całym świecie, tak aby użytkownicy z różnych krajów byli obsługiwani przez serwer znajdujący się jak najbliżej.

Z punktu widzenia właściciela strony, CDN działa w sposób praktycznie niewidoczny. Gdy odwiedzający otwiera naszą stronę, żądania wyświetlenia (a właściwie pobrania) statycznych plików trafiają do serwera CDN. Serwer sprawdza czy posiada takie pliki. Jeśli ich nie ma, to pobiera je sobie z naszej strony i zachowuje, dystybuując je jednocześnie do pozostałych serwerów w sieci CDN. Jeśli pliki istnieją, to są one od razu przesyłane do użytkownika.

Korzystanie z CDN ma jeszcze jedną zaletę. Ponieważ pliki statyczne są dostępne pod inną niż właściwa strona subdomeną, przeglądarki będą próbowały pobierać je równolegle z plikami pobieranymi z właściwej domeny, co teoretycznie może nieco przyśpieszyć ładowanie strony.

Zanim włączymy obsługę CDN na naszej stronie należy dokonać odpowiedniej konfiguracji w panelu administracyjnym CDN. Konfiguracja taka wygląda różnie w zależności od wybranego usługodawcy, dlatego nie została ona opisana w tym tekście.

WP Super Cache - CDN

Opcja Enable CDN Support włącza wsparcie dla CDN. Off-site URL to adres, który podaliśmy w konfiguracji CDN. Pole Include directories zawiera nazwy katalogów, z których pliki będą przesyłane do CDN. W standardowej instalacji WordPressa wartości domyślne powinny być wystarczające. Pole Exclude if substring pozwala na wykluczenie wybranych katalogów lub plików. Koniecznie należy w tym polu pozostawić rozszerzenie .php. W polu Additionaml CNAMES możemy wprowadzić dodatkowe subdomeny dla plików serwowanych z CDN. Ma to sens gdy nasza strona zawiera bardzo dużo statycznych plików (równoległe pobieranie).

Informacje diagnostyczne

Zakładka Debug pozwala na włączenie zapisywania informacji diagnostycznych do pliku logu (opcja Debugging). Możemy tu również włączyć dodawanie informacji o statusie cache do naszej strony – ma ona formę komentarza w kodzie HTML i może wyglądać na przykład tak:

Narzędzia uzupełniające

Jak wspomniałem na początku, wtyczce WP Super Cache brakuje kilku narzędzi, dzięki którym możemy jeszcze trochę przyśpieszyć ładowanie naszej strony.

Scalanie i kompresja plików CSS i JavaScript oraz kodu HTML strony

Jeśli nasza strona korzysta z dużej liczby plików CSS i JavaScript, to dobrze byłoby je scalić i skompresować, tak aby zmniejszyć liczbę żądań i sumaryczną objętość plików. Zadanie to możemy powierzyć wtyczce Autoptimize, która dodatkowo skompresuje kod HTML naszej strony.

Wykorzystanie cache przeglądarki

W praktyce sprowadza się to do ustawienia plikom odpowiednich nagłówków Expires. Można to zrobić wspomnianą już wtyczką Autoptimize, można również wprowadzić odpowiedni kod do pliku .htaccess (osobiście najczęściej korzystam z tego rozwiązania).

Zaawansowana obsługa CDN

Wprawdzie obsługa CDN nie jest najważniejszą z opcji WP Super Cache, ale skoro już jest, to mogłaby (tak jak W3 Total Cache) ułatwiać konfigurację dla konkretnych usługodawców (np. CloudFlare, MaxCDN czy Amazon Cloudfront). Praktycznie wszyscy udostępniają własne wtyczki, które zwykle udostępniają nieco bardziej zaawansowaną konfigurację.

Co dalej?

Jeśli już zainstalowaliśmy WP Super Cache na naszej stronie, to warto poświęcić trochę czasu i poeksperymentować z jej ustawieniami. Może się okazać, że w danej sytuacji optymalna będzie nieco inna niż polecana przeze mnie konfiguracja. Czynników, które mogą mieć na to wpływ, jest kilka, między innymi ruch na stronie, ilość podstron (w tym ilość wpisów i stron) czy wydajność serwera oraz jego ogólne obciążenie.

Eksperymenty warto zacząć już na samym początku, nawet jeśli naszą witrynę odwiedza tylko kilka osób dziennie – Google preferuje szybko ładujące się strony.

Bezpośredni link

  • zxc

    Wtyczka Super Cache – ma wydaje się bardzo dobrą funkcjonalność opisana przez ciebie „tworzy plik HTML a nie dynamicznie tworzy zawsze stronę”. Musze to sprawdzić

    W3cache – ja stworzyłem jeden plik i za każdym razem importuje go dla każdego nowego serwisu
    Super Cache – czy tu jest opcja importu?

    Ok, fajnie że opisałeś (sporo tego) ale czy możesz dołączyć ew. plik do importu z ustawieniami?
    Jaka i czy w ogóle jest różnica w efekcie pomiędzy wtyczkami?
    Czy np. SuperCache ma kompresję JS,CSS i scalanie w jeden plik?

    • W3 Total Cache działa dokładnie tak samo (Page Cache).

      WP Super Cache nie ma opcji eksportu/importu ustawień.

      Co do kompresji i scalania CSS i JS, to nie doczytałeś wpisu do końca. ;)

    • WP SC jest dobrą wtyczką do przyspieszenia ładownia strony. Ja od kiedy zmieniłem, czy może oddałem się jej przyspieszyłem blog. Naturalnie możesz korzystać oczywiście z pierdyliona innych w tym płatnych wtyczek. Na codecanyon.net jest tego na kilogramy. Ale w tym wszystkim podstawa jak serwer czyli host z prawidłową obsługą gzip nie zaszkodzi.

  • Karol

    Nie rozumiem jednej rzeczy. Czy za pomocą tej wtyczki włącze kompresje mojej strony opartej na wordpress? Gdy wybiore moduł mod_rewrite to znaczy że wtyczka dopisze do pliku .htaccess odpowiednią formułkę wymuszająca włączenie kompresji ?
    Czy po prostu muszę ręcznie dodać formułkę kompresji do .htaccess + włączyć mod_rewrite w tej wtyczce.

    Proszę o wyjaśnienie, bo się pogubiłem :)

    • Tak, wtyczka posiada opcję włączenia kompresji gzip dla strony (Compress pages so they’re served more quickly to visitors).

      • Karol

        Czyli nie muszę dopisywać ręcznie własnych regułek do .htaccess tylko zrobic update tego co podpowiada wp super cache w .htaccess i to wystraczy ? Beż żadnych dodatkowych czynności w panelu DirectAdmin swojego hostingu ?

        • Jeśli chodzi tylko o kompresję gzip, to nie musisz wykonywać żadnych dodatkowych czynności – wtyczka sama doda odpowiednie wpisy do .htaccess. Upewnij się tylko, że masz na serwerze zainstalowany moduł mod_deflate dla Apache (to on jest po stronie serwera odpowiedzialny za kompresję).

          • Karol

            Tak serwer obsługuje moduł mod_deflate. Włączyłem odpowiednie funkcje w WP Super Cache, program dodał wpisy do .htaccess i z tego co testuje to kompresja działa :)

            Natomiast gdy kontaktowałem się z hostingiem też kazali dodać odpowiednie (inne) regułki do .htaccess + włączyć moduł zlib.output_compression w ustawieniach PHP, jednak wybrałem twój sposób.

            Jak myślisz jest jakaś różnica pomiędzy tymi opcjami które wymieniłem ? Lepiej jak zrobił to program ? czy jednak korzystać z ustawień hostingu ?

            Wynik tak czy siak według Google Page Speed Insights poprawił się z 55 na 74 (komórka) i 63 na 87 jeśli chodzi o komputery.

          • Nie wiem co kazali Ci dodać do .htaccess. ;) Natomiast kompresja włączana w ustawieniach PHP kompresuje tylko pliki przechodzące przez parser – czyli nie dotyka plików CSS, JS itp.

  • Wpis jak zwykle ciekawy, do większości rzeczy doszedłem samemu wcześniej, ale jak zwykle o paru się dowiedziałem :)
    Dzięki

  • Cześć Bartek, super wpis! Od dłuższego czasu konfiguruję swojego bloga i często trafiam na Twojego bloga znajdując odpowiednie rozwiązania. A co sądzisz o Cloud Flare? Próbuję znaleźć miejsce tej darmowej usługi wśród pluginów cache, myślisz że WP Super Cache + Autoptimize + Cloud Flare by się sprawdziło? Cloud flare też ma opcje „minify”, nie wiem czy nie będzie kolidowało ze sobą.

    • CloudFlare jest OK – jak najbardziej polecam wypróbować ich usługi, szczególnie że na początek spokojnie powinien Ci wystarczyć darmowy pakiet.

      Co do opcji „minify” – nie ma sensu robić tego w dwóch miejscach. Sprawdź która metoda sprawdzi się lepiej w Twoim przypadku (wtyczka czy CloudFlare) i zostań przy niej.

    • Karol

      Mateusz, korzystam z bezpłatnego pakietu od CloudFlare wraz z SSL. Póki co mam małe problemy, ponieważ cały content na wordpressie sie miksuje odkąd strona jest z https zamiast http, trzeba trochę pogrzebać i poustawiać wszystko :)

  • brak CPU zmotywowalo mnie do ustawienia wtyczki. miałem juz ja ale nie byla skomfigurowana. doradzasz experymentowanie dla mnie nie informatyka nie do osiagniecia. ustawiałem według instrukcji . jak to usprawnić idziec rezultaty… naszych experymentów ustawień.? czy towoje ustawienia odwzorowanie u siebie nie będzie odpowienie? dzieki

    • W większości przypadków opisane przeze mnie ustawienia powinny się sprawdzić. Możesz pokombinować z wyłączeniem automatycznego czyszczenia cache (o ile go nie potrzebujesz), bo wtedy cache będzie czyszczony tylko podczas publikacji lub aktualizacji wpisów.

      Wyniki eksperymentów najłatwiej sprawdzić analizując obciążenie serwera w jakimś dłuższym czasie.

  • zen

    O kurcze! Sporo tego. Przydała by się taka opcja uproszczona. Np przycisk „przyspiesz stronę”. Heh :)

    • Teoretycznie możesz się ograniczyć do włączenia cache i nie zagłębiania się w kolejne opcje. ;)

  • Karol

    Po jakimś czasie pojawiła się taka informacja na samej górze wtyczki :

    It appears you have WordPress installed in a sub directory as described here. Unfortunately WordPress writes to the .htaccess in the install directory, not where your site is served from.
    When you update the rewrite rules in this plugin you will have to copy the file to where your site is hosted. This will be fixed in the future.

    Nie za bardzo rozumiem o co chodzi ? Mógłbyś mi pomóc?

    • Zainstalowałeś WordPressa w podkatalogu i wtyczka zapisuje plik .htaccess w tym katalogu. Musisz po prostu skopiować plik .htaccess ręcznie do katalogu głównego strony.

      • Karol

        Posiadam na serwerze w głównym katalogu domeny(tam gdzie wszystkie pliki z wordpressa) plik .htaccess natomiast jak wchodze w wp-content>cache> tu widnieje również plik pod taka sama nazwą lecz z inną treścią. Czy to jest ten błąd ?
        Co w tym wypadku zrobić ?

        • Jeśli WordPressa zainstalowałeś w katalogu głównym, to komunikat wyświetlany przez wtyczkę jest błędny i nic nie powinieneś robić. Upewnij się tylko, że w pliku .htaccess znajdującym się w katalogu głównym masz wpisy dodane przez wtyczkę (komentarz # BEGIN WPSuperCache).

          Plik .htaccess znajdujący się w katalogu ‚cache’ ma zupełnie inne przeznaczenie niż ten znajdujący się w katalogu głównym, tak więc nie należy go ruszać.

          • Karol

            Mam coś takiego: http://pastebin.com/bteiTu3m
            przy czym ta regułkę od supercache dodałem automatycznej po włączeniu kompresji, a reszta była już od początku, więc chyba wszystko jest w porządku.

          • Ciekawe jest to, że masz zduplikowany kod od WP Super Cache. W niczym to nie powinno przeszkadzać, ale to dziwne.

          • Karol

            Podpinałem ostatnio certyfikat SSL’a do strony może dlatego ?

          • Wątpię. Te dwa bloki kodu różnią się tylko jedną linią:

            RewriteCond %{HTTP:Accept-Encoding} gzip

          • Karol

            usunąłem regułke „supercache” z .htaccess i ponownie zaktualizowałem poprzez wtyczke mod_rewrites. Plik się spowrotem nadpisał, jest to samo oprócz tego że między # BEGIN WordPress i #END brakuje
            RewriteEngine On
            RewriteBase /

            natomiast przy # BEGIN WPSuperCache takie dwie linijki kodu istnieją, czy to będzie stwarzać jakis problem ?

          • Dokładnie tak ma być. ;)

          • Karol

            Przepraszam że zapytam tak tutaj, ale czy udzielasz także indywidualnych porad ? Można nawiązać z Tobą stały bezpośredni kontakt ? (mail,gg,skype)

          • E-mail do mnie znajdziesz tutaj: https://wpzen.pl/kontakt/

  • Grzegorz

    Dziękuję za materiał! Prima sort poradnictwo taktyczne! :)
    Zastanawiam się tylko, czy cache nie wpłynie na działanie http://adaptive-images.com/, z którego korzystam. Chodzi o odpowiednio szybkie utworzenie cookie i „przekierowanie” w Apache adresu pobierania grafiki.

    • Adaptive Images robi przekierowanie w pliku .htaccess, tak więc jeśli dodasz jego kod do pliku .htaccess wygenerowanego przez WP Super Cache, to wydaje mi się, że powinno to razem działać.

  • Servitium

    Przetestowałem wiele wtyczek do przyśpieszania i na różnych stronach używam różnych, ale ostatnio ze względu na łatwość konfigurowania zainwestowałem w „WP-Rocket”

    • Nie miałem okazji testować WP Rocket, ale czytałem o niej dużo dobrego.

  • Kasia Świderska

    Bardzo fajny wpis, bardzo mi się dziś przydał. Sporo udało mi się urwać z czasu ładowania strony i teraz śmiga jak trzeba :D

  • Darek

    Czy ktoś mi może zainstalować tą wtyczkę ? Bo jak próbowałem to znikła strona ! Nie wiem o co chodzi :(

  • Witam, czy kolejność włączania wtyczek ma znaczenie? włączyłem najpierw wtyczkę Autoptimize, ale niestety rozwaliło mi stronę . Czy istnieje też jakaś alternatywa dla tej wtyczki bez ręcznego wpisywania kodu?

    • Generalnie kolejność włączania wtyczek nie ma znaczenia, ale nie bardzo wiem do czego zmierzasz…

      Co to znaczy „rozwaliło mi stronę”? Co to znaczy „alternatywa (…) bez ręcznego wpisywania kodu”? Jakiego kodu?

      Jeśli szukasz pomocy, to poświęć proszę chwilę na napisanie swoich pytań w sposób zrozumiały, tak żebyśmy nie musieli się wszystkiego domyślać.

    • Paweł Knapek

      Kolejność czasem ma znaczenie ….ale raczej nie w tym przypadku. Tutaj co najwyżej trzeba odświeżyć pamięć podręczną Autoptymize, by sobie zaktualizował zoptymalizowane wersje skryptów i styli.
      Co do rozwałki, to patrz komentarz wcześniej – może to być kwestia doboru odpowiednich ustawień wtyczki.

  • po włączenie wtyczki autoptimize strona straciła spójny wygląd tak jak by zniknął szablon strony i chodziło mi o alternatywę dla tej wtyczki by zoptymalizować kody HTML, JS, CSS

    • Paweł Knapek

      A może problem nie we wtyczce, tylko w jej konfiguracji?
      Autoptimize nie jest zła, ale nie zawsze wszystkie jej opcje są odpowiednie dla danej strony.
      Pod jedną trzeba ją inaczej skonfigurować, pod inną inaczej.
      -tak jest z wieloma bardziej zaawansowanymi czy specializowanymi wtyczkami …zwłaszcza w zakresie optymalizacji.
      Można posłużyć się w3totalem, Better WordPress Minify albo innymi, można tez ręcznie optymalizować – nie ma tu chyba rozwiązania totalnie bezobsługowego i zawsze, wszędzie idealnie działającego.

    • Najprawdopodobniej któryś z CSSów źle zniósł kompresję i/lub scalenie. Spróbuj (jak już napisał Paweł) pokombinować z konfiguracją, wykluczaniem CSSów i JSów itp.

  • Tak dokładnie wina po stronie konfiguracji :) CSS źle znoszą kompresję i scalanie :)

  • Ustawiłem wtyczkę kierując się propozycjami zawartymi w artykule, i zniknął panel logowania a podstrony wyświetlają się w formie znaków- i teraz nie wiem czy wina leży po stronie ustawień wtyczki czy istnieje też inna opcja?

    • To najprawdopodobniej wina wtyczki Autoptimize – pokombinuj z jej konfiguracją albo po prostu ją wyłącz.

  • no niestety super cache powoduje problemu na samej wtyczce Autoptimize działa poprawnie

    • Paweł Knapek

      Znowu prawdopodobnie kwestia doboru odp. ustawień.
      W Super Cache wyłącz kompresję, wyklucz stronę logowania z keszu, wyczyść cache i sprawdź ponownie.

  • Dzięki za podpowiedz o czcigodni, kompresja wyłączona i faktycznie nie powoduje konfliktu- strona trochę szybciej się ładuje :) czy dla porównania moglibyście polecić opis, gdzie poczytać na temat działania wtyczki W3 Total Cache ?

    • Paweł Knapek

      Swego czasu Bartosz robił prezentację o W3 >> https://wpzen.pl/na-wordcampie-wroclawiu-bede-opowiadal-o-przyspieszaniu-wordpressa/
      Możesz tez wstukać w Google: „konfiguracja w3 total cache” etc. – to wyskoczy kilka opisów.

      Ale w tym przypadku odradzam. Wtyczka wymiata, ale ma bardzo rozbudowany konfig – wymaga dedykowanych ustawień pod konkretną stronę i platformę na jakiej jest ona hostowana.
      Zdecydowanie nie jest to zabawka dla początkujących.

  • Aneta

    Może głupie pytanie ale jak się ma taki cache do np. tracking code’ów Google? Nie zaburzy to statystyk? Pozdrawiam.

    • O ile nie tworzysz kodów śledzących dynamicznie (a na 99% nie tworzysz), to wszystko będzie działać OK.

  • Rodia

    WP Super Cache jest wygodną i sprawnie działającą wtyczką wyraźnie akcelerującą pageload ale….niestety problemy pojawiają się z nią wraz z obsługą strony przez SSL, TLS, wtedy pozostaje W3 Total Cache

    • Możesz napisać coś więcej na temat tych problemów?

      • Rodia

        Do momentu kiedy uruchomiłem cert.SSL WPSCache działał bez zarzutu potem zaczęły się problemy z funkcjonowaniem serwisu, które zniknęły po instalacji W3 Total Cache co znalazło potwierdzenie https://wordpress.org/support/topic/plugin-wp-super-cache-is-ssl-messing-up-my-cache?replies=7

        • Dzięki za informację.

          Czy w Twoim przypadku korzystasz z SSL (https) na całej stronie czy tylko w panelu administracyjnym?

          • Rodia

            Full on. Zmodyfikowałem bazę i linki w serwisie, resztę poprawił plugin SSL Insecure Content Fixer -polecam przy przejściu na https – pomimo to WPSC powodował problemy m.in. z logowaniem. Ustawienie PHP mode niczego nie zmieniło.

  • Rodia

    Do momentu kiedy uruchomiłem cert.SSL WPSCache działał bez zarzutu a potem „Test Cache” rozjechany -failed,
    skrypty .js nie startowały na stronie. Sytuację próbowałem poprawić poprzez add_filter( ‚https_local_ssl_verify’, ‚__return_false’ );
    poprawiłem tylko Test Cache – passed, reszta bez zmian….. Teraz analizuje gdzie może tkwić problem WPSCache +TLS u mnie. Niemniej po uruchomieniu W3 Total Cache +TLS serwis działa normalnie…i subiektywnie szybciej…

  • trzepak

    A czy jest możliwość zrobienia czegoś takiego?

    Mam na swojej stronie http://meteoserwis24.pl/ skrypt który generuje obecną mapę pogody (robi to na początku każdej godziny) jaki dodać zapis w htacess aby ta grafika nie była cachowana, tylko przy każdym otwarciu strony była wczytywana z serwera?

  • Dzięki Tobie poprawiłem swój wynik o jakieś 1.3-1.5 sekundy. Wielkie dzięki :)

  • Aga

    a u mnie występuje taki problem, że każde dodanie komentarza na blogu usuwa cały cache mimo iż mam włączoną opcję cachowania tylko bieżącej strony na której dodwanay jest komentarz. Ktoś wie jak zrobić, żeby nie kasowała po każdym komentarzu całego cacheu?

  • Dziękuje za tak dobry artykuł. Dzięki niemu i narzędziu PageSpeed Insights poprawiłem wyniki swojej strony. Będę go polecał moim przyszłym użytkownikom. ;)

  • Mi po zainstalowaniu wtyczki wywaliło szablon w wersji mobilnej. Najdziwniejsze jest to, że strona na moim telefonie działa również na: http://www.messidesign.pl/sprawdz-responsive-design.html?check=true ale nie przechodzi Testu zgodności z urządzeniami mobilnymi na stronie googla. Funkcję Mobile device support odznaczyłem. Jakieś sugestie? polubiłem wtyczkę bo łatwa w obsłudze.

    • Twoja strona jest responsywna, tak więc nie ma na niej czegoś takiego, jak wersja mobilna. Trudno stwierdzić coś więcej, bo w tej chwili wtyczka cache jest (o ile się nie mylę) wyłączona, ale szczerze wątpię, że mogła ona cokolwiek popsuć w kwestii responsywności strony i jej zgodności z urządzeniami mobilnymi.

      • Wtyczka jest włączona, ustawienia takie same jak powyżej na Twoim wpisie. Jedyne co zauważyłem to nie działa strona główna ale tylko w teście zgodności z urządzeniami mobilnymi na stronie googla. Dziwne. Gdy wtyczka jest wyłączona to wszystko działa. Nawet test wychodzi szybciej na PageSpeed Insights nieznacznie (serwer wolny) dlatego rozważam cloudflare gdyż jest możliwość otworzenia konta za darmo. Tylko pytanie jest czy darmowe konto jest wystarczające.

        • Jeśli w tej chwili wtyczka cache jest włączona, to ja nie widzę żadnych problemów ze stroną – ani w przeglądarce, ani w teście Google.

          CloudFlare to dobra usługa, ale zastanów się czy w Twoim przypadku korzystanie z niej cokolwiek zmieni.

  • Kamil Nowak

    Witam. Jeśli parametr w googlach przed i po włączeniu tej wtyczni pozostaje taki sam, to czy ona działa poprawnie? https://developers.google.com/speed/pagespeed/insights/ Dodatkow, cały czas mam pusty folder w zakładce „contents” – może coś źle ustawiłem?

    • Wynik w Google PageSpeed, mimo że nie jest najważniejszy, to powinien się chociaż trochę zmienić. Bardzo możliwe, że coś źle ustawiłeś, ale mam problemy z jasnowidzeniem, tak więc nie jestem w stanie powiedzieć nic więcej. ;)

  • Zbigniew

    A czy planuje autor jakieś porównanie miedzy wtyczką ZENcache?

    • Nie mówię „nie”, ale porównywanie bardzo podobnie działających wtyczek (szczególnie na testowych stronach bez ruchu) nie jest proste. Ale zobaczymy. ;)

  • Krzysztof Milewski

    Jak sprawdzić czy mam u mnie włączony filtr wpsc_cachedata? Mam włączony dynamiczny cache i na wpisach mam licznik wyświetleń wpisu. W panelu administracyjnym pokazuje mi, że licznik danego wpisu się zwiększa ale na wpisie stoi. Natomiast jak weszłem na ten wpis w innej przeglądarce to licznik pokazał dobrze czyli więcej wejść. Na dodatek w tej drugiej przeglądarce jedne liczniki we wpisach pokazują dobrze inne źle. Czy coś mam źle ustawione? Z góry dziękuję za odpowiedź.

  • wdrożyłam zalecenia (zaznaczyłam pola) z zakładki easy i advanced, a narzędzie PageSpeed Insights dalej zaleca „włącz kompresję” jak sobie z tym poradzić?

  • Bardzo dobry i przydatny artykuł. Pozdrawiam ;)

  • Onliniak

    Wtyczka była dobra na 4.4, w obecnej wersji zmienia kodowanie albo coś w konfiguracji namieszałem :�’�9��$�/�R��x2″��8}N����ۧON������u�����:ݖ�Z��G �-��-��j�WDF ��u�t�]�R�:������1Ѵ���ON���N>�zE=X_��~@Zdggd:-����N��x�un�V�(� p���K�Eך�3}豢�mnp��Ҕ�P;���7��w����O��m�őglg�0_�.�Q�T= ��=������>#J*E�����ے��)���T}�5y7�.��i/_␅�xy[U�Ssd��.�O��!�p��`���?��/�o�����wB �ǎ��!�;�u��!/�����R�{� V4�y����=��-�����;x�fN���G���iw�”��x���j��c��=�y�ҡB���h�G�b��x��:8�b�d�֑�J��`�[ʷ�_���� ����q����NT���i���^�:S�M��&�TX��[Y�&�Y ��@qB�������P��`�uP�O���O�廌J�V*��G�����Ӊ�bX*��>��f�|%�N�O�XU�p`0��ޅ��sY�Ku�@�5�������|DE�L��G0�&�� L���;��oY�d�q�C%hY�Aɝ����-Dm�d�����S`/=$/X򔷽e-�w��:��˷��aR2 o�ZsFZ�C.B6��W��$L���ln���t�EǢ�V�Z>;�zAu�u��j!��Hj’B�”��J�D��Z���4��?{m[P�K���_��ې���C/ߑ��Lj�S�l>��] �� �6�(ְn ���2�)���,A�:~]{3H{L�@c0���/QIl;&�h��Y�;ĠU��Զ�b���Hڬ�f�ٟ�]�=8?���3!��c������[��c��Au� ��J�s�2Ϧ8yЋ�f� ���C������A]Sy��P���[)�_�cE”LsM3|�/��r��sj�U���x���4P����3��5#��{���b����AG���:厡������+��r��Jl�����m��G�_��N��A���%g%&�v �&v��۱��=o�lN� co ciekawe gator cache nic nie psuje …

  • Łukasz Kowal 

    Artykuł już trochę ma ale tak w zasadzie to nie ma w sieci równie przydatnego poradnika. Ja chciałbym doprecyzować jedną sprawę bo nie do końca mogę zrozumieć i nie chcę popełnić błędów. Wiadomo, że preload odświeża listę stron, w moim przypadku sklepu na woocommerce. Załóżmy, że ze względu na listę polecanych produktów, komentarzy itp ustawię sobie preload na 1440 (co 24 godziny). Nie wiem jeszcze ile ustawić stron w jednorazowym przeładowaniu cache ale będę eksperymentował z wydajnością serwera. Jeśli jednak ustawię 100 a cała witryna posiada 500 to cały cache odświeży mi się w ciągu 5 dni?
    Drugą sprawą jest Expiry Time & Garbage Collection. Czy to ustawienie jest niezależnym mechanizmem od preload? Ja to rozumiem tak, że oprócz aktualnych plików w cache znajdują się równorzędnie pliki przeterminowane, przeznaczone do usunięcia po jakimś tam czasie. Przechowywane są na wypadek gdyby robot lub użytkownik wszedł na nie wygenerowaną jeszcze stronę? Czy mam rację? Jednakże w przypadku włączenia preload na stronie Expiry Time & Garbage Collection widnieje komunikat Warning! PRELOAD MODE activated. Supercache files will not be deleted regardless of age. Czy to oznacza, że w takim przypadku opcja ta nie działa i cache pracuje na parametrach preload?
    Poproszę autora wpisu o pomoc w zrozumieniu tych zależności… :)

    • Artykuł rzeczywiście ma już grubo ponad rok, ale wciąż jest aktualny, bo we wtyczce WP Super Cache nie zmieniło się w tym czasie zbyt wiele. Bardzo dziękuję za miłe słowa o jego przydatności. :)

      1. Teoretycznie przy takich ustawieniach Twoja strona odświeżyłaby się całkowicie w ciągu 5 dni. Ale pamiętaj, że na przykład w momencie publikacji nowego komentarza czy wpisu (zależnie od ustawień) część cache również jest odświeżana. Tak więc najczęściej odświeżenie całego serwisu zajęłoby mniej czasu. Nie wiem na ile podane przez Ciebie liczby odzwierciedlają rzeczywistość, ale przy 500 stronach ja wyłączyłbym preload i został przy automatycznym usuwaniu starych plików cache co jakiś sensowny czas (godzina, dwie, cztery – zależnie od liczby nowych treści pojawiających się w ciągu godziny). Korzystanie z preloadera ma sens w przypadku naprawdę dużych serwisów ze sporym ruchem.

      2. Jeśli włączysz preload mode, to garbage collection nie działa dla stron, dla których preloader wygenerował już cache (czyli ostatecznie nie działa w ogóle, bo w końcu wszystkie strony zostaną przetworzone przez preloader). W cache znajdują się oczywiście „przeterminowane” pliki cache, ale nigdy nie występuje sytuacja, w której w cache jest plik aktualny i przeterminowany – jeśli któryś z procesów wygenerował aktualny plik cache, to plik przeterminowany jest usuwany. Generalnie używanie jednocześnie garbage collectora i preloadera mija się trochę z celem, bo te dwa mechanizmy nawzajem sobie przeszkadzają. ;)

      Co do stron bez cache, to działa to mniej więcej w taki sposób, że jeśli ktoś wchodzi na stronę, dla której nie ma jeszcze wygenerowanego cache, to cache ten jest tworzony (niezależnie od ustawień preloadera), użytkownik dostaje strone wygenerowaną „na żywo”, a kolejny użytkownik dostanie już stronę z cache.

      Mam nadzieję, że chociaż trochę pomogłem. ;)

    • Jeszcze jedna uwaga do punktu 1. Jeśli cache ma się odświeżać co 24 godziny, to po 24 godzinach wszystkie wygenerowane już pliki przestaną być „ważne” i zostaną zakwalifikowane do ponownego wygenerowania, mimo że cała strona nie została jeszcze „przetworzona”. Szczerze mówiąc nie wiem co się w takiej sytuacji stanie…

    • No to jeszcze jeden komentarz a propos punktu 1, bo napisałem Ci nieprawdę. ;)

      Jeśli ustawisz porcję stron do wygenerowania na 100, to nie oznacza to, że wtyczka będzie generować 100 stron co 24 godziny. Po wygenerowaniu 100 stron kolejny proces zostanie uruchomiony 30 sekund później. Zakładając, że cache dla 100 stron generuje się 1 minutę, cache dla 500 stron powinien wygenerować się w ciągu 5 minut + 150 sekund, czyli 7,5 minuty.

      • Łukasz Kowal 

        Mój serwis (sklep na woo) będzie miał docelowo około 500 stron w witrynie. Chcę ustawić odświeżanie na 24 godziny ze względu na polecane produkty, klienci kupili również i powiązane produkty. Poza tym pozostaje listing produktów na stronach kategorii. Produkty się zmieniają, ubywa ich (sprzedaję tylko dostępne sztuki i tylko one są widoczne).
        W drugim swoim serwisie gdzie treść zmienia się co trzy tygodnie, preload i wygaśniecie wogóle wyłączyłem a cache stron generuję podczas ich edycji.
        W odniesieniu do tych dwóch systemów czyszczenia cache wolał bym osobiście preload co 24 godziny w ustawieniu 20 stron na jeden raz (wolałbym aby użytkownik wszedł na stronę już w cache wygenerowaną niż dopiero generowaną w locie – krótszy czas dostępu, mniej odrzuceń podczas oczekiwania na wygenerowanie) w założeniu, że generowanie kolejnej paczki odbywa się co 30 sekund (można tą wartość gdzieś zmieniać?). Wobec tego preloader odświeża strony według swojego harmonogramu nie patrząc się na garbage collection i to co wygenerowane siedzi przez 24 godziny?
        Rozumiem więc, że w przypadku moich preferencji mogę wyłączyć mechanizm Expiry Time & Garbage Collection i oprzeć się jedynie na preloaderze?

        Jeśli chodzi o Twoje artykuły to trzymaj tak dalej bo dotykasz tematów jakie są prawie wogóle nie podejmowane i stanowią na prawdę solidną dawkę wiedzy :)

        • Słuszna uwaga co do wchodzenia na stronę z już wygenerowanym cache – szybkość przede wszystkim. ;) Tych 30 sekund nie można niestety nigdzie zmienić – jest to „zaszyte” w kodzie wtyczki.

          Jest dokładnie tak, jak piszesz – preloader odświeża cache według swojego harmonogramu, a garbage collector nie rusza tych plików. Możesz więc spokojnie wyłączyć garbage collector.

          I jeszcze raz dziękuję za miłe słowa. :)

          • Łukasz Kowal 

            Mam jeszcze jedno pytanie, sytuacja jaką właśnie zaobserwowałem. W mojej witrynie mam ustawioną stronę o nazwie home jaką stronę główną. Nie wiem dlaczego ale plik index-https.html generowany jest dopiero po wejściu na stronę. Wszystkie inne strony produktów oraz taxonomie i strony informacyjne generowane są zgodnie z ustawieniami preloadera.

          • Łukasz Kowal 

            W zasadzie to zdarza się cacheować stronę główną ale po chwili obecności na liście w folderze cache plik znika – jest usuwany. Nie wiem dlaczego. Tak jakby dla pliku strony głównej czas życia cache był jakiś inny narzucony przez wtyczkę. Może da się to zmienić?

          • Spróbuj wyłączyć opcję ‚Extra homepage checks’.

          • Łukasz Kowal 

            Tą opcję miałem wyłączoną więc jeszcze raz wszystko przepatrzę i może dojdę do tego gdzie leży problem. Mam nadzieję, że to nie przez SSL i włączoną autoptimize.

          • Łukasz Kowal 

            Niestety nie znalazłem nic co mogło by nakierować mnie na rozwiązanie problemu. Chyba konieczna będzie zmiana wtyczki na w3tc

          • Łukasz Kowal 

            Podczas testowania cache jest taki komunikat i to chyba przyczyna problemu ale nie bardzo rozumiem jak to rozwiązać

            Test your cached website by clicking the test button below.

            Fetching https://lavivre.pl/ to prime cache: OK

            Fetching first copy of https://lavivre.pl/: OK (1.html)

            Fetching second copy of https://lavivre.pl/: OK (2.html)

            The pages do not match! Timestamps differ or were not found!

            Things you can do:

            Load your homepage in a logged out browser, check the timestamp at the end of the html source. Load the page again and compare the timestamp. Caching is working if the timestamps match.

            Enable logging on the Debug page here. That should help you track down the problem.

            You should check Page 1 and Page 2 above for errors. Your local server configuration may not allow your website to access itself.

            Send non-secure (non https) request for homepage

          • Ten komunikat występuje dlatego, że masz wyłączone informacje diagnostyczne – pojawiają się one w źródle strony i są używane do tego testu.

  • Wielkie dzięki za ten artykuł – dla mnie, zielonej, przebrnięcie wymagało dwóch kaw i sześciu kasztanków (a d*** rośnie ;)), ale bardzo dużo pomogło… Bez tego pewnie włączyłabym tylko wtyczkę i nie ruszała, żeby nie popsuć. Albo usilnie szukała gdzieś strzępów wskazówek co i jak.

    Ogromna pomoc. Megadokładne ujęcie tematu. Bardzo si :) Dzięki raz jeszcze :)

  • Łukasz Kowal 

    Jeśli chodzi o funkcję garbage collection, to pomimo ustawienia cache timeout na 0 to w dalszym ciągu dla strony głównej cache usuwa się według ustawień sheduler. Nie da się go wyłączyć.

    • Masz włączoną opcję Extra homepage checks?

      • Łukasz Kowal 

        Nie nie mam tej opcji włączonej. Te problem dotyczy tylko plików strony głównej po https. reszta podstron zachowuje w cache swoje katalogi.

      • Łukasz Kowal 

        Rozwiązaniem tego problemu okazał się litespeed. Na serwerze z tym oprogramowaniem nie działa dobrze cacheowanie. Po włączeniu wtyczki na innym serwerze apache wszystko działa idealnie. Z tego co wiem to autoptimize też ma problemy na litespeed więc coś chyba jest na rzeczy.

  • TTBoS

    Hmm, a co w przypadku:

    Zlib Output Compression Enabled!

    PHP is compressing the data sent to the visitors of your site.
    Disabling this is recommended as the plugin caches the compressed output
    once instead of compressing the same page over and over again. Also see
    #21 in the Troubleshooting section. See this page for instructions on modifying your php.ini.

    Za bardzo nie wiem co mam z tym zrobić ;<

    • Paweł Knapek

      A czytałeś w FAQ pod wskazanym punktem?

      „If you see garbage in your browser after enabling compression in the plugin, compression may already be enabled in your web server. In Apache you must disable mod_deflate, or in PHP zlib compression may be enabled. You can disable that in three ways. If you have root access, edit your php.ini and find the zlib.output_compression setting and make sure it’s „Off” or add this line to your .htaccess:

      php_flag zlib.output_compression off If that doesn’t work, add this line to your wp-config.php:

      ini_set(‚zlib.output_compression’, 0);”

  • W którym miejscu we wtyczce Autoptimize włącza się Expires? Szukam i znaleźć nie mogę (a tych opcji jest kilka na krzyż).
    „W praktyce sprowadza się to do ustawienia plikom odpowiednich nagłówków Expires. Można to zrobić wspomnianą już wtyczką Autoptimize”

    • Trochę nieprecyzyjnie to napisałem. Autoptimize ustawia nagłówki Expires dla złączonych przez siebie plików JS i CSS, nie dla całego serwisu.

  • 538

    Witam,

    Mam problem z GZIP.

    Skonfigurowałem wtyczkę według instrukcji. Strona http://checkgzipcompression.com/ nie waliduje mi GZIP.

    • Być może na Twoim serwerze nie ma zainstalowanego odpowiedniego modułu. Zwróć się z tym do firmy hostingowej, z której usług korzystasz.

    • w jakiej firmie masz hosting?

  • Po raz kolejny potrzebowałam skonfigurować wtyczkę WP Super Cache i po raz kolejny podążałam za instrukcjami zawartymi w artykule. Za pierwszym razem znalazłam go przez Google, za drugim już pamiętałam. Z kilku różnych, które wówczas (za tym pierwszym razem) przeczytałam, tylko ten był tak pełny i opisany krok po kroku, a porady zostały wyłożone jak krowie na rowie. W innych były trzy hasła na krzyż i autoreklama autora, szkoda słów. W każdym razie jestem baaardzo wdzięczna za artykuł, bo w wielu sytuacjach WP mnie po prostu przerasta. Dzięki! :)

  • Michał

    Na początku wielkie dzięki za szczegółowe opisanie wtyczki – dołączam się do wszystkich słów uznania.
    Nie rozumiem tylko jednej sprawy – jeśli mam ustawione czyszczenie cache po dodaniu nowego wpisu (i wyłączony czas życia cache zgodnie z sugestią), to czy to oznacza, że w miejsce starego cache automatycznie wejdzie nowy, kiedy dodam post? O ile dobrze zrozumiałem, to po dodaniu posta (lub zmodyfikowaniu) następuje taka sytuacja, że pierwszemu odwiedzającemu stronę wszystko ładuje się długo. Może jest taka możliwość, żeby preloader uruchamiał się wtedy, kiedy aktualizuję stronę? Prowadzę stronę na której nowy post pojawia się co kilka dni – nic więcej nie jest zmieniane ( http://www.wsdts.pl ), więc po co odświeżać cache lub uruchamiać preloader często – wolałbym tylko przy okazji publikacji. Da się zrobić coś takiego?

    Z góry dziękuję za pomoc!

    • Opcje masz dwie. Albo czyścisz cały cache po publikacji nowego wpisu i pierwszy odwiedzający musi go wygenerować (czyli strona będzie mu się ładować dłużej), albo nie czyścisz całego cache po publikacji nowego wpisu i czekasz na samoczynne jego odświeżenie (nie „wyłączasz” czasu życia cache). Niestety, proponowanej przez Ciebie opcji pośredniej nie ma. ;)

      Natomiast od momentu napisania tego wpisu moje spojrzenie na działanie cache nieco się zmieniło i dzisiaj już bym nie rekomendował czyszczenia całego cache po publikacji nowego wpisu.

      • Michał

        No, ale jeśli nie wyczyścisz cache po publikacji posta, to przez pewien czas się nie będzie wyświetlał – przez pewien czas – do odnowienia cache. Opcją pośrednią może być wejście osobiście na stronę przez okno incognito, żeby cache się odświeżył.

        • Ale cache się wtedy nie odświeży.

          • Michał

            Chodziło mi o sytuację, że mamy ustawione czyszczenie cache po dodaniu/zmodyfikowaniu posta.

  • Barti

    Wyrzuciło mi taki komunikat:

    Zlib Output Compression Enabled!
    PHP is compressing the data sent to the visitors of your site.
    Disabling this is recommended as the plugin caches the compressed output
    once instead of compressing the same page over and over again. Also see
    #21 in the Troubleshooting section. See this page for instructions on modifying your php.ini.

    O co chodzi z tym?

  • Artur

    używam wtyczki Widget logic do sprawdzenia czy jest spełniony konkretny warunek i wtedy pokazuje widzet na stronie

    prosta funkcja w pliku functions.php

    function test()
    // $cos – wynik z bazy

    {
    if($cos == 1){
    return true
    else{
    return false
    }

    Dane w bazie zmieniam napisaną przez siebie wtyczką, czy jest jakaś możliwość żeby dopisać kod do mojej wtyczki żeby czyścił cache jak dokonam zmian w bazie bo teraz muszę czekać aż cache wygaśnie żeby pojawił się lub zniknął widget?

    • Możesz we własnej wtyczce wymusić wyczyszczenie cache przez wywołanie funkcji wp_cache_clear_cache().

  • Używa ktoś na witrynie wtyczkę WP Statistics + WP Super Cache? Zauważyłem, że po uruchomieniu WP Super Cache prezentowane statystyki na blogu w PA od tej wtyczki mocno poleciały do dołu (co najmniej o połowę poprzednich wartości). Zrobiłem testy tygodniowe z włączoną/wyłączonym cachem i ewidentnie są to efekty po włączeniu WP SC. Ktoś ma sugestie co może być tego przyczyną?

    • https://pl.wordpress.org/plugins/wp-statistics/#faq

      Does WP Statistics work with caching plugins?
      Probably not, most caching plugins don’t execute the standard WordPress loop for a page it has already cached (by design of course) which means the WP Statistics code never runs for that page.

      Czyli w skrócie: ta wtyczka nie działa z wtyczkami cache.

  • Opróżnianie domów i mieszkań W

    Bardzo szczegółowy poradnik :-). Naprawdę jestem pełen uznania :-)
    Po wprowadzonych przez Ciebie rozwiązaniach punktacja w pagespeed wzrosla natychmiastowo. Problemem jest tylko wtyczka optimizer która niestety zaniżała wszystkie wyniki ale ma to może związek z hostingiem w home.
    Dzięki jeszcze raz i gratuluje wiedzy w temacie :-)

  • Michał Nowotyński

    Może to głupie pytanie, ale czy strona bez tych wtyczek będzie dużo wolniejsza? Do dzisiaj używałem WP Super Cache, ale ponieważ zaczęły pokazywać mi się jakieś błędy (z którymi sam nie mogę sobie poradzić), strona zaczęła się wieszać, to ją wyłączyłem zupełnie…
    Po wyłączeniu wtyczki strona działa teraz bez zarzutu, nie zauważyłem też żeby zwolniła (oczywiście będę obserwował co będzie dalej).
    Krótko mówiąc – czy bez WP Super Cache da się żyć? :)

    • Pytanie nie jest głupie, ale trudno na nie udzielić jednoznacznej odpowiedzi. ;) Po prostu czynników, które mają wpływ na szybkość działania strony, jest zbyt wiele. Jeśli Twoja strona została zbudowana w optymalny sposób, nie jest przeładowana zbędnymi wodotryskami i działa na porządnym serwerze, to jest spora szansa, że poradzi sobie bez cache. Nie oznacza to jednak, że problemy nigdy się nie pojawią – wpływ na spowolnienie strony może mieć wzrost (znaczny) ilości treści na stronie czy duży wzrost ruchu (to w tym przypadku tak naprawdę cache pokazuje swoje zalety).

      Jeśli obiektywnie (zmierzyłeś to) Twoja strona działa tak samo szybko bez cache, to nie ma powodów, dla których nie mógłbyś jej tak zostawić. Oczywiście stałe obserwowanie zachowania strony jest dobrym pomysłem.

      • Michał Nowotyński

        Strona jednak zwolniła (Polskie Drogi). Miesięcznie odnotowuje ponad 700 tys. odsłon, więc możliwe, że ruch miał na to wpływ.
        Musiałem więc wypróbować coś innego. Zainstalowałem wtyczkę WP Fastest Cache, która w przypadku PD zadziałała znakomicie. Wtyczka jest prosta, łatwa, przyjemna i skuteczna.
        Nie wiem jak patrzą na nią osoby mocno zorientowane w temacie WP, ale dla osób zorientowanych na poziomie podstawowym (czyli takich jak ja) myślę, że opcja warta rozważenia. Ok, nie zabieram więcej czasu.

        • Słyszałem i czytałem sporo dobrych opinii o WP Fastest Cache, ale sam nigdzie jej nie używałem (poza krótkimi testami na lokalnej instalacji WP).

        • Paweł Knapek

          WP Fastest Cache jest bardzo fajna. Może od strony kodu nie powala, ale funkcjonalnie daje radę.
          Natomiast prawda jest taka, że wszystko zalezy od środowiska w jakim działa strona. Jaki serwer, gdzie i o jakich parametrach, jak skonfigurowany, do tego sama strona i co w niej siedzi. Nie zapominając już o sposobie konfiguracji samej wtyczki – wszystko to ma wpływ.
          Bo nie ma jednej słusznej metody i jednej jedynej właściwej wtyczki – zależnie od przypadku, jedno rozwiązanie może się sprawdzać czasem lepiej, inne gorzej – to już trzeba intuicyjnie i metodą prób i błędów dochodzić.
          Najczęściej właśnie WP Fastest Cache lub WP Super Cache leci, czasem jednak sytuacja wymaga np. LiteSpeed Cache albo W3 Total Cache.

  • Nie wiem czemu ale niektóre ze stron gdzie używam tej wtyczki od niedawna nie pozwalają mi zrobić zmian w pliku .htaccess po kliknięciu na przycisk „Update Mod_Rewrite Rules”. Może stało się tak po jednej z kolejnych aktualizacji WP Super Cache choć ciężko mi odnotować której konkretnie.
    Co ciekawe po przyciśnięciu przycisku „Update Mod_Rewrite Rules” te zalecane zmiany wyświetlają mi się w ramce zielonej, taj jak gdyby udało się je wprowadzić ale po wyjściu i powrocie do ustawień wtyczki znowu dostaję je w żółtych ramkach z komentarzem jak poniżej:

    „Mod Rewrite rules must be updated!

    The plugin could not update /home/zal-z/ftp/.htaccess file: .htaccess not found: /home/zal-z/ftp/.htaccess.
    The new rules go above the regular WordPress rules as shown in the code below: ”

    Spotkałeś się może z podobną sytuacją lub masz pomysł o co chodzi?

    P.S. Po ręcznym wstawieniu na początek pliku .htaccess zalecanych w żółtych ramkach zmian nadal niestety ta informacja o konieczności ich wklejenia doń się pojawia :((