Sklep WooCommerce – od wolnej strony do zielonych Core Web Vitals

Klient zgłosił się do SEOSEM24 z klasycznym problemem właścicieli sklepów internetowych: „mamy ruch, mamy dobrą ofertę, ale strona ładuje się wolno, a sprzedaż mogłaby być wyższa”. Sklep działał na WordPress + WooCommerce z własnym motywem, rozbudowaną warstwą wizualną, wieloma integracjami i niestandardowymi funkcjami. Dla użytkownika oznaczało to kilka sekund czekania na załadowanie strony oraz frustrujące „przycinanie się” interfejsu w kluczowych momentach ścieżki zakupowej.

Z perspektywy SEO problem był równie poważny. Dane z Google Search Console i PageSpeed Insights pokazywały, że duża część adresów URL sklepu nie przechodzi testu Core Web Vitals. Największe problemy dotyczyły wskaźników LCP (Largest Contentful Paint) oraz INP/TBT, czyli realnej responsywności strony na działania użytkownika. To wszystko wpływało na doświadczenie klienta, współczynnik odrzuceń i – pośrednio – na widoczność w wynikach organicznych.

Celem współpracy było więc nie tylko „przyspieszenie strony”, ale poprawa całej warstwy technicznej sklepu tak, aby spełniał wymagania Core Web Vitals, był zgodny z dobrymi praktykami dostępności oraz lepiej konwertował ruch z SEO. Naszym pacjentem był sklep internetowy pod adresem url: https://sklep-mati.pl

Punkt wyjścia – co zastaliśmy po audycie

W pierwszym etapie przeprowadzony został szczegółowy audyt wydajności i dostępności. Obejmował on pomiar czasu ładowania na kluczowych podstronach (strona główna, kategorie, karty produktów, koszyk), analizę zapytań do bazy danych, struktury plików oraz sposobu ładowania zasobów front‑endowych.

Najważniejsze problemy:

• Czas wczytywania strony głównej sięgał kilku sekund na urządzeniach mobilnych. Dla części użytkowników, szczególnie przy wolniejszych łączach, realnie oznaczało to 4–5 sekund czekania na to, aż będą mogli wykonać pierwsze sensowne działanie.
• Metryka LCP była zbyt wysoka. Największy element widoczny w obszarze ekranu (najczęściej grafika hero lub duży banner produktowy) ładował się z opóźnieniem – obraz był serwowany w dużej rozdzielczości, bez odpowiedniego priorytetu, a czasem dodatkowo objechany przez skrypty odpowiedzialne za animacje.
• Wysoki czas TTFB sugerował przeciążenie warstwy PHP i bazy danych. Ilość zapytań generowanych przez własny motyw, WooCommerce i wtyczki pomocnicze była zdecydowanie zbyt duża. Brakowało cache’owania strategicznych elementów.
• Nadmiar skryptów JavaScript i arkuszy CSS powodował blokowanie renderowania. Część bibliotek front‑endowych była ładowana globalnie, mimo że używano ich tylko na pojedynczych widokach. Dodatkowo na stronie działały różne wtyczki analityczne, czat i kilka systemów remarketingu – każdy ze swoim kodem.
• Audyt dostępności wykazał liczne błędy: przyciski bez nazw dostępnych (np. ikonki serca i koszyka), zbyt małe touch‑targety na urządzeniach mobilnych, formularze kontaktowe z nieczytelnymi etykietami oraz brak spójnej hierarchii nagłówków na części podstron.

Podsumowując – sklep był rozbudowany, atrakcyjny wizualnie, ale technologicznie „ciężki”. Konieczne było podejście systemowe, a nie jednorazowa „łatka” w postaci kolejnej wtyczki optymalizacyjnej.

Strategia SEOSEM24 – techniczny fundament pod SEO i UX

Zespół SEOSEM24 przygotował plan działań w kilku obszarach, które razem miały doprowadzić do wyraźnej poprawy wyników:

