Optymalizacja szybkości sklepu nie kończy się na włączeniu jednej wtyczki — to projekt, który trzeba zaplanować, zmierzyć i rozliczyć. W tej części artykułu skupiamy się na organizacji pracy: co zapisać przed startem, w jakiej kolejności wdrażać zmiany i jak sprawdzić, czy faktycznie przyniosły efekt. Znajdziesz tu listę typowych błędów, checklistę wdrożeniową i odpowiedzi na pytania, które najczęściej dostajemy od właścicieli sklepów z Frampola i okolic.
Najczęstszy argument, jaki słyszymy od właścicieli sklepów z Frampola i okolic, brzmi: „u mnie na laptopie otwiera się od razu”. To prawda — ale Twój laptop pracuje na kablu albo mocnym Wi-Fi, a klient jedzie przez Biłgoraj czy Janów Lubelski i klika w telefonie na 4G. To dwa różne pomiary i tylko ten drugi przekłada się na zamówienia.
Skala strat jest policzona. Badanie Google/SOASTA z 2017 r. wykazało, że 53% użytkowników mobilnych porzuca stronę ładującą się dłużej niż 3 sekundy. Analiza Deloitte dla Google („Milliseconds make millions”, 2020) pokazała, że skrócenie LCP o 0,1 s wiązało się ze wzrostem konwersji w handlu detalicznym o ok. 8%. Nie traktuj tych liczb jako prognozy dla własnego sklepu — to punkt odniesienia. Wartość ma Twój pomiar przed i po.
Klient z mniejszej miejscowości zachowuje się inaczej niż mieszkaniec dużego miasta. Wprowadza w telefonie „sklep [kategoria] Frampol”, klika w wynik lokalny albo w mapy, a potem chce w 2–3 sekundy zobaczyć cenę, dostępność i koszt dostawy. Widzi biały ekran albo skaczące elementy — wraca do wyników wyszukiwania i wchodzi do konkurencji. Przy słabszym łączu każdy kilobajt boli: nieskompresowany baner 1,5 MB albo czcionka ładowana z zewnętrznego serwera to kilkaset milisekund na start.
Dlaczego „wydaje mi się szybkie” kłóci się z realnym pomiarem? Trzy powody: cache przeglądarki (drugie wejście jest zawsze szybsze niż pierwsze), szybkie łącze w biurze i duży ekran, który nie wymaga pobrania pełnej wersji mobilnej. Dlatego mierzymy zawsze na telefonie, w trybie incognito, z dławieniem sieci i procesora. Ten sam schemat prac stosujemy w sklepach na WooCommerce — zobacz, jak wygląda optymalizacja WooCommerce w Józefowie. Zakres dla sąsiedniej miejscowości rozpisaliśmy też w materiale o SEO technicznym i optymalizacji szybkości w Józefowie.
SEO techniczne to wszystko, co dzieje się poza treścią, a decyduje o tym, czy Google w ogóle weźmie Twoją stronę pod uwagę. Proces po stronie wyszukiwarki dzieli się na trzy etapy i każdy można zablokować jednym ustawieniem.
| Etap | Co robi Google | Co go blokuje | Gdzie to sprawdzisz |
|---|---|---|---|
| Crawl | Pobiera adresy z sitemap.xml i linków wewnętrznych | Disallow w robots.txt, błędy 500, pętle przekierowań, tysiące adresów filtrów | Raport Sitemaps i Sprawdzenie adresu URL w GSC |
| Indeksacja | Wybiera wersję kanoniczną i zapisuje stronę w indeksie | noindex, błędny canonical, duplikaty, kategorie z jednym produktem | Raport Indeksowanie stron w GSC |
| Renderowanie | Uruchamia JavaScript i ocenia finalną treść | Ceny i opisy wstrzykiwane JS-em, lazy load nad pierwszym ekranem | Test na żywo w GSC, PageSpeed Insights |
Do tego dochodzi warstwa plików i adresów: robots.txt z poprawną dyrektywą Sitemap, sitemap.xml generowana automatycznie, prawidłowy canonical, przekierowania 301 zamiast łańcuchów po trzy–cztery skoki oraz czytelna struktura URL typu /buty-meskie/skorzane-trzewiki zamiast /index.php?id_product=125&controller=product. W PrestaShop i WooCommerce najczęściej psuje się to przy zmianie szablonu albo po włączeniu modułu, który „optymalizuje” i przy okazji wycina canonicale — po każdej takiej zmianie zrób test dwóch–trzech adresów.
Osobna pozycja to dane strukturalne. Dla produktu potrzebujesz Product i Offer: nazwa, cena, waluta, dostępność, a w przypadku wyników zakupowych także kosztów dostawy i zwrotów. Bez tego nie łapiesz rozszerzonych wyników z ceną i stanem magazynowym. Wzorce, które Google faktycznie obsługuje, znajdziesz w dokumentacji danych strukturalnych.
Core Web Vitals (LCP, INP, CLS) są sygnałem rankingowym, ale nie jedynym i nigdy nie nadrobią złej techniki. Sklep z LCP 1,9 s i pętlami przekierowań w kategoriach wypadnie gorzej niż wolniejszy, ale poprawnie zaindeksowany. Kolejność jest zawsze ta sama: najpierw dostępność i indeksacja, potem szybkość. Przykład takiego zakresu dla mniejszej miejscowości mamy w tekście o SEO technicznym i szybkości w Krasnobrodzie.
Zacznij od Search Console, bo tam są dane od Google, a nie z symulacji. Kolejność i czas:
curl -I na trzech adresach, żeby zobaczyć kody odpowiedzi i łańcuchy przekierowań.| Narzędzie | Co sprawdzasz | Czas | Na co uważać |
|---|---|---|---|
| GSC → Core Web Vitals | Które szablony (grupy URL) mają problem na telefonie | 5 min | To dane polowe z 28 dni, nie pojedynczy test |
| GSC → Indeksowanie stron | Błędy 404/500, noindex, błędne canonicale | 7 min | Awaria kategorii blokuje też przypisane produkty |
| Test na żywo | Czy Google widzi cenę i nazwę po wyrenderowaniu JS | 3 min | Test nie potwierdza, że adres jest w indeksie |
| PageSpeed Insights | LCP, INP, CLS z danych polowych i labowych | 7 min | Zawsze zaczynaj od telefonu, lab to symulacja 4G |
| Lighthouse + curl -I | Zasoby blokujące, przekierowania, kody odpowiedzi | 8 min | Wynik labowy skacze o 10–20 pkt między uruchomieniami |
Jak zapisać stan „przed”. Załóż arkusz z kolumnami: URL, data, PSI mobile (lab), LCP/INP/CLS (dane polowe, 28 dni, mobile), liczba zaindeksowanych stron, liczba błędów 404 i 500, liczba ostrzeżeń Core Web Vitals. Zrób zrzut ekranu każdego raportu z ustawionym zakresem dat i wyeksportuj CSV. Zapisz datę wdrożenia zmiany — dane polowe porównujesz dopiero po 28 dniach, bo tyle wynosi okno CrUX. Pułapka numer jeden: porównywanie wyniku Lighthouse przed i po. Ten sam adres potrafi dać 45 i 68 punktów w dwóch kolejnych uruchomieniach, więc zmieniaj jedną rzecz naraz. Zakres takich audytów opisaliśmy przy okazji audytu w Szczebrzeszynie, a jeśli problem siedzi w samej platformie, warto połączyć go z porządkowaniem wdrożeń i migracji PrestaShop w Frampolu — inaczej kolejna aktualizacja szablonu cofnie część poprawek.
Core Web Vitals to trzy liczby zbierane od prawdziwych użytkowników Chrome. Nie musisz znać definicji, żeby coś z nich wyciągnąć — wystarczy wiedzieć, co mówią o Twoim sklepie.
Najczęstsi winowajcy w sklepach, które widzimy: zdjęcia produktowe prosto z aparatu (4000 × 3000 px, 2–4 MB), atrybut loading="lazy" na obrazie LCP — czyli leniwe ładowanie tego, co ma pojawić się pierwsze — oraz banery cookie i wtyczki newsletterowe wstrzykujące elementy nad treścią. Przy LCP zamiast lazy ustaw fetchpriority="high" i podaj obraz w WebP.
Skąd brać dane: raport CrUX w PageSpeed Insights pokazuje wyniki z ostatnich 28 dni od realnych użytkowników. W Search Console, w sekcji „Podstawowe wyniki internetowe”, widzisz to samo pogrupowane po adresach — i to jest liczba, którą warto raportować. Dane laboratoryjne z Lighthouse to jedna symulacja na laptopie: przydają się do debugowania, ale nie odpowiadają telefonowi w terenie. Definicje i progi zebrano w dokumentacji web.dev – Core Web Vitals.
| Metryka | Próg „dobry” | Typowa przyczyna w sklepie |
|---|---|---|
| LCP | poniżej 2,5 s | za duże zdjęcie hero lub produktu, lazy-load na obrazie LCP, wysoki TTFB serwera |
| INP | poniżej 200 ms | wtyczki blokujące główny wątek: rekomendacje produktów, czat, rozbudowane filtry |
| CLS | poniżej 0,1 | baner cookie bez zarezerwowanego miejsca, fonty bez font-display, wstrzykiwane reklamy |
W PrestaShop kolejność działań waży więcej niż liczba wtyczek. Poniżej lista od największego zysku.
app/config/parameters.php.displayHeader dokłada CSS i JS do każdej podstrony. Nieużywany suwak, czat, licznik — do wyłączenia.Obrazy. PrestaShop generuje kilka miniatur na produkt (m.in. cart_default, home_default, medium_default, large_default). Zostaw tylko te, których faktycznie używa szablon, włącz WebP i popraw wymiary w Ustawieniach obrazów. Regeneracja 5000 miniatur z panelu kończy się timeoutem — rób to skryptem CLI. W szablonie classic zadbaj o poprawne srcset, żeby telefon nie pobierał zdjęcia 800 px.
Baza danych. Tabele ps_connections, ps_page_viewed i ps_guest rosną do milionów wierszy — jeśli nie analizujesz statystyk, wyłącz ich zbieranie i czyść je cronem. Sprawdź indeksy na ps_product_lang i ps_category_product, włącz slow query log z long_query_time = 1. Kategoria z 2000 produktów i filtrami fasetowymi potrafi wygenerować setki zapytań na jedno wejście — to widać dopiero w logu bazy, nie w panelu. Kolejność i zakres prac po stronie kodu opisujemy przy okazji organizacji wdrożeń i migracji PrestaShop.
Hosting. Najczęstsza przyczyna wolnego WooCommerce to hosting współdzielony z limitem 256 MB RAM na proces PHP. Sklep z 25 wtyczkami potrzebuje ich kilka równolegle, PHP-FPM zabija procesy, a TTFB skacze do 1,5–3 s. Punkt wyjścia: 2 vCPU, 4 GB RAM, dysk NVMe, PHP 8.1–8.3 z OPcache i MySQL 8.0 lub MariaDB 10.6. Na hostingu współdzielonym dochodzi jeszcze I/O od „sąsiadów” na tym samym serwerze — tego nie naprawisz wtyczką.
Cache. Potrzebujesz dwóch warstw. Page cache (LiteSpeed Cache, jeśli serwer to LiteSpeed, albo WP Rocket) oraz object cache na Redis przez wtyczkę Redis Object Cache — w WooCommerce drugie jest kluczowe, bo zapytania o produkty i terminy powtarzają się przy każdym wejściu. Konsekwentnie wyklucz z page cache: /koszyk/, /zamowienie/, /moje-konto/ i cały checkout. Mini-koszyk w nagłówku zostaw na AJAX. Zbyt agresywny cache bez wykluczeń to nie teoria — widzieliśmy sklepy, w których klient zobaczył zawartość cudzego koszyka.
Higiena wtyczek i bazy. Zainstaluj Query Monitor i zmierz TTFB oraz liczbę zapytań przed i po. Wyłączaj wtyczki grupami po 5 na kopii i mierz — 30 wtyczek po 50 ms to już 1,5 s. Wtyczki filtrów produktów budują JOIN-y na wp_postmeta; na listingu norma to 60–100 zapytań, a powyżej 200 zaczyna się problem. Wyłącz rewizje wpisów, czyść transienty i sprawdź rozmiar wp_options — potrafi urosnąć do setek megabajtów. Zakres typowego wdrożenia opisaliśmy w materiale o optymalizacji WooCommerce.
Wizytówka Google daje efekty tylko wtedy, gdy po kliknięciu użytkownik trafia na szybką, spójną stronę. Zacznij od trzech pól: kategoria główna (np. hurtownia budowlana, a nie firma), kilka kategorii dodatkowych zgodnych z realną ofertą i obszar działania. Obszar działania nie jest promieniem rankingowym — wpisujesz tam miejscowości, do których faktycznie dowozisz towar, bo to informacja dla klienta, a nie dla algorytmu.
Dane NAP (nazwa, adres, telefon) muszą być identyczne w wizytówce, na stronie kontakt, w stopce i w danych strukturalnych LocalBusiness. Rozjazd typu „ul.” kontra „ulica” albo inny format numeru telefonu to klasyczna przyczyna słabego dopasowania. Zdjęcia wgrywaj do wizytówki regularnie, a te na stronie kompresuj do WebP po 100–200 KB — jedna grafika 3 MB potrafi zepsuć LCP całej kategorii.
Strony pod lokalizacje mają sens tylko wtedy, gdy każda jest inna. Osobny adres dla Frampola, Zamościa, Biłgoraja i Zwierzyńca z tym samym tekstem i podmienioną nazwą to dla Google strony drzwiowe. Każda potrzebuje własnego H1, self-canonicala, opisu dojazdu lub terminu dostawy na danej trasie i lokalnego zdjęcia. Zasady opisuje wprost dokumentacja Google o treściach tworzonych dla ludzi.
Długi ogon lokalny to frazy z miejscowością plus kategoria plus dostawa, sklep albo hurt. Wolumeny są małe, często kilkadziesiąt wyszukiwań miesięcznie, ale konkurencja bywa zerowa. Sprawdź je w Planerze słów kluczowych, zanim zaczniesz pisać. Sama technika w pozostałych miejscowościach regionu działa identycznie — przykład dla sąsiedniego miasta znajdziesz w materiale o SEO technicznym i optymalizacji szybkości w Zwierzyńcu.
| Lokalizacja | Co musi być unikalne | Wzorzec frazy | Uwaga techniczna |
|---|---|---|---|
| Frampol | Adres punktu odbioru, godziny, zdjęcia z miejscowości | dostawa [kategoria] Frampol | Rolę strony lokalnej pełni zwykle strona główna lub kontakt — nie twórz duplikatu |
| Zamość | Opis tras i realnych terminów dostaw | hurt [kategoria] Zamość | Osobny URL, self-canonical, link zwrotny do kategorii |
| Biłgoraj | Opinie i realizacje klientów z tego miasta | sklep [kategoria] Biłgoraj | Minimum 300 słów unikalnego tekstu, bez kopiowania akapitów |
| Zwierzyniec | Sezonowość i inne godziny pracy | dostawa [kategoria] Zwierzyniec | Własny H1, własne zdjęcia, inny tytuł i meta description |
Te siedem problemów odpowiada za większość spadków widoczności i wolnego ładowania w sklepach, które trafiają do naszego audytu. Każdy da się wykryć w kilka minut, bez płatnych narzędzi.
Brak indeksacji kluczowych stron — wejdź w Search Console → Indeksowanie → Strony i sprawdź, czy kategorie i produkty nie siedzą w koszu „Wykluczone”. Najczęstsza przyczyna to noindex zostawiony po pracach na kopii testowej. Duplikaty przez parametry URL i tagi — filtry i sortowanie (?orderby=, ?page=) oraz widoki tagów generują setki adresów z tą samą treścią. Sprawdź raport „Zindeksowane, ale nie wysłane” i ustaw self-canonical na widokach filtrowanych. Mixed content po migracji na HTTPS — DevTools → Console pokaże ostrzeżenia o plikach ładowanych po http, a ikona kłódki w pasku adresu będzie przekreślona. Lazy-load na obrazie hero — jeśli baner ma loading=lazy, LCP rośnie o kilkaset milisekund. Sprawdź w DevTools → Elements i ustaw loading=eager oraz fetchpriority=high.
Skrypty blokujące renderowanie w sekcji head — Lighthouse wypisze je w punkcie Eliminate render-blocking resources. Przenieś je na koniec body albo dodaj defer. Zbyt agresywny cache dla zalogowanych — klient dodaje produkt, a koszyk pokazuje stan sprzed kilku minut. Sprawdź nagłówki komendą curl -I na adresie koszyka; Cache-Control: public w tym miejscu to błąd. Błędne nagłówki odpowiedzi — 301 prowadzące do 404, 302 zamiast 301, brak nagłówka HSTS. Warto znać punkt odniesienia: progi Core Web Vitals opisane na web.dev. Kolejność napraw i sposób pracy nad motywem opisujemy w materiale o wdrożeniach i migracjach PrestaShop w Frampolu.
| Błąd | Jak wykryć | Co poprawić |
|---|---|---|
| Brak indeksacji kluczowych stron | Search Console → Indeksowanie → Strony; wynik site:twojadomena.pl | Zdejmij noindex, popraw robots.txt, wyślij mapę XML |
| Duplikaty z parametrów URL i tagów | Search Console → Zindeksowane, ale nie wysłane | Self-canonical na widokach filtrowanych, konfiguracja tagów |
| Mixed content po HTTPS | DevTools → Console, ostrzeżenia o treści mieszanej | Podmień adresy http:// na https:// w treściach i szablonach |
| Lazy-load na obrazie hero | DevTools → Elements, atrybut loading na banerze | loading=eager, fetchpriority=high, preload dla obrazu LCP |
| Skrypty blokujące renderowanie | Lighthouse → Eliminate render-blocking resources | defer, przeniesienie na koniec body, krytyczny CSS |
| Cache również dla zalogowanych | curl -I na /koszyk i /moje-konto, nagłówek Cache-Control | Wyklucz koszyk, konto i strony z sesją z cache |
| Błędne przekierowania i nagłówki | DevTools → Network, kolumna Status | Popraw łańcuchy 301, ustaw docelowe 301 zamiast 302 |
Kolejność prac nie jest kwestią upodobań. Najpierw audyt, potem poprawki krytyczne, dopiero później cache i obrazy. Jeśli zaczniesz od kompresji grafik w sklepie, który ma noindex na kategoriach, poprawiasz coś, czego nikt nie widzi.
Audyt zajmuje zwykle 4–8 godzin: robots.txt, mapa XML, statusy odpowiedzi, canonicale, stan indeksacji, nagłówki, logi serwera i pomiar bazowy. Poprawki krytyczne to 6–16 godzin — widełki zależą od tego, czy problem leży w konfiguracji, czy w kodzie motywu. Cache, kompresja obrazów i kolejność ładowania zasobów: 2–8 godzin. Dalsze optymalizacje po pomiarach: 8–24 godziny rozłożone w czasie, bo część zmian trzeba zweryfikować na realnym ruchu.
Pracochłonność rośnie wraz z liczbą produktów i integracji. Katalog 20 000 SKU wymaga innego podejścia do generowania miniatur i indeksacji niż 200 pozycji. Do tego dochodzą ERP, magazyn, Baselinker czy Subiekt — każda integracja to dodatkowe zapytania po stronie serwera. Prace w motywie rób na kopii i przez child theme; punkt wyjścia znajdziesz w dokumentacji deweloperskiej PrestaShop.
Pomiar przed i po: zapisz wynik dla 3–5 adresów (strona główna, kategoria, produkt) w Lighthouse dla mobile i desktop, a po zmianach porównaj raport Core Web Vitals w Search Console — dane użytkowników potrzebują około 28 dni, więc nie oceniaj efektu po dwóch dniach. Opiekę po wdrożeniu zapisz w umowie z konkretnym SLA. Podobny zakres dla sklepów na innym silniku opisujemy w tekście o wdrożeniach i optymalizacji WooCommerce w Józefowie.
| Etap | Zakres | Typowy czas pracy | Kiedy |
|---|---|---|---|
| Audyt | robots.txt, mapa, canonicale, indeksacja, nagłówki, logi, pomiar bazowy | 4–8 h | Zawsze pierwszy |
| Poprawki krytyczne | Noindex, duplikaty, przekierowania, HTTPS, błędy 404 | 6–16 h | Bezpośrednio po audycie |
| Cache i obrazy | Konfiguracja cache, WebP, lazy-load, kolejność zasobów | 2–8 h | Po poprawkach krytycznych |
| Optymalizacje po pomiarach | CSS krytyczny, kolejne iteracje wydajności, testy A/B | 8–24 h | Po 28 dniach danych z CWV |
| Opieka po wdrożeniu | Monitoring, aktualizacje, reakcja na regresje | wg pakietu godzin | Zapisane w SLA |
Optymalizacja na wyczucie, bez zapisanego stanu wyjściowego. Po miesiącu nikt nie pamięta, jak sklep działał przed zmianami, więc nie da się powiedzieć, czy cokolwiek się poprawiło.
Jak wykryć: Sprawdź, czy masz jakikolwiek zrzut ekranu z PageSpeed Insights albo eksport raportu z Google Search Console z datą sprzed wdrożenia. Jeśli nie — nie masz punktu odniesienia.
Jak naprawić: Zrób pomiar „przed” i zapisz go jako plik z datą w nazwie (zrzut ekranu + eksport CSV z GSC dla mobile i desktop). Ten sam zestaw narzędzi powtórz po wdrożeniu.
Zmiany wprowadzane bezpośrednio na działającym sklepie, bez kopii zapasowej i środowiska testowego. Pierwszy błąd w konfiguracji potrafi wyłączyć koszyk w środku dnia.
Jak wykryć: Sprawdź w panelu hostingu datę ostatniej kopii bazy i plików. Jeśli jest starsza niż 24 godziny albo nie wiesz, jak ją odtworzyć — to jest problem.
Jak naprawić: Zanim cokolwiek zmienisz, zrób kopię bazy i plików oraz sprawdź, czy umiesz ją odtworzyć. Poważniejsze zmiany testuj najpierw na kopii sklepu na osobnym adresie z blokadą indeksowania (noindex).
Wdrażanie wszystkiego naraz: cache, kompresja, nowy szablon, konwersja zdjęć, przebudowa kategorii. Gdy coś się zepsuje, nie wiadomo co.
Jak wykryć: Popatrz na swoją listę zadań — jeśli nie ma na niej priorytetów ani dat, a wszystkie pozycje są „do zrobienia w tym tygodniu”, to znak, że idziesz na raz.
Jak naprawić: Ustal kolejność od największego zysku: najpierw hosting i cache, potem obrazy, potem baza i moduły. Wdrażaj jedną zmianę, mierz efekt, dopiero potem następną.
Włączenie agresywnego cache bez wykluczenia koszyka, kasy i strony zalogowanego klienta. Klient dodaje produkt, a sklep pokazuje mu cudzy koszyk albo pustą stronę.
Jak wykryć: Wejdź na stronę sklepu jak zwykły użytkownik, dodaj produkt do koszyka, odśwież stronę kilka razy, potem zaloguj się i powtórz test na innym urządzeniu.
Jak naprawić: Dodaj do wykluczeń cache koszyk, kasę, stronę mojego konta i wszystkie adresy z parametrami sesji. Po każdej zmianie konfiguracji powtórz test zakupu od początku do końca.
Przekonanie, że jedna wtyczka od cache albo „optymalizator” załatwi całą szybkość. Takie narzędzia pomagają, ale nie naprawią ciężkiego szablonu, zbyt dużych zdjęć i wolnej bazy.
Jak wykryć: Sprawdź, ile wtyczek lub modułów odpowiada za cache, minifikację i obrazy. Jeśli nakładają się na siebie, często szkodzą bardziej niż pomagają.
Jak naprawić: Wybierz jeden system cache po stronie serwera i jeden mechanizm cache aplikacji. Resztę wyłącz i zmierz różnicę w TTFB przed i po.
Brak właściciela zadania i terminu. Optymalizacja szybkości zostaje jako „kiedyś do zrobienia”, a lista błędów w Search Console rośnie.
Jak wykryć: Zapytaj w firmie, kto konkretnie odpowiada za wdrożenie i kiedy ma być gotowe. Jeśli odpowiedź brzmi „zobaczymy”, zadanie nie istnieje.
Jak naprawić: Wyznacz jedną osobę odpowiedzialną, termin na każdy etap i krótki raport tygodniowy: co wdrożone, jaki wynik, co dalej.
Największym błędem nie jest brak wiedzy o technologii, ale brak organizacji: nikt nie zapisał stanu wyjściowego, nie ma kolejności prac i nikt za nie nie odpowiada. Ustal pomiar „przed”, zrób kopię sklepu, wdrażaj jedną zmianę naraz i mierz efekt tymi samymi narzędziami. Dopiero na tak przygotowanym gruncie poprawki szybkości i SEO technicznego da się rozliczyć, a nie tylko „poczuć”.
Od pomiaru i najtańszych rzeczy, które zwykle dają najwięcej: kompresji i cache na serwerze, zmniejszenia zdjęć oraz wyłączenia zbędnych modułów. Dopiero potem warto inwestować w przebudowę szablonu czy zmiany w bazie. Kolejność ma znaczenie, bo praca nad szablonem przy źle skonfigurowanym hostingu i tak nie przyniesie efektu.
Nie. SEO techniczne obejmuje m.in. plik robots.txt, mapę strony, adresy kanoniczne, przekierowania 301, strukturę adresów URL i dane strukturalne dla produktów. Szybkość jest jednym z jego elementów, mocno widocznym w Core Web Vitals — ale sam szybki sklep nie naprawi błędów indeksacji. Szczegóły znajdziesz w dokumentacji Core Web Vitals w Google Search Central.
Nie ma jednej liczby — zależy od stanu sklepu, liczby modułów i tego, czy poprawki robisz własnymi siłami, czy zlecasz. Realistyczne podejście to podział na etapy i pomiar po każdym z nich, a nie jedno wielkie wdrożenie. Przed podaniem terminu trzeba najpierw zobaczyć pomiar wyjściowy i listę problemów.
Może, jeśli koszyk, kasa i strona zalogowanego klienta nie są wykluczone z cache. Objawia się to pustym koszykiem, dziwnymi cenami albo komunikatem o błędzie przy składaniu zamówienia. Dlatego po każdej zmianie konfiguracji trzeba przejść pełną ścieżkę zakupu na telefonie i na komputerze — to zajmuje kilka minut, a ratuje sprzedaż.
Nie. Lighthouse mierzy w warunkach laboratoryjnych, na jednym urządzeniu i w jednej chwili. O tym, jak sklep działa naprawdę, mówią dane użytkowników — raport CrUX w PageSpeed Insights oraz raport Core Web Vitals w Search Console. Dopiero zestawienie obu źródeł pokazuje, czy problem jest realny, czy tylko testowy. Więcej o metrykach pisze web.dev.
Raz nie wystarczy. Każda aktualizacja sklepu, nowa wtyczka czy moduł mogą pogorszyć szybkość i indeksację — często bez widocznego objawu. Praktyczny rytm to krótki przegląd po każdej większej zmianie i pełniejszy audyt raz na kwartał. Jeżeli prowadzisz sklep na PrestaShop i planujesz prace porządkowe, punktem wyjścia może być organizacja wdrożeń i migracji PrestaShop.
Jeśli wolisz zacząć od konkretnej listy działań dla swojego sklepu, napisz do nas krótko, na czym stoi Twoja strona — powiemy, od czego zacząć. Zajmujemy się też szybkością sklepów WooCommerce, o czym pisaliśmy przy okazji optymalizacji WooCommerce.