Podobno, jeśli tytuł artykułu zawiera pytanie, to odpowiedź na nie zazwyczaj brzmi „Nie”. W przypadku tego zagadnienia jest jednak inaczej…
Tak, cache’owanie może pogorszyć wydajność strony. Może wręcz tę stronę zabić. Przekonał się o tym właściciel pewnego sklepu internetowego.
Sytuacja, jakich wiele. Klient znalazł wykonawcę, zamówił sklep i go otrzymał. Strona zbudowana została na gotowym motywie. Gdy klient chciał jakąś dodatkową funkcjonalność, wykonawca znikał na jakiś czas, testował kilka wtyczek (wszystko na stronie produkcyjnej), a następnie zostawiał tę, która sprawdzała się najlepiej. Brzmi znajomo, prawda?
Efekt? Okazało się, że strona działa wolno.
A co się robi, gdy strona działa wolno? Instaluje się wtyczkę cache’ującą. Najlepiej od razu kilka, bo skąd mamy wiedzieć, która z nich da najlepsze efekty:
Cache niestety nie pomógł (nie miał zresztą prawa pomóc, bo w sklepie nie ma za bardzo co cache’ować – ale to już temat na zupełnie inny artykuł). Wykonawca zaczął więc włączać kolejne moduły wtyczki W3TC.
I tak po kilku podejściach do optymalizacji strony, cache’owane były już zapytania do bazy danych, obiekty WP oraz same strony… Wykonawca twierdził, że rozwiązał problem, bo narzędzia pomiarowe (Pingdom Tools, itp.) pokazywały szybkie czasy. Niestety rzeczywisty czas ładowania sklepu zaczął się zbliżać do 15 sekund, co nie cieszyło ani właściciela strony, ani jego klientów…
Co poszło nie tak?
Kilka rzeczy… których dałoby się uniknąć, gdyby wykonawca rozumiał, jak działa cache i WooCommerce.
- Nie da się cache’ować stron, które muszą być aktualne lub przedstawiają indywidualną treść. Zatem w sklepie tylko niewielki odsetek odsłon jest możliwy do obsłużenia przez statyczne strony trzymane w cache’u stron statycznych.
- WooCommerce przechowuje sesje i koszyki w bazie danych (przy użyciu mechanizmu transientów). Każdy użytkownik generuje nowy rekord, a tym samym zmusza cache do aktualizacji.
Ze względu na powyższe cechy, włączenie każdego dodatkowego modułu de facto spowalniało stronę. Przy każdej odsłonie sklepu serwis zamiast zadawać szybkie zapytania do bazy danych o konkretne rekordy, musiał:
- odpytać cache obiektów o istnienie konkretnego obiektu (obiektu nie było),
- odpytać cache bazy danych o istnienie konkretnego zapytania (zapytania nie było),
- odpytać bazę danych o konkretny rekord (rekordu nie było),
- utworzyć rekord w bazie danych
- utworzyć odpowiedni wpis w cache’u zapytań bazy danych (dla późniejszych zapytań),
- utworzyć odpowiedni wpis w cache’u obiektów.
Jeśli teraz dodam, że cache przechowywany był w formie plików na dysku serwera (oraz że serwer nie ma dysków SSD), to wszystko staje się jasne.
Czy w takim razie lepiej w ogóle nie używać cache’owania?
Używać, ale z głową, jak każdego narzędzia i tylko wtedy, gdy naprawdę jest nam ono przydatne, pomocne i potrzebne. Tak samo, jak nie każdą usterkę da się naprawić młotkiem – nie każdą stronę uda się przyśpieszyć dokładając jedynie kolejne warstwy cache’owania. Cache, tak samo jak młotek, może też czasem zaszkodzić…