1. Refaktoryzacja motywu i redukcja obciążenia serwera
   Pierwszym krokiem była analiza kodu własnego motywu oraz szablonów WooCommerce. Zidentyfikowano fragmenty generujące zbędne zapytania do bazy – m.in. powtarzane pętle produktów, widgety pobierające duże ilości danych oraz mocno rozbudowane sekcje dynamiczne na stronie głównej. Część funkcji została przebudowana tak, aby bazowały na cache’owanych wynikach, a nie na każdorazowym wykonywaniu wielokrotnych zapytań. Usunięto również przestarzałe lub nieużywane moduły, które nadal ładowały swoje zasoby.
2. Porządkowanie i warunkowe ładowanie assetów
   Zamiast globalnie dołączać wszystkie arkusze stylów i skrypty JavaScript, przygotowano podział na zestawy ładowane zależnie od typu strony. Inne zasoby ładowane są na stronie głównej, inne na kartach produktów, a jeszcze inne w koszyku i w procesie checkout. Zadbano też o minifikację plików, scalanie tylko tych zasobów, które faktycznie dawały zysk, oraz ich ładowanie w sposób nieblokujący renderowania tam, gdzie to możliwe.
3. Konfiguracja cache i CDN
   Sklep miał już zainstalowane rozwiązanie cache’ujące oraz CDN, ale konfiguracja była „domyślna”. Wprowadzono bardziej agresywne reguły cache dla stron, które rzadko się zmieniają, oraz sensowniejsze wykluczenia dla dynamicznych elementów (np. koszyka). Zadbano o to, aby statyczne zasoby – obrazki, CSS, JS – były serwowane z CDN z odpowiednio długimi nagłówkami cache i wersjonowaniem plików.
4. Optymalizacja obrazów i kluczowego elementu LCP
   Skoncentrowano się na największych grafikach, które zwykle stają się elementami LCP. Zostały skompresowane, przygotowano warianty w formatach nowej generacji oraz dopasowane rozmiary do realnych potrzeb layoutu. Dla głównego obrazu hero usunięto lazy‑loading i przypisano mu najwyższy priorytet ładowania, tak aby przeglądarka traktowała go jako zasób kluczowy.
5. Poprawa dostępności (WCAG) i elementów interaktywnych
   Ikony i przyciski wykorzystywane w motywie – np. dodawanie do ulubionych, rozwijanie filtrów, przełączanie widoków – zostały uzupełnione o atrybuty ARIA i czytelne etykiety tekstowe dla czytników ekranu. Jednocześnie dopilnowano, aby elementy klikalne na urządzeniach mobilnych miały wystarczający rozmiar i odstępy. Obszar interakcji rozszerzono tak, by spełniał wymagania dotyczące minimalnej wielkości targetu dotykowego.
6. Monitoring i testy A/B
   Każdy etap wdrożenia był testowany – zarówno w narzędziach deweloperskich przeglądarki, jak i w PageSpeed Insights oraz Lighthouse. Zmiany wprowadzano iteracyjnie, porównując wyniki przed i po modyfikacjach. Dzięki temu udało się uniknąć typowego problemu, w którym agresywna optymalizacja „psuje” ważne funkcje sklepu.

Działania operacyjne – co dokładnie zostało zrobione

Na poziomie technicznym ważne były detale. Oto wybrane przykłady rozwiązań, które miały największy wpływ na finalny efekt:

• Optymalizacja zapytań do bazy danych
  W wielu miejscach sklep korzystał z dodatkowych zapytań w pętlach produktowych – np. pobieranie ulubionych, zliczanie opinii, sprawdzanie stanów magazynowych. Część tych operacji została przeniesiona na poziom pojedynczej, dobrze zaprojektowanej kwerendy lub cache’owana w sesji użytkownika, co znacząco zmniejszyło obciążenie serwera.
• Usprawnienie pracy serwera PHP
  Zaktualizowano wersję PHP, zoptymalizowano konfigurację opcache oraz innych mechanizmów przyspieszających generowanie odpowiedzi. Dodatkowo zwrócono uwagę na to, by w newralgicznych miejscach kod był maksymalnie „lekki”, bez zbędnych pętli i kosztownych operacji.
