Optymalizacja stron internetowych, która realnie zwiększa sprzedaż 

Wolna strona kosztuje Cię klientów

Prędkość ładowania strony to nie kwestia estetyczna ani techniczna fanaberia – to bezpośredni czynnik biznesowy. Badania Google pokazują, że 53% użytkowników mobilnych opuszcza stronę, jeśli ładuje się dłużej niż 3 sekundy. Nie czekają, nie próbują odświeżyć – po prostu wychodzą i otwierają wynik numer dwa w Google. Jeśli prowadzisz sklep, stronę usługową lub landing page, każda sekunda opóźnienia to realnie utracone zapytania i sprzedaż.

Konwersja spada szybciej niż myślisz

Deloitte przebadało wpływ szybkości stron na konwersję w e-commerce i wyniki są jednoznaczne: poprawa czasu ładowania o zaledwie 0,1 sekundy przekłada się na wzrost konwersji o 8%. To nie jest wynik dla gigantów z milionami sesji – efekt jest proporcjonalny i działa dla każdej skali biznesu. Zależność jest prosta: szybsza strona to mniejszy opór przed dokonaniem kolejnego kroku, czy to wypełnieniem formularza, dodaniem produktu do koszyka, czy kliknięciem w numer telefonu.

Bounce rate i co z niego wynika

Współczynnik odrzuceń (bounce rate) to odsetek użytkowników, którzy wchodzą na stronę i wychodzą bez jakiejkolwiek interakcji. Wolna strona winduje ten wskaźnik w górę, bo część odwiedzających odpada jeszcze zanim strona się w pełni załaduje. Wysoki bounce rate to sygnał dla Google, że strona nie spełnia oczekiwań użytkownika – co przekłada się na gorsze pozycje, mniej ruchu organicznego i spiralę, z której trudno wyjść samą treścią czy linkowaniem.

W e-commerce każda sekunda ma cenę

Sklepy internetowe odczuwają skutki wolnej strony najboleśniej. Użytkownik, który czeka na załadowanie karty produktu, traci cierpliwość i impuls zakupowy jednocześnie. Porzucone koszyki rzadko wracają. Amazon szacował, że każde 100ms opóźnienia kosztuje ich 1% sprzedaży – przy ich skali to miliardy, ale mechanizm działa tak samo dla sklepu z obuwiem czy suplementami. Wolny checkout to prosta droga do porzuconego zamówienia na ostatnim kroku, gdy użytkownik już prawie kupił.

Zaufanie i pierwsze wrażenie

Szybkość strony wpływa też na percepcję marki. Wolno ładująca się witryna podświadomie komunikuje zaniedbanie – jeśli firma nie zadba o własną stronę, jak zadba o klienta? To szczególnie istotne w branżach, gdzie wiarygodność i profesjonalizm są kluczowym argumentem sprzedażowym: prawo, finanse, medycyna, usługi B2B. Pierwsze wrażenie robi się raz – i często dzieje się to zanim użytkownik przeczyta pierwsze zdanie.

Dlaczego WordPress z czasem zwalnia?

WordPress to najpopularniejszy system CMS na świecie – napędza ponad 40% wszystkich stron internetowych. Jego siła to elastyczność i ogromny ekosystem wtyczek, ale to właśnie ta elastyczność jest głównym powodem, dla którego strony zbudowane na WordPressie potrafią z czasem dramatycznie tracić na wydajności. Nie dzieje się to z dnia na dzień – to powolna degradacja, która zazwyczaj umyka uwadze właściciela strony do momentu gdy ktoś zwróci uwagę, że „strona strasznie wolno działa".

Wtyczki – największy sprawca

