CDN i cache: konfiguracja dla szybkiego sklepu

Cache strony buduje gotowy HTML na serwerze, CDN rozsyla pliki blizej uzytkownika
Strony cache'ujesz dla niezalogowanych, koszyk i kasa zawsze swieze
ESI cache'uje statyczna czesc strony, a mini-koszyk podaje na zywo
Object cache na Redis odciaza baze przy ciezkich zapytaniach WooCommerce
Purge musi lapac zmiany cen i stanow, inaczej klient widzi stara oferte
[/dwb_keytakeaways]

Cache strony i CDN to dwie rozne rzeczy

Wiekszosc osob wrzuca cache i CDN do jednego worka, a to dwie osobne warstwy, ktore robia co innego. Zanim ustawisz cokolwiek w sklepie, warto zrozumiec te roznice, bo od niej zalezy cala dalsza konfiguracja.

• Cache strony: serwer zapisuje gotowy HTML danej podstrony, zeby nie budowac go od nowa przy kazdym wejsciu. Bez cache WordPress przy kazdej wizycie odpala PHP, pyta baze i sklada strone. Z cache podaje gotowy plik w ulamku sekundy.
• CDN (Content Delivery Network): siec serwerow rozsianych po swiecie, ktora trzyma kopie Twoich plikow statycznych (obrazy, CSS, JavaScript) blisko uzytkownika. Klient z Krakowa pobiera obraz z serwera w Polsce, a nie z drugiego konca Europy.
• Object cache: trzecia warstwa, ktora zapisuje w pamieci wyniki zapytan do bazy. Wraca do niej w kolejnym akapicie, bo w sklepie ma duze znaczenie.

W szybkim sklepie te warstwy graja razem. Cache strony skraca czas odpowiedzi serwera, CDN skraca droge danych do uzytkownika, a object cache odciaza baze. Mylenie ich konczy sie zwykle tym, ze ktos wlacza dwie rzeczy naraz, ktore sobie przeszkadzaja.

Co cache'owac w sklepie, a czego nigdy

To jest najwazniejsza decyzja w calej konfiguracji i miejsce, w ktorym najlatwiej zrobic blad. Sklep ma strony publiczne, ktore wygladaja tak samo dla wszystkich, i strony prywatne, ktore pokazuja dane konkretnej osoby.

Strony publiczne smialo cache'ujesz dla niezalogowanych uzytkownikow: strona glowna, kategorie, karty produktow, wpisy na blogu, strona kontaktu. To one daja najwiekszy ruch i najwiecej zyskuja na cache.

Strony prywatne musza byc zawsze swieze i nigdy nie trafiaja do zwyklego cache strony: koszyk, moje konto, kasa, strona platnosci. Pokazuja dane zalogowanej osoby, ceny po rabacie, zawartosc koszyka. Gdyby trafily do cache, klient zobaczylby cudze dane, a to katastrofa.

ESI: jak cache'owac strone z dynamicznym koszykiem

Pojawia sie tu naturalny problem. Karta produktu jest w wiekszosci statyczna, ale w naglowku masz mini-koszyk, ktory pokazuje liczbe produktow i kwote dla konkretnej osoby. Jak cache'owac strone, skoro jeden jej fragment jest zawsze inny?

Rozwiazaniem jest ESI (Edge Side Includes). To technika, w ktorej cache'ujesz statyczna czesc strony, a male dynamiczne fragmenty (mini-koszyk, powitanie zalogowanego klienta) podajesz na zywo. LiteSpeed Cache ma dedykowana sekcje WooCommerce wlasnie do tego. Dzieki temu karta produktu laduje sie z cache blyskawicznie, a mini-koszyk w naglowku zawsze pokazuje aktualny stan.

To wazna roznica wobec prostych wtyczek cache, ktore albo nie cache'uja stron ze zmiennym fragmentem, albo cache'uja je w calosci i pokazuja zly stan koszyka. ESI daje jedno i drugie: szybkosc cache i poprawnosc danych.

Object cache na Redis: odciazenie bazy

WooCommerce przy budowaniu jednej strony potrafi odpytac baze danych kilkadziesiat razy: ceny, stany, atrybuty, warianty, opcje. Przy malym ruchu baza wyrabia bez problemu. Przy duzym katalogu i ruchu z reklam zaczyna byc waskim gardlem.

Object cache zapisuje wyniki tych zapytan w pamieci RAM przez Redis. Zamiast pytac baze w kolko o te same dane, sklep siega po nie z pamieci w mikrosekundach. Efekt to mniejsze obciazenie bazy, stabilniejsze czasy odpowiedzi i mniej spowolnien przy szczytach ruchu.

• Maly sklep z dobrym cache strony: Redis nie jest niezbedny, cache strony zalatwia wiekszosc ruchu od niezalogowanych.
• Duzy katalog, wielu zalogowanych klientow, ruch z reklam: tu object cache realnie pomaga, bo zalogowani omijaja cache strony i kazda ich wizyta meczy baze.
• Sklep B2B z cenami po zalogowaniu: object cache czesto wazniejszy niz cache strony, bo prawie kazdy uzytkownik jest zalogowany.

Cloudflare jako CDN: obrazy i statyki blizej klienta

Cloudflare to najpopularniejszy CDN i w sklepie sprawdza sie do rozsylania plikow statycznych: obrazow produktow, CSS, JavaScriptu i fontow. Klient pobiera je z serwera blisko siebie, a nie z Twojego hostingu, co skraca czas ladowania, zwlaszcza przy duzej liczbie zdjec produktow.

Cloudflare laczysz z LiteSpeed Cache przez token API z uprawnieniem do czyszczenia cache strefy. Dzieki temu gdy LiteSpeed czysci cache po zmianie tresci, Cloudflare tez czysci swoja kopie i nie zostaje stara wersja. To kluczowe, bo CDN bez zsynchronizowanego purge potrafi miesiacami serwowac nieaktualny plik.

Jest jeden warunek, ktory latwo przeoczyc: nie wlaczaj cache strony w Cloudflare i w LiteSpeed jednoczesnie. Te dwie warstwy cache strony wchodza sobie w droge, a efektem sa nieaktualne strony i trudne do zdiagnozowania bledy. Cache strony zostawiasz LiteSpeed, a Cloudflare odpowiada za statyki i siec. Obrazy mozesz tez serwowac przez CDN obrazow z konwersja do WebP, co dodatkowo zmniejsza ich rozmiar.

Purge: kiedy i co czyscic

Cache jest tyle wart, ile jego odswiezanie. Jesli cache nie czysci sie po zmianie tresci, klient widzi stara oferte. Jesli czysci sie za czesto, tracisz korzysc z cache. Sztuka polega na tym, zeby czyscic dokladnie to, co sie zmienilo.

1. Zmiana ceny produktu: czysc cache tej karty produktu. Sama cene na karcie najlepiej pobierac swiezo przez AJAX, zeby nie czyscic calej strony.
2. Zmiana stanu magazynowego: czysc karte produktu, a kategorie odswiezaj tylko gdy zmienia sie status dostepnosci (z dostepny na niedostepny i odwrotnie).
3. Nowy wpis lub edycja tresci: czysc dana strone plus strony powiazane (strona glowna, lista wpisow).
4. Zmiana globalna (motyw, menu): czysc caly cache, bo zmiana dotyczy wszystkich stron.

LiteSpeed Cache ma do tego gotowe reguly w sekcji WooCommerce. Mozesz ustawic, zeby czyscil produkt przy zmianie stanu lub ilosci i odswiezal kategorie tylko przy zmianie statusu dostepnosci. To wlasnie ten poziom precyzji odroznia dobrze ustawiony sklep od takiego, w ktorym cache albo pokazuje stare ceny, albo czysci sie tak czesto, ze nie ma z niego pozytku.

Wplyw na Core Web Vitals

Cache i CDN najmocniej poprawiaja LCP, czyli czas, po ktorym pojawia sie glowna tresc strony. To dlatego, ze atakuja dwie najwieksze przyczyny wolnego LCP: powolna odpowiedz serwera i daleko polozone pliki.

• LCP: cache strony skraca czas odpowiedzi serwera, a CDN przyspiesza pobranie glownego obrazu. To zwykle najwiekszy zysk.
• CLS: posrednio, bo szybciej zaladowane obrazy z podanymi wymiarami rzadziej powoduja przeskoki ukladu.
• INP: cache nie naprawia ciezkiego JavaScriptu, ale odciazony serwer szybciej obsluguje zadania, wiec reakcja na klik bywa plynniejsza.

W praktyce sklep, ktory bez cache generuje strone w dwie albo trzy sekundy, po wlaczeniu cache strony i CDN schodzi czesto grubo ponizej sekundy do pierwszej tresci. Najwiekszy skok widac na telefonach w slabszym zasiegu, czyli dokladnie tam, gdzie Google mierzy dane terenowe.

Konfiguracja krok po kroku i czeste bledy

Kolejnosc prac, ktora daje najwiecej i najmniej problemow, wyglada tak:

Najczestsze bledy, ktore widze przy audytach sklepow, to zawsze ten sam zestaw. Po pierwsze, zacache'owany koszyk albo konto, bo ktos wlaczyl agresywny cache bez wykluczen. Po drugie, cache strony wlaczony jednoczesnie w Cloudflare i w LiteSpeed, co daje nieaktualne strony. Po trzecie, brak synchronizacji purge z CDN, przez co klient widzi stara cene, mimo ze w sklepie jest juz nowa. Po czwarte, wlaczony object cache bez dzialajacego Redis na hostingu, czyli ustawienie, ktore nic nie robi.

Jesli stawiasz sklep od zera albo chcesz przyspieszyc istniejacy, w DawidWeb robie to regularnie: konfiguracja LiteSpeed Cache pod WooCommerce, object cache na Redis, podlaczenie Cloudflare z poprawnym purge i pomiar Core Web Vitals przed i po. Strony i sklepy buduje od 1800 zl, jestem Partnerem Shoper, mam za soba ponad 120 projektow, a wycene konkretnego wdrozenia dostajesz w 24 godziny.