• Porządkowanie front‑endu
  Nadmiar bibliotek JavaScript – od sliderów, przez animacje, po komponenty UI – został ograniczony do tych faktycznie wykorzystywanych. Wyłączono generowanie skryptów i stylów modułów, które w praktyce nigdy nie były używane na froncie. Dla pozostałych wprowadzono warunkowe ładowanie oraz opóźnione wykonywanie skryptów, które nie są potrzebne do pierwszego renderu strony.
• Priorytety ładowania kluczowych zasobów
  Dla najważniejszych obrazów w obszarze widocznym po wejściu na stronę zastosowano wyższy priorytet pobierania, natomiast pozostałe elementy graficzne zostały objęte sensowną polityką lazy‑loadingu. Dzięki temu użytkownik szybko widzi istotne informacje, a mniej ważne elementy wczytują się w tle.
• Usprawnienie formularzy i nawigacji
  Formularze kontaktowe i zapisu do newslettera zostały przebudowane tak, aby każdy element miał jednoznaczną etykietę, odpowiedni rozmiar i zachowywał pełną funkcjonalność klawiaturową. Podobny przegląd wykonano dla nawigacji, filtrów produktów, paginacji i innych elementów interfejsu.

Wyniki – szybszy sklep, lepszy UX, więcej konwersji

Po pełnym wdrożeniu optymalizacji strona została ponownie przebadana w narzędziach analitycznych i deweloperskich. Efekty były porównywalne z tymi, które osiąga się w dobrze przeprowadzonych projektach optymalizacji WooCommerce:

• Wyraźne skrócenie czasu ładowania
  Czasy ładowania kluczowych podstron spadły z kilku sekund do okolic jednej sekundy na desktopie i znacząco poprawiły się na urządzeniach mobilnych. Dla użytkownika różnica była odczuwalna natychmiast – strona przestała „mulić”, a grafiki pojawiały się płynnie.
• Zielone statusy Core Web Vitals
  Po serii iteracyjnych poprawek większość stron w raporcie Core Web Vitals osiągnęła status „dobry”. Obniżono LCP do poziomu zgodnego z zaleceniami wyszukiwarek, poprawiono stabilność layoutu (CLS), a responsywność interfejsu znalazła się w bezpiecznym zakresie.
• Lepsze doświadczenie użytkownika i konwersje
  Skrócenie czasu oczekiwania na załadowanie strony oraz poprawa ergonomii elementów interaktywnych przełożyły się na większą liczbę ukończonych sesji zakupowych. Użytkownicy rzadziej porzucali koszyk i częściej przechodzili cały proces zakupu.
• Solidny fundament pod dalsze działania SEO
  Dzięki uporządkowaniu warstwy technicznej sklep zyskał stabilną bazę pod rozbudowę treści, linkowanie wewnętrzne i kolejne działania marketingowe. Dalszy wzrost organiczny można teraz osiągać przez prace on‑page i off‑page, bez obaw, że ograniczeniem będzie wydajność platformy.

Więc, co wyróżnia podejście SEOSEM24?

W tym projekcie kluczowe było połączenie kilku kompetencji: znajomości WordPressa i WooCommerce na poziomie kodu, praktyki SEO technicznego, rozumienia Core Web Vitals oraz zasad dostępności. Zamiast próbować „magicznie” przyspieszyć stronę samą konfiguracją wtyczek cache, SEOSEM24 skupiło się na prawdziwych przyczynach wolnego działania:

• odchudzenie motywu,
• zoptymalizowanie zapytań i zasobów,
• priorytetyzacja kluczowych elementów,
• oraz poprawa UX i dostępności.

Dzięki temu sklep nie tylko spełnia wymagania wyszukiwarek i narzędzi testujących, ale przede wszystkim stał się szybszy i wygodniejszy dla realnych klientów. To dokładnie ten rodzaj efektu, który później najłatwiej pokazać w raportach i dalszych case studies Twojej agencji.