Przeciętna strona WordPress ma zainstalowanych od 20 do 40 wtyczek. Każda z nich dokłada coś do ładowania strony: własne pliki CSS, własne pliki JavaScript, własne zapytania do bazy danych przy każdym wejściu na podstronę. Problem w tym, że większość wtyczek ładuje swoje zasoby globalnie – na każdej podstronie, niezależnie od tego czy są tam potrzebne. Wtyczka do formularza kontaktowego ładuje swój JavaScript na stronie głównej, w blogu i w sklepie, choć formularz jest tylko w zakładce „Kontakt". Suwak zdjęć dokłada bibliotekę liczącą 150 kB do każdej podstrony. Zsumuj to przez 30 wtyczek i masz setki kilobajtów zbędnych zasobów ładowanych przy każdym wejściu na stronę.

Drugi problem to jakość samych wtyczek. Ekosystem WordPress jest otwarty, co oznacza że każdy może opublikować wtyczkę – i poziom optymalizacji kodu bywa bardzo różny. Popularna wtyczka z milionem aktywnych instalacji może wykonywać dziesiątki zbędnych zapytań SQL przy każdym ładowaniu strony, blokować główny wątek PHP albo ładować całą bibliotekę jQuery tylko po to żeby obsłużyć jedno rozwijane menu. Samo sprawdzenie aktywnych wtyczek w narzędziach do profilowania zapytań (np. Query Monitor) potrafi ujawnić, że jedna konkretna wtyczka odpowiada za 60% czasu generowania strony.

Baza danych rośnie i nikt jej nie sprząta

WordPress przechowuje w bazie MySQL absolutnie wszystko. Każda wersja posta, każde ustawienie każdej wtyczki, logi, tymczasowe dane cache (tzw. transients), metadane użytkowników i produktów, statystyki. Tabela wp_options ze świeżej instalacji ma kilkaset wpisów. Po dwóch latach aktywnego używania strony z kilkoma zmienianymi wtyczkami potrafi mieć ich kilkadziesiąt tysięcy – z czego zdecydowana większość to osierocone dane po wtyczkach, które zostały odinstalowane, ale nie posprzątały po sobie. Zapytania do takiej tabeli są wolne, bo MySQL musi przeszukać dziesiątki tysięcy wierszy zamiast kilkuset. Do tego dochodzą rewizje postów – WordPress domyślnie zapisuje nieskończoną historię wersji każdego artykułu. Sklep z 500 produktami, gdzie każdy był edytowany kilkanaście razy, może mieć w tabeli wp_posts kilka tysięcy wpisów będących wyłącznie historycznymi rewizjami, nigdy niewyświetlanymi nikomu.

Motywy, które robią za dużo

Page buildery takie jak Elementor, Divi czy WPBakery dają ogromną swobodę projektowania bez znajomości kodu, ale mają swoją cenę wydajnościową. Generują rozbudowane struktury HTML z dziesiątkami zagnieżdżonych divów, ładują własne biblioteki CSS i JS liczące setki kilobajtów, i często uniemożliwiają sensowną optymalizację bez głębokiej znajomości ich wewnętrznych mechanizmów. Motyw kupiony na ThemeForest za 59 dolarów, reklamowany jako „all-in-one", często bundluje kilkanaście bibliotek i funkcji których nigdy nie użyjesz, ale które i tak ładują się przy każdym wejściu na stronę. Lekki, dobrze napisany motyw w połączeniu z oszczędnym page builderem – albo bez niego – to jedna z najbardziej efektywnych optymalizacji jakie można zrobić, choć wymaga migracji treści.

Hosting, który nie nadąża

WordPress jest dynamiczny – każde wejście na stronę (bez cache) generuje zapytanie do bazy danych, wykonuje kod PHP i dopiero potem oddaje gotowy HTML do przeglądarki. Na tanim hostingu współdzielonym zasoby serwera są dzielone między dziesiątki lub setki stron jednocześnie. Gdy sąsiad na tym samym serwerze dostaje nagły ruch, Twoja strona zwalnia – bo dostaje mniej mocy obliczeniowej. Limity pamięci PHP ustawione na 64 MB zamiast 256 MB powodują że duże operacje kończą się błędem albo drastycznym zwolnieniem. Brak OPcache sprawia że PHP interpretuje ten sam kod od nowa przy każdym zapytaniu, zamiast korzystać z skompilowanej wersji przechowywanej w pamięci. To obszar, na który właściciel strony często nie ma wpływu bez zmiany planu hostingowego lub przejścia na VPS.

