Cloudflare dla PrestaShop — realne korzyści i granice

Cloudflare działa jako reverse proxy i CDN ustawiony przed serwerem sklepu. Cały ruch trafia najpierw do sieci Cloudflare i dopiero stamtąd, jeśli trzeba, do Twojego origin. Zasoby statyczne — obrazy, CSS, JavaScript, fonty — mogą być serwowane z węzła blisko użytkownika, bez angażowania serwera. Żądania dynamiczne, czyli wszystko, co PrestaShop generuje osobno dla każdego użytkownika, i tak wracają do origin.

Od razu ustawmy proporcje: to nie jest integracja „dla PrestaShop”. Cloudflare stoi tak samo przed WordPressem, Laravelem czy dowolną inną aplikacją PHP. Dlatego większość tego, co opiszemy, dotyczy każdego sklepu za takim proxy, a to, co wyróżnia PrestaShop, wynika z charakteru samego sklepu, nie ze specjalnego wsparcia po stronie Cloudflare.

O tym, ile Cloudflare pomoże, decyduje struktura ruchu konkretnego sklepu. Typowy PrestaShop to dużo zdjęć produktów, każde w kilku wariantach rozmiaru, do tego CSS, JavaScript i fonty motywu, ruch crawlerów indeksujących katalog, kosztowne dynamiczne żądania PHP i MySQL, okresowe skoki ruchu przy promocjach oraz sporo modułów i endpointów.

Z tego układu wynika prosta zależność, o której warto pamiętać przy każdej obietnicy przyspieszenia:

Korzyści z Cloudflare przed sklepem są konkretne, ale każda ma swój warunek brzegowy. Poniżej to, co zwykle widać w praktyce — bez obietnic, których ta warstwa nie jest w stanie spełnić.

Mniej ruchu i transferu na origin. Cache plików statycznych ogranicza liczbę żądań i ilość danych, które serwer musi obsłużyć samodzielnie. Największy efekt widać na obrazach i pozostałych zasobach statycznych oraz na ruchu, który Cloudflare zatrzyma jeszcze przed serwerem. Nie zakładaj przy tym automatycznego spadku CPU: samo wysłanie statycznego pliku rzadko obciąża PHP czy MySQL, więc oszczędzasz głównie na połączeniach, transferze i pracy web serwera.

Szybsze zasoby dla użytkowników z dalszych regionów. Obrazy, arkusze CSS, JavaScript i fonty mogą być pobierane z punktu Cloudflare bliżej użytkownika, zamiast za każdym razem z origin. To skraca czas ładowania tych zasobów, ale nie skraca czasu generowania dynamicznej strony — ten nadal zależy od Twojego serwera.

Większa odporność na część skoków ruchu. Gdy rośnie ruch na tym, co można obsłużyć lub odrzucić na brzegu, origin dostaje mniejsze uderzenie. Zastrzeżenie jest istotne: nagły wzrost żądań niecache’owalnych, takich jak koszyk, API czy wyszukiwarka, nadal potrafi przeciążyć backend, bo trafiają one wprost do PHP i bazy.

Filtrowanie części botów i ataków. Cache ogranicza powtarzalne pobrania statycznych zasobów, a mechanizmy ochrony przed botami zatrzymują część niechcianego ruchu przed serwerem. Uważaj tylko, żeby przy okazji nie blokować legalnych crawlerów bez analizy — Googlebot i tak pobiera dynamiczny HTML, więc teza „crawler mniej obciąża origin” nie jest bezwarunkowa.

Warstwa bezpieczeństwa przed serwerem. Cloudflare może zatrzymać część skanowania, automatycznych ataków, prób nadużyć i przeciążeń, zanim dotrą do PrestaShop. Nie naprawia jednak podatności w module ani nie zastępuje aktualizacji sklepu i serwera; luki w samym kodzie trzeba domykać po swojej stronie.

Obrazy: transformacje na brzegu. Cloudflare potrafi przetwarzać obrazy w locie — skalować, kadrować, optymalizować i dostarczać nowoczesny format — bez trzymania każdego wariantu na serwerze. W chwili aktualizacji tego artykułu plan Free obejmuje do 5000 unikalnych transformacji miesięcznie, gdzie „unikalna” oznacza kombinację źródłowego obrazu i parametrów, a nie każde wyświetlenie. Po przekroczeniu limitu na Free wcześniej wykonane transformacje nadal są serwowane z cache, a odrzucane są tylko nowe. To praktyczna alternatywa dla generowania wszystkich miniatur po stronie sklepu.

PrestaShop może generować zoptymalizowane formaty samodzielnie, a Image Transformations tworzą warianty rozmiaru i formatu na brzegu, bez przechowywania każdej wersji na origin. Który wariant wybrać, zależy od liczby zdjęć i wariantów, dostępnego miejsca, kosztu CPU oraz sposobu zarządzania obrazami w sklepie — żadne z tych rozwiązań nie wygrywa zawsze.

Dodatkowe dane i obserwowalność. Przy okazji dostajesz wgląd w ruch: statystyki, zdarzenia bezpieczeństwa oraz informację o tym, co jest odrzucane i cache’owane. To materiał, który później pozwala ocenić, czy wdrożenie faktycznie coś dało — do tego wracamy na końcu.

Na koniec uwaga o stacku: Cloudflare stoi przed nginksem, Apache’em i LiteSpeedem tak samo. HTTP/3 dotyczy przy tym połączenia użytkownika z siecią Cloudflare i nie oznacza automatycznie, że origin również obsługuje HTTP/3.