Aktualizacje, które zmieniają zachowanie

WordPress, motywy i wtyczki są regularnie aktualizowane – i choć zazwyczaj aktualizacje poprawiają bezpieczeństwo i wydajność, zdarza się że nowa wersja wtyczki zmienia jej zachowanie w sposób, który spowalnia stronę. Nowy feature domyślnie włączony, dodatkowe zapytanie Ajax, zmiana sposobu ładowania zasobów. Strona działała dobrze przez rok, po aktualizacji trzech wtyczek jednocześnie wynik PageSpeed spada o 20 punktów – i bez monitorowania trudno nawet stwierdzić co jest przyczyną. Właśnie dlatego w ramach opieki miesięcznej aktualizacje przeprowadzamy kontrolowanie, z weryfikacją wyników po każdej zmianie, a nie hurtem raz na kwartał.

Cloudflare, CDN i cache – jak to działa?

Żeby zrozumieć dlaczego Cloudflare i CDN tak bardzo przyspieszają strony, trzeba najpierw zrozumieć co dzieje się bez nich. Użytkownik wpisuje adres strony w przeglądarce. Przeglądarka wysyła zapytanie do serwera – fizycznej maszyny stojącej w konkretnym miejscu na świecie. Serwer generuje odpowiedź, odsyła ją z powrotem, przeglądarka zaczyna renderować stronę i wysyła kolejne dziesiątki zapytań po obrazy, CSS, JavaScript i czcionki. Każde z tych zapytań podróżuje fizyczną siecią – im dalej serwer, tym dłużej trwa ta podróż. To opóźnienie nazywa się latency i jest nieusuwalne – nawet przy idealnej infrastrukturze sygnał nie może podróżować szybciej niż prawa fizyki pozwalają. Jedynym sposobem na jego redukcję jest zbliżenie serwera do użytkownika.

CDN – treść bliżej użytkownika

Content Delivery Network to sieć dziesiątek lub setek serwerów rozmieszczonych w różnych lokalizacjach geograficznych – nazywanych węzłami lub punktami obecności (PoP, Points of Presence). Kiedy użytkownik z Poznania wchodzi na stronę, której główny serwer stoi w Warszawie, różnica jest pomijalnie mała. Ale jeśli ta sama strona obsługuje klientów z Niemiec, Wielkiej Brytanii czy Skandynawii, każde zapytanie do zasobów statycznych – obrazów, plików CSS, JavaScript – musi podróżować do Warszawy i z powrotem. CDN rozwiązuje ten problem kopiując te zasoby do węzłów w Frankfurcie, Amsterdamie, Londynie i Sztokholmie. Użytkownik z Berlina pobiera obraz z serwera 15 ms od niego, a nie z Warszawy oddalonej o 80 ms. Przy stronie z kilkudziesięcioma zasobami te różnice się sumują do zauważalnego skroku w czasie ładowania.

Cloudflare jest dziś najpopularniejszym dostawcą CDN dla małych i średnich stron internetowych – i słusznie, bo darmowy plan oferuje naprawdę dużo. Sieć Cloudflare liczy ponad 300 węzłów na całym świecie. Konfiguracja sprowadza się do zmiany serwerów DNS domeny na serwery Cloudflare – od tego momentu cały ruch do strony przechodzi przez infrastrukturę Cloudflare, która obsługuje go z najbliższego węzła.

Cache – serwowanie gotowych odpowiedzi

Cache to mechanizm przechowywania wcześniej wygenerowanych odpowiedzi i oddawania ich kolejnym użytkownikom bez ponownego przetwarzania. Istnieje na kilku poziomach jednocześnie i każdy z nich jest ważny.

Cache przeglądarki – zasoby statyczne jak logo, czcionki czy arkusze CSS są pobierane przez przeglądarkę raz i przechowywane lokalnie przez określony czas (zdefiniowany przez nagłówki HTTP Cache-Control i Expires). Przy kolejnych wizytach przeglądarka nie pobiera ich ponownie z serwera – bierze gotowe z dysku. Poprawna konfiguracja nagłówków cache potrafi sprawić, że ponowne wejście na stronę ładuje się błyskawicznie, bo 80% zasobów jest już lokalnie.

Cache serwera – WordPress bez cache generuje każdą stronę dynamicznie: wykonuje zapytania SQL, przetwarza kod PHP, składa HTML i dopiero wtedy odsyła odpowiedź. Dla strony z dużym ruchem to ogromne obciążenie serwera. Cache serwera przerywa ten cykl: po pierwszym wejściu gotowy HTML jest zapisywany na dysku lub w pamięci, a kolejni użytkownicy dostają tę gotową wersję bezpośrednio, z pominięciem PHP i bazy danych. Czas generowania strony spada z setek milisekund do kilku lub kilkunastu.

Cache Cloudflare – Cloudflare może cache'ować nie tylko zasoby statyczne ale przy odpowiedniej konfiguracji również gotowe odpowiedzi HTML dla niezalogowanych użytkowników. Oznacza to, że część ruchu w ogóle nie dociera do Twojego serwera – Cloudflare odpowiada z własnej pamięci ze swojego węzła. To radykalnie odciąża hosting i skraca TTFB (Time to First Byte) do minimum.

Reguły i wykluczenia – gdzie cache przeszkadza

Cache jest potężnym narzędziem, ale wymaga starannej konfiguracji wykluczeń – i tu właśnie popełnia się najwięcej błędów. W sklepie WooCommerce strony produktów i treści statyczne powinny być agresywnie cache'owane. Ale koszyk, strona kasy, strona „moje konto" i wszelkie podstrony dla zalogowanych użytkowników muszą być z cache wykluczone – bo te strony są dynamiczne i unikalne dla każdego użytkownika. Podanie zalogowanemu klientowi ze strony cache zawartości koszyka innego użytkownika to błąd, który zdarza się przy zbyt agresywnej konfiguracji bez właściwych wykluczeń. Dobrze skonfigurowany Cloudflare ma zdefiniowane reguły Page Rules lub Cache Rules, które precyzyjnie określają co cache'ować, na jak długo i dla kogo.

Minifikacja, kompresja i HTTP/2

Cloudflare oferuje też automatyczną minifikację HTML, CSS i JavaScript – usuwa białe znaki, komentarze i zbędne znaki z plików bez zmiany ich funkcjonalności, redukując ich rozmiar. Włącza kompresję Brotli lub Gzip dla wszystkich zasobów tekstowych – przeglądarka otrzymuje skompresowany plik i rozpakuje go lokalnie, co jest wielokrotnie szybsze niż pobieranie pełnej wersji. Cloudflare obsługuje też HTTP/2 i HTTP/3, które pozwalają przeglądarce pobierać wiele zasobów jednocześnie przez jedno połączenie zamiast kolejkować je jedno po drugim jak w starszym HTTP/1.1. Wszystko to dzieje się automatycznie po podpięciu domeny pod Cloudflare, bez żadnych zmian na serwerze.

Optymalizacja obrazów – największa szybka wygrana

Obrazy są zazwyczaj największym składnikiem wagowym strony internetowej. Na przeciętnej witrynie WordPress odpowiadają za 50–70% całkowitego rozmiaru pobieranych zasobów. To sprawia, że optymalizacja obrazów jest jednocześnie najłatwiejszym i najszybszym sposobem na poprawę wydajności – efekty są niemal natychmiastowe i nie wymagają ingerencji w kod ani konfigurację serwera. Mimo to zdecydowana większość stron, które trafiają do nas na audyt, ma obrazy w ogóle nieoptymalizowane: oryginalne pliki JPEG wrzucone prosto z aparatu lub od grafika, ważące po 3–8 MB, wyświetlane w kontenerze o szerokości 600 pikseli.

Format ma ogromne znaczenie – WebP i AVIF

Przez lata standardem w internecie był JPEG dla fotografii i PNG dla grafik z przezroczystością. Oba formaty mają swoje lata i nie zostały zaprojektowane z myślą o współczesnych prędkościach łącza i rozdzielczościach ekranów. WebP, opracowany przez Google, oferuje kompresję o 25–35% lepszą niż JPEG przy identycznej lub wyższej jakości wizualnej. Ten sam obraz, który w JPEG waży 400 kB, w WebP waży 260–280 kB bez zauważalnej różnicy dla ludzkiego oka. AVIF – jeszcze nowszy format – potrafi osiągnąć kompresję o 50% lepszą niż JPEG, choć jego wsparcie w starszych przeglądarkach jest wciąż ograniczone. Praktyczne podejście to serwowanie WebP jako domyślnego formatu z fallbackiem do JPEG dla starszych przeglądarek – tag HTML <picture> pozwala to obsłużyć elegancko bez żadnego JavaScript.

W WordPress konwersja do WebP odbywa się automatycznie przez wtyczki takie jak ShortPixel, Imagify czy Cloudflare Polish. Od wersji 5.8 WordPress natywnie obsługuje WebP jako format uploadu, ale samo wgranie pliku w WebP nie wystarczy – trzeba zadbać o to żeby wszystkie miniatury generowane przez WordPress (a jest ich zazwyczaj kilka rozmiarów dla każdego obrazu) też były w odpowiednim formacie i rozmiarze.

Wymiary i skalowanie po stronie przeglądarki

Jeden z najczęstszych błędów to wgrywanie obrazów w oryginalnych wymiarach i poleganie na tym że przeglądarka je pomniejszy przez CSS. Wgrywasz zdjęcie 4000×3000 pikseli, ustawiasz w CSS max-width: 800px i myślisz że problem rozwiązany. Przeglądarka wyświetla obraz w 800 pikselach – ale pobiera pełne 4000 pikseli. Skalowanie odbywa się lokalnie, ale pobieranie jest pełne. Obrazy powinny być wgrywane lub automatycznie przycinane do rozmiarów faktycznie używanych w layoucie. WordPress robi to przez system miniaturek, ale wymaga poprawnej konfiguracji – zdefiniowania rozmiarów odpowiadających rzeczywistym miejscom użycia w motywie, a nie tylko domyślnych wartości.

Do tego dochodzi kwestia ekranów Retina i wysokiej rozdzielczości (HiDPI). Na takich ekranach przeglądarka potrzebuje obrazu o dwukrotnie większych wymiarach niż kontener w CSS żeby wyglądał ostro. Atrybut srcset pozwala dostarczyć przeglądarce kilka wersji obrazu w różnych rozmiarach – przeglądarka sama wybiera właściwy w zależności od gęstości pikseli i rozmiarów okna. Poprawna implementacja srcset to balans między ostrością na wszystkich urządzeniach a niepotrzebnym pobieraniem gigantycznych plików na małych ekranach.

Lazy loading – ładuj tylko to co widoczne

Domyślnie przeglądarka pobiera wszystkie obrazy na stronie od razu podczas ładowania – nawet te, które są głęboko na dole i użytkownik może nigdy do nich nie dotrzeć. Lazy loading odkłada pobieranie obrazów poza aktualnym widokiem (viewport) do momentu gdy użytkownik faktycznie do nich dotrze scrollując. Implementacja jest prosta – atrybut loading="lazy" w tagu <img> – i jest natywnie obsługiwana przez wszystkie nowoczesne przeglądarki bez żadnych bibliotek JavaScript. Efekt to znaczące zmniejszenie rozmiaru danych pobieranych przy pierwszym wejściu na stronę, co bezpośrednio przekłada się na LCP i ogólny czas ładowania.

Ważna uwaga: lazy loading nie powinien być stosowany do obrazów widocznych od razu po załadowaniu strony – czyli głównego obrazu hero, logo i wszystkiego w górnej części ekranu (above the fold). Dla tych elementów priorytetem jest jak najszybsze załadowanie, więc używamy atrybutu fetchpriority="high" który sygnalizuje przeglądarce żeby pobrała je jako pierwsze, jeszcze zanim przeanalizuje resztę strony.

Kompresja – jakość bez zbędnych danych

Każdy plik graficzny zawiera metadane: informacje o aparacie, lokalizację GPS, profil kolorów, datę wykonania. Dla użytkownika strony są one całkowicie bezużyteczne, ale potrafią dodawać kilkadziesiąt kilobajtów do każdego pliku. Usunięcie metadanych (tzw. strip metadata) to jedno z pierwszych działań przy optymalizacji obrazów. Do tego dochodzi właściwa kompresja stratna lub bezstratna – w zależności od rodzaju obrazu. Fotografie znoszą kompresję stratną bez zauważalnej utraty jakości przy ustawieniu 75–85% jakości JPEG. Grafiki z płaskimi kolorami, ikony i ilustracje lepiej kompresują się bezstratnie lub jako SVG jeśli to możliwe. SVG dla ikon i prostych grafik to osobna kategoria – plik SVG to kod XML opisujący kształty wektorowe, często kilkadziesiąt razy lżejszy niż odpowiadający mu PNG, i idealnie ostry na każdej rozdzielczości ekranu.

Kiedy wtyczki i cache już nie wystarczą

Jest pewien próg, po którego przekroczeniu standardowy zestaw narzędzi – wtyczka cache, Cloudflare, optymalizacja obrazów – przestaje wystarczać. Można skonfigurować WP Rocket perfekcyjnie, wdrożyć Cloudflare z kompletnymi regułami, skompresować każdy obraz do WebP i nadal patrzeć na wynik 45/100 w PageSpeed z TTFB liczonym w sekundach. Dzieje się tak gdy problem leży głębiej – w warstwie, do której wtyczki nie mają dostępu: w kodzie aplikacji, konfiguracji serwera na poziomie systemu operacyjnego, architekturze bazy danych lub sposobie generowania odpowiedzi przez PHP.

Czas odpowiedzi serwera (TTFB) jako wskaźnik

Time to First Byte – czas od wysłania zapytania przez przeglądarkę do otrzymania pierwszego bajtu odpowiedzi z serwera – jest kluczowym sygnałem diagnostycznym. Dobry TTFB to poniżej 200 ms, akceptowalny to poniżej 600 ms. Jeśli TTFB Twojej strony wynosi 1,5–3 sekundy, żadna optymalizacja front-endowa tego nie naprawi – cache obrazów i minifikacja CSS działają dopiero po tym jak serwer odpowie. Wysoki TTFB wskazuje że problem jest po stronie serwera: zbyt wolne wykonywanie PHP, przeciążona baza danych, brak OPcache, niewystarczające zasoby hostingu lub nieefektywny kod aplikacji.

OPcache i konfiguracja PHP

PHP jest językiem interpretowanym – normalnie przy każdym zapytaniu do strony serwer musi wczytać pliki PHP, sparsować je i skompilować do kodu bajtowego, który dopiero jest wykonywany. OPcache eliminuje ten krok przechowując skompilowany kod bajtowy w pamięci operacyjnej serwera. Przy następnym zapytaniu PHP pomija etap parsowania i kompilacji, co skraca czas wykonywania nawet o 50–70%. Na większości hostingów współdzielonych OPcache jest włączony, ale jego konfiguracja – wielkość pamięci, czas wygaśnięcia, liczba plików – jest często ustawiona na minimum. Na VPS i serwerach dedykowanych dostrojenie OPcache do specyfiki konkretnej aplikacji to jedna z pierwszych i najbardziej opłacalnych interwencji na poziomie serwera.

Do tego dochodzą ustawienia samego PHP: limit pamięci, maksymalny czas wykonania, obsługa sesji, wersja PHP. WordPress działa najwydajniej na PHP 8.1 lub nowszym – przejście z PHP 7.4 na 8.1 to mierzalny wzrost wydajności bez żadnych innych zmian, bo nowe wersje PHP są po prostu szybsze w wykonywaniu kodu. Wiele stron tkwi na starszych wersjach PHP z obawy przed niekompatybilnością wtyczek lub z braku wiedzy że aktualizacja jest możliwa.

Baza danych – zapytania jako wąskie gardło

W bardziej rozbudowanych stronach i sklepach problemem przestaje być sama ilość danych w bazie, a stają się nim konkretne zapytania SQL wykonywane przy każdym ładowaniu strony. Wtyczka Query Monitor w trybie debugowania potrafi pokazać że jedna podstrona wykonuje 200 zapytań SQL, z których kilkanaście trwa po 300–500 ms każde. Zazwyczaj winowajcami są zapytania bez indeksów – MySQL musi przeskanować całą tabelę zamiast skorzystać z indeksu i znaleźć wynik natychmiast. Dodanie odpowiednich indeksów do tabel, optymalizacja zapytań generowanych przez motywy i wtyczki, oraz wdrożenie cache obiektów przez Redis lub Memcached (mechanizm przechowujący wyniki zapytań SQL w pamięci RAM, eliminujący ich ponowne wykonywanie) potrafi zredukować czas generowania strony z 2 sekund do 200 ms.

Wolny kod aplikacji

Kiedy narzędzia profilujące wskazują na konkretne funkcje PHP lub komponenty JavaScript jako źródło problemów, wkraczamy w obszar optymalizacji kodu. W WordPress może to być nieefektywna pętla w motywie wykonująca zapytania do bazy w każdej iteracji zamiast pobrać wszystkie dane jednym zapytaniem, funkcja hooka uruchamiana przy każdym ładowaniu strony która wykonuje kosztowne operacje, albo fragment kodu legacy który oblicza coś synchronicznie co powinno być cache'owane lub wykonywane asynchronicznie. W niestandardowych platformach – Next.js, Laravel, Magento – problemy mogą być bardziej złożone: nieoptymalne renderowanie po stronie serwera, brakujące cache na poziomie aplikacji, niezoptymalizowane relacje w ORM generujące problem N+1 zapytań.

Redis i dedykowane rozwiązania cache

Na poziomie enterprise i przy dużym ruchu standardowy cache plikowy WordPressa przestaje wystarczać. Redis to baza danych działająca w pamięci RAM, używana jako cache obiektów – przechowuje wyniki zapytań SQL, skompilowane fragmenty stron i dane sesji w pamięci operacyjnej serwera, skąd są odczytywane w mikrosekundach. Varnish to z kolei reverse proxy cache – siedzi przed serwerem webowym i odpowiada na zapytania HTTP bezpośrednio z pamięci, zanim w ogóle dotrą do PHP i WordPress. Dla sklepów WooCommerce z tysiącami produktów i setkami jednoczesnych użytkowników te rozwiązania to nie luksus – to konieczność. Konfiguracja Redisa i Varnisha wykracza daleko poza zakres jakiejkolwiek wtyczki i wymaga dostępu do serwera oraz znajomości jego architektury.

Kiedy warto rozważyć migrację

Czasem po pełnym audycie uczciwa odpowiedź brzmi: ten serwer lub ta architektura nie pozwolą osiągnąć dobrych wyników bez fundamentalnej zmiany infrastruktury. Hosting współdzielony z limitami PHP uniemożliwiającymi włączenie OPcache i Redis, stara wersja MySQL bez możliwości aktualizacji, serwer fizycznie zlokalizowany na innym kontynencie niż większość użytkowników – to bariery, których optymalizacja aplikacji nie przeskoczy. W takich przypadkach migracja na VPS lub serwer dedykowany z pełną kontrolą nad konfiguracją jest kosztowo efektywniejsza niż próba wyciśnięcia maksimum z ograniczonej infrastruktury. W raporcie zawsze wskazujemy takie sytuacje wprost – bo lepiej wiedzieć to przed zamówieniem optymalizacji niż po.