Cloudflare to warstwa przed serwerem, więc wszystko, co dzieje się już na serwerze, zostaje po Twojej stronie. Nie przyspieszy wolnych kontrolerów, niezaindeksowanych zapytań, rozbudowanych modułów ani przeciążonego PHP-FPM i MySQL. Nie pomoże, gdy stronę spowalnia zewnętrzne API blokujące jej wygenerowanie, nadmiar JavaScriptu w motywie, słaby hosting, wolny checkout, źle przygotowane zdjęcia źródłowe albo problemy z Core Web Vitals (wskaźnikami jakości ładowania strony) wynikające z renderowania i interakcji.

Dlatego Cloudflare nie zastępuje optymalizacji po stronie sklepu. Redis, cache PrestaShop, OPcache, indeksy w bazie, porządek w modułach i poprawna konfiguracja PHP dalej są potrzebne. Te rzeczy rozwiązują problemy na innej warstwie niż CDN i jedno bez drugiego nie wystarcza.

Nie licz też na cache całego HTML „z pudełka”. Automatic Platform Optimization, które robi to dla WordPressa, nie ma gotowej integracji z PrestaShop; podobny efekt trzeba zbudować samodzielnie, razem z poprawnym unieważnianiem cache. Najprościej zapamiętać zasadę: jeśli anonimowa strona jest wolna, bo origin długo ją generuje, warstwa brzegowa tego nie skróci. Zmierz najpierw, gdzie tracisz czas — jeśli wąskim gardłem jest backend, Cloudflare nie jest odpowiedzią.

Dla wielu sklepów plan Free jest dobrym punktem startu. Dostajesz CDN i cache statyki, podstawowe mechanizmy bezpieczeństwa, HTTP/3, możliwość budowania własnych reguł oraz — co mniej oczywiste — wspomniane 5000 unikalnych transformacji obrazów miesięcznie. To zwykle wystarcza, żeby ruszyć i zobaczyć, ile zyskujesz w praktyce.

Po płatny plan sięga się w odpowiedzi na konkretną potrzebę, nie „dla zasady”. Zwykle jest to jedna z poniższych sytuacji:

Większość problemów z Cloudflare przed PrestaShop nie wynika z samego Cloudflare, tylko z wdrożenia zatrzymanego w połowie. Dwa z tych błędów widać najczęściej i to one najbardziej mszczą się w produkcji, więc zaczniemy od nich.

Odsłonięty origin. Ustawienie „pomarańczowej chmury” w DNS nie sprawia, że serwer przestaje przyjmować połączenia bezpośrednio. Adres origin bywa znany z historii DNS, z nagłówków poczty, ze starych rekordów „DNS only” albo z innych usług na tym samym serwerze, a kto go zna, może wysłać żądania z pominięciem Cloudflare i tym samym ominąć cache, WAF oraz rate limiting. Na własnym VPS-ie lub serwerze dedykowanym ruch HTTP i HTTPS powinien być przyjmowany wyłącznie z zakresów Cloudflare i od faktycznie potrzebnych integracji; pamiętaj o IPv4 i IPv6, a dla monitoringu czy callbacków przygotuj osobne wyjątki. Sama lista dozwolonych adresów to warstwa przydatna, ale Cloudflare klasyfikuje ją jako „umiarkowanie bezpieczną”; mocniejszą opcją są Authenticated Origin Pulls, które pozwalają origin zweryfikować, że żądanie faktycznie przyszło z sieci Cloudflare, albo Cloudflare Tunnel. Najważniejsze do zapamiętania: samo podpięcie domeny do Cloudflare nie zabezpiecza serwera przed ruchem bezpośrednim.

Nieprzywrócony prawdziwy adres IP i stary fail2ban. Za reverse proxy serwer widzi połączenia z adresów Cloudflare, a prawdziwy adres klienta dostaje w nagłówku (m.in. CF-Connecting-IP). Jeśli go nie przywrócisz, logi, geolokalizacja, reguły antyfraud, rate limiting po stronie serwera i tryb konserwacji zobaczą adresy Cloudflare zamiast klientów. W Apache robi się to przez mod_remoteip, w nginx przez moduł Real IP z listą zaufanych zakresów Cloudflare — i temu nagłówkowi wolno ufać tylko wtedy, gdy połączenie faktycznie przyszło z zaufanego adresu Cloudflare, inaczej da się go sfałszować. To samo dotyczy fail2ban. Nie chodzi o to, że wymaga on „aktualizacji, bo doszedł Cloudflare”; po wdrożeniu trzeba przejrzeć, jak odczytuje adres klienta z logów, jakie zna zaufane zakresy i jak egzekwuje blokadę. Kluczowy niuans: blokada na firewallu origin może przestać działać, bo połączenie do serwera nawiązuje Cloudflare, a nie użytkownik — dlatego blokować trzeba albo na poziomie aplikacji i web serwera po przywróconym adresie, albo przenosić decyzje fail2ban do Cloudflare przez API, jako reguły działające na brzegu. Cloudflare wprost ostrzega zresztą, że bez przywróconego adresu fail2ban potrafi przypadkiem zablokować adresy samego Cloudflare i wywołać błędy u wielu użytkowników naraz.

Pozostałe błędy są mniej spektakularne, ale równie kosztowne:

Skoro mówimy o korzyściach, wypada pokazać, jak sprawdzić, że faktycznie wystąpiły. Nie potrzebujesz do tego benchmarków ani efektownych procentów w prezentacji — wystarczy obserwować kilka wskaźników przed wdrożeniem i po nim: