SEO techniczne i optymalizacja szybkości w Szczebrzeszynie to praca nad tym, co widzi robot Google: indeksacją, strukturą adresów, czasem odpowiedzi serwera i bezpieczeństwem. Nie chodzi o teksty ani o linki — te mają sens dopiero wtedy, gdy techniczny fundament nie blokuje wejścia. W praktyce dla firmy z Lubelszczyzny oznacza to zwykle mniejszy ruch niż w sklepie ogólnopolskim i większą wagę telefonu oraz wizytówki Google. Dlatego zamiast gonić za każdym punktem PageSpeed, najpierw ustalamy liczby, które strona faktycznie musi osiągnąć. Zakres takiej pracy opisujemy szerzej na stronie SEO techniczne i optymalizacja szybkości — Szczebrzeszyn.
SEO techniczne to praca nad warstwą, której klient nie widzi: czy robot Google w ogóle wejdzie na stronę, jak szybko dostanie odpowiedź od serwera, jak zbudowane są adresy i czy strona nie wycieka danych przez niezabezpieczone formularze. W praktyce dotyczy pięciu obszarów: indeksacji, struktury adresów i linkowania wewnętrznego, czasu odpowiedzi i renderowania, bezpieczeństwa (HTTPS, nagłówki, poprawny SSL) oraz danych strukturalnych. To nie są teksty ani grafiki — to konfiguracja serwera, motywu i plików takich jak robots.txt oraz sitemap.xml.
Rozgraniczenie jest proste. SEO techniczne decyduje, czy strona może pojawić się w wynikach. Treść decyduje, na jaką frazę. Linki decydują, czy ktoś uzna ją za wiarygodną. Podstrona z najlepszym opisem usługi nie zadziała, jeśli jest zablokowana w robots.txt, ma canonical wskazujący na inny adres albo renderuje się 9 sekund na telefonie.
Opóźnienie przekłada się na pieniądze, choć nie liniowo. Branżowe zestawienia pokazują rząd wielkości: każda dodatkowa sekunda ładowania to kilka procent porzuconych koszyków. Przy sklepie robiącym 200 zamówień miesięcznie oznacza to kilka transakcji — nie katastrofę, ale wystarczająco, żeby nie ignorować tematu. Traktuj to jako kierunek, nie jako gwarancję wzrostu.
Firma ze Szczebrzeszyna ma inne priorytety niż sklep ogólnopolski. Ruch lokalny jest mniejszy, więc każda wizyta jest cenniejsza. Większość wejść to telefon, a spora część klientów trafia z wizytówki Google, nie z listy wyników. Dlatego zanim zlecisz prace, sprawdź zakres i progi dla swojej sytuacji — opisujemy je w sekcji SEO techniczne i optymalizacja szybkości w Szczebrzeszynie.
Zamiast dyskutować, czy strona jest szybka, porównaj ją z progami. Google ocenia trzy metryki i publikuje dla nich jednoznaczne przedziały.
Skąd biorą się liczby? Z Chrome UX Report — danych od realnych użytkowników Chrome, agregowanych w 28-dniowym oknie i liczonych na 75. percentylu. To znaczy, że jedna wolna wizyta nie psuje oceny, ale też jedna szybka jej nie ratuje. Wynik odzwierciedla to, co przeciętnie dostaje trzech na czterech użytkowników.
Dane laboratoryjne (PageSpeed Insights, Lighthouse) i rzeczywiste (CrUX) mierzą co innego. Laboratorium pokazuje, co da się poprawić — pełną listę zadań: nieużywany CSS, za duże obrazy, długie zadania w JavaScript. Dane rzeczywiste pokazują, czy poprawki dotarły do użytkowników. Potrzebne są oba, bo laboratorium bez CrUX to optymalizacja w teorii, a CrUX bez laboratorium to wynik bez instrukcji naprawy.
Gdzie to sprawdzić: Search Console, sekcja Doświadczenie, raport Core Web Vitals. Zobaczysz osobno grupę adresów dla mobilnych i dla desktopu — w praktyce mobilna prawie zawsze wypada gorzej i to ona wymaga pracy. Osobno sprawdzaj adresy z błędem, osobno te oznaczone jako wymagające poprawy.
Kiedy wynik 78 w PageSpeed jest w porządku? Gdy pole pochodzi z CrUX i jest zielone. Kiedy 92 to problem? Gdy w laboratorium wszystko wygląda dobrze, ale INP w danych rzeczywistych wynosi 400 ms — bo wąskie gardło siedzi w obsłudze kliknięć: nasłuchiwacze zdarzeń, pluginy, zewnętrzne skrypty czatu. Progi znajdziesz w dokumentacji Web Vitals na web.dev. Sąsiednie wdrożenia w regionie opisujemy też w materiale o SEO technicznym i optymalizacji szybkości w Zamościu.
| Metryka | Dobry | Wymaga poprawy | Zły |
|---|---|---|---|
| LCP (największy element) | do 2,5 s | 2,5–4,0 s | powyżej 4,0 s |
| INP (reakcja na klik) | do 200 ms | 200–500 ms | powyżej 500 ms |
| CLS (przesunięcia układu) | do 0,1 | 0,1–0,25 | powyżej 0,25 |
Zanim wydasz złotówkę na audyt, zrób siedem rzeczy. Zajmą pół godziny i dadzą ci punkt odniesienia.
Jak oddzielić hosting od kodu? Wgraj na ten sam serwer plik test.html z jednym akapitem tekstu i zmierz TTFB. Statyczny plik z TTFB 700 ms oznacza problem hostingu lub bazy. Jeśli statyczny ma 150 ms, a koszyk 1,8 s — wąskie gardło jest w kodzie i zapytaniach, nie w serwerze.
Zakres audytu zależy od skali. Sklep z 200 produktami przejdziesz ręcznie: 20 podstron, robots, sitemap, mobile, koszyk. Katalog 5000+ SKU wymaga analizy logów serwera, paginacji, filtrów fasetowych i canonicali — bez tego audyt jest niepełny.
Zapisz baseline przed zmianami: LCP, INP, CLS (mobile i desktop), TTFB, liczbę zapytań do bazy na stronie głównej i kategorii, wagę strony oraz rozmiar plików JavaScript. Wrzuć do arkusza z datą. Bez tego nie udowodnisz, czy wdrożenie cokolwiek poprawiło. Przykład takiego pomiaru w mniejszym mieście opisujemy przy okazji SEO technicznego i optymalizacji szybkości w Hrubieszowie.
Zanim cokolwiek zmienisz, ustal, co realnie spowalnia sklep. Wymiana serwera, który nie był problemem, to najczęstszy sposób przepalenia budżetu.
Winowajcą numer jeden jest zwykle motyw, nie serwer. Motywy z wbudowanym page builderem ładują dziesiątki plików CSS i JS na każdej podstronie. Test: na kopii sklepu przełącz na motyw domyślny i porównaj liczbę żądań oraz LCP. Progi metryk znajdziesz w dokumentacji Web Vitals.
Pułapka: wyłączenie modułu nie usuwa jego skryptów z frontendu. Kod mógł zostać wklejony na sztywno do header.tpl lub plików motywu. Sprawdź widok źródła (Ctrl+U) i wyszukaj nazwę wyłączonego modułu — jeśli nadal się pojawia, dezaktywacja nic nie dała. Podobną diagnostykę prowadzimy przy pracach nad optymalizacją szybkości i SEO technicznym w Hrubieszowie.
Kolejność ma znaczenie, bo część optymalizacji nie przynosi efektu, dopóki poprzedni krok nie jest zrobiony. Redukcja CSS przy TTFB 1,2 s to praca wrzucona do kosza — użytkownik czeka na odpowiedź serwera, nie na reguły stylów.
Widełki poniżej dotyczą typowego sklepu MŚP z katalogiem 500-2000 produktów. Przy 20 000 SKU krok „baza danych” rośnie nawet trzykrotnie.
W praktyce dwa kroki dają najwięcej przy najmniejszym nakładzie: pełnopage cache z cache obiektowym oraz kompresja obrazów. Razem 6-18 h pracy i zwykle to wystarcza, żeby zejść z LCP 4-5 s do 2-2,5 s. Hosting wysuwa się na pierwsze miejsce tylko wtedy, gdy TTFB bez cache przekracza 600 ms.
Czego nie robić na starcie. Nie przepisuj sklepu od zera — to 3-6 miesięcy i realne ryzyko utraty ruchu. Nie wymieniaj platformy „przy okazji”. Nie zmieniaj motywu bez planu migracji: motyw to nie tylko wygląd, ale szablony i przypisane hooki, więc po zmianie często znikają niestandardowe pola produktu i sekcje CMS.
Wdrożenie bez przestoju. Kopia na subdomenie (staging) z hasłem i noindex, test na pięciu realnych adresach: strona główna, kategoria z filtrami, produkt, koszyk, podziękowanie za zamówienie. Backup plików i bazy przed oknem, okno wdrożeniowe 22:00-2:00, gotowy plan wycofania — przywrócenie backupu w 15-30 min. Orientacyjny koszt SEO technicznego i optymalizacji szybkości w Zamościu pokazuje, jak takie prace wyceniamy u podobnych firm.
| Krok | Nakład | Spodziewany efekt |
|---|---|---|
| Hosting i TTFB | 2-6 h (głównie migracja) | TTFB z 800-1500 ms do 200-400 ms |
| Cache stron i cache obiektowy | 2-6 h | TTFB 60-200 ms, 60-90% mniej zapytań do bazy |
| Obrazy (WebP/AVIF, wymiar do 1600 px, 150-250 kB) | 4-12 h | LCP na karcie produktu niższe o 30-50% |
| CSS i JS (krytyczny CSS, defer) | 6-16 h | 200-600 ms mniej w FCP i TBT |
| Baza danych (indeksy, czyszczenie ps_log, wp_options) | 4-12 h | Zapytania katalogowe z 300-800 ms do 30-120 ms |
| CDN | 2-4 h | Zauważalne przy ruchu z całej Polski, pomijalne lokalnie |
Indeksacja. Zacznij od Search Console → Indeksowanie → Strony. Trzy liczby, które trzeba znać: „Zaindeksowane”, „Wykluczone przez znacznik noindex” i „Alternatywna strona z prawidłowym tagiem canonical”. Jeśli kategoria z 200 produktami wypada z indeksu, to prawie zawsze przypadkowy noindex — w PrestaShop w zakładce SEO i URL przy kategorii, w WooCommerce globalnie w Ustawienia → Czytanie albo w ustawieniach wtyczki SEO. Klasyka: noindex ze stagingu skopiowany na produkcję.
Przekierowania. Łańcuch A → B → C kosztuje czas i gubi część sygnału. 302 zostaw tylko tam, gdzie zmiana naprawdę jest tymczasowa; przy migracji adresów produktów używaj 301. Sprawdzisz to w Screaming Frog albo przez curl -I.
Canonical. Największe źródło duplikacji w sklepach to filtry, sortowanie i paginacja: ?filter=, ?orderby=, ?page=2. Wersja z filtrem powinna wskazywać canonical na czystą kategorię, a kombinacje filtrów najlepiej wyłączyć z indeksu. Paginacja to inny przypadek: kolejne strony potrzebują self-canonical, a nie wskazania na stronę pierwszą.
sitemap.xml i robots.txt. Najczęstsze błędy: Disallow dla /wp-content/ i /themes/, co blokuje CSS i JS potrzebne Google do renderowania; sitemap zawierająca adresy z noindex; robots.txt ze stagingu wgrany na produkcję z wpisem Disallow: /. Sprawdź, czy sitemap jest zadeklarowana w robots.txt i czy zwraca kod 200.
Dane strukturalne. Product, Offer i BreadcrumbList nie podnoszą pozycji bezpośrednio. Realnie dają szansę na rozszerzony wynik z ceną, dostępnością i oceną oraz na ścieżkę okruszków. Błędny Offer — bez ceny, waluty lub availability — cofa wynik do zwykłego. Wymagania opisuje dokumentacja Google dotycząca danych strukturalnych.
HTTPS i wersja domeny. Jedna wersja: https://twojadomena.pl z przekierowaniem 301 z http, z www i z bez www. Do tego certyfikat i brak mieszanej treści.
| Element | Typowy błąd | Skutek |
|---|---|---|
| robots.txt | Disallow dla /wp-content/ lub /themes/ | Google nie renderuje strony, widzi wersję bez stylów |
| sitemap.xml | Adresy z noindex lub za przekierowaniem 302 | Marnowanie budżetu indeksacji |
| Canonical na filtrach | Warianty ?filter= wskazują same na siebie | Dziesiątki zdublowanych adresów w indeksie |
| http/https i www | Brak wymuszenia jednej wersji | Dwie wersje witryny, rozdzielone sygnały |
| Offer | Brak ceny, waluty lub availability | Brak rozszerzonego wyniku produktowego |
Wizytówka Google (Google Business Profile) dla firmy ze Szczebrzeszyna często generuje więcej telefonów niż sama strona. Zacznij od kategorii głównej: wybierz najwęższą, jaka pasuje — „Sklep z częściami samochodowymi” zamiast „Sklep”, „Usługi hydrauliczne” zamiast „Usługi budowlane”. Kategoria główna decyduje o tym, w jakich zapytaniach lokalnych w ogóle się pokażesz.
Dane NAP (nazwa, adres, telefon) muszą być identyczne znak po znaku w każdym miejscu:
Szybka weryfikacja spójności: wpisz nazwę firmy w cudzysłowie w Google i przejrzyj pierwsze 10 wyników, potem wejdź na 3–5 katalogów i porównaj ciąg znaków. Popraw tam, gdzie masz dostęp do profilu.
Obszar działania wokół Szczebrzeszyna ustaw jako listę miejscowości, nie promień: Szczebrzeszyn, Zamość, Zwierzyniec, Radecznica, Sułów, Nielisz, Tereszpol, gmina Zamość. Zdjęcia: 10–15 na start (elewacja z ulicy, wnętrze, zespół, realizacje), potem 2–4 nowe miesięcznie. Opinie zbieraj SMS-em 24 h po realizacji, z krótkim linkiem, i odpowiadaj na każdą w ciągu 48 h.
Strona lokalna czy doorway page? Test jest prosty: podmieniasz „Szczebrzeszyn” na „Narol” i treść nadal nic nie wnosi? To doorway. Wartościowa strona lokalna ma co najmniej jeden element, którego nie da się wygenerować automatycznie: zdjęcie realizacji z konkretnej ulicy, nazwę klienta (za zgodą), realny czas dojazdu, obsługę konkretnej instytucji z powiatu zamojskiego.
Treści lokalne, które działają: realizacje z powiatu zamojskiego, warunki dostawy (InPost, DPD, DHL — ile dni), formy płatności (BLIK, Przelewy24, przelew), odbiór osobisty i godziny. Jeśli obsługujesz też Zamość, zobacz SEO techniczne i optymalizacja szybkości w Zamościu dla firm, a dla mniejszych miejscowości — SEO techniczne i optymalizacja szybkości w Narolu.
| Element wizytówki | Co ustawić dla firmy ze Szczebrzeszyna |
|---|---|
| Kategoria główna | Najwęższa pasująca, np. „Usługi hydrauliczne”, nie „Usługi budowlane” |
| Obszar działania | Lista miejscowości: Szczebrzeszyn, Zamość, Zwierzyniec, Radecznica, Sułów, Nielisz, Tereszpol |
| Zdjęcia | 10–15 na start, potem 2–4 nowe miesięcznie |
| Opinie | Prośba SMS 24 h po realizacji, odpowiedź w ciągu 48 h |
| NAP | Identyczny zapis w GBP, stopce, katalogach i social media |
Nie publikujemy cennika „od–do”, bo identyczna z wyglądu strona dla dwóch firm może kosztować zupełnie różne kwoty. Rozliczamy się za godziny, a ich liczbę ustalamy przed startem. Poniżej realne widełki z naszych wdrożeń.
Koszt to liczba godzin pomnożona przez stawkę ustaloną w ofercie. Nie zmieniamy jej w trakcie projektu — jeśli zakres się rozszerza, dostajesz nową wycenę do akceptacji, zanim ktokolwiek zacznie pracę.
Co podnosi cenę:
Opieka po wdrożeniu obejmuje: monitoring dostępności (sprawdzenie co 1–5 minut), codzienne kopie zapasowe z retencją 30 dni i testem odtworzenia raz na kwartał, aktualizacje rdzenia, modułów i wersji PHP oraz reakcję w ramach SLA — awaria krytyczna w 2 h, drobne zgłoszenia w 2 dni robocze.
Na piśmie przed startem dostajesz: zakres prac, liczbę godzin, imię i nazwisko osoby kontaktowej z adresem e-mail, sposób raportowania (cotygodniowy raport z listą zmian i pomiarów) oraz kryteria odbioru. Pracujesz bezpośrednio z deweloperem, bez pośredników przekazujących kontekst — to skraca wdrożenie o dni, a każde pominięte ogniwo to godziny, których nie płacisz.
| Zakres | Typowa liczba godzin | Kiedy tak jest |
|---|---|---|
| Audyt techniczny | 8–16 h | Strona lub sklep do ok. 500 SKU, jeden szablon |
| Audyt techniczny | 20–40 h | 5–20 tys. SKU, multistore, integracja ERP |
| Wdrożenie optymalizacji | 20–60 h | WordPress/WooCommerce, kilka wtyczek, jeden język |
| Wdrożenie optymalizacji | 60–150 h | PrestaShop z wieloma modułami, filtrami i wersjami językowymi |
| Opieka miesięczna | 4–10 h/mies. | Monitoring, kopie zapasowe, aktualizacje, reakcja SLA |
Bez baseline'u nie ma dowodu na efekt. Przed pierwszym commitem zapisz: LCP, INP i CLS z PageSpeed Insights, TTFB z serwera, współczynnik odrzuceń, liczbę konwersji, pozycje z Search Console za ostatnie 28 dni oraz własne zdarzenie w GA4 — „pierwszy koszyk”. Wszystko z datą i zrzutem ekranu.
Progi, do których dążymy: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1, TTFB ≤ 0,8 s. To cel techniczny, nie cel sam w sobie — zielony wynik w narzędziu nie sprzedaje, jeśli koszyk nadal ładuje się dziesięć sekund.
Dlaczego nie widać efektu po tygodniu: dane z realnych użytkowników są agregowane za 28 dni, więc po wdrożeniu mija około miesiąca, zanim odzwierciedlą zmiany — wyjaśnia to dokumentacja Web Vitals na web.dev. Druga pułapka: strona z ruchem głównie z Lubelszczyzny może nie przekroczyć progu próbki i raport w ogóle się nie pojawi. Wtedy mierzysz się sam przez RUM.
Jak nie zepsuć wyniku: każdy nowy moduł (chat, suwak, piksel, kalkulator) wchodzi najpierw na staging i przechodzi pomiar przed/po. Ustaw budżet wydajności: +50 kB JS i LCP bez pogorszenia o więcej niż 0,2 s. Nie mieści się — moduł nie wchodzi albo ładuje się po interakcji użytkownika.
Kiedy optymalizacja przestaje wystarczać: gdy kolejne miesiące pracy nie ruszają LCP, bo blokuje go szablon z inline CSS i kilkudziesięcioma modułami, albo gdy platforma stoi na niewspieranej wersji PHP. Wtedy licz, nie zgaduj: jeśli roczny koszt opieki zbliża się do jednej trzeciej kosztu nowego wdrożenia, migracja zwraca się szybciej niż dalsze łatanie.
| Okres | Co sprawdzasz | Gdzie |
|---|---|---|
| 30 dni | TTFB, LCP z pomiaru laboratoryjnego, błędy 4xx/5xx w logach, indeksacja nowych adresów | PageSpeed Insights, Search Console (Indeksowanie) |
| 60 dni | INP i CLS z realnych użytkowników, pozycje, konwersje | Raport Core Web Vitals w Search Console, GA4 |
| 90 dni | Trend konwersji i czasu do pierwszego koszyka, koszt utrzymania | GA4, raport wdrożeniowy |
Optymalizacja bez zapisania punktu wyjścia — nikt nie wie, czy cokolwiek się poprawiło.
Jak wykryć: Pytasz wykonawcę o wyniki LCP, INP i CLS sprzed zmian i nie ma żadnego zrzutu ani arkusza z pomiarami.
Jak naprawić: Przed pierwszą zmianą zapisz w arkuszu: LCP/INP/CLS dla mobile i desktop, TTFB, liczbę żądań i całkowity rozmiar strony. Bez baseline każda późniejsza dyskusja to zgadywanie.
Mylenie wyniku z PageSpeed Insights (Lighthouse) z realnymi Core Web Vitals z Chrome UX Report.
Jak wykryć: PageSpeed pokazuje 92, a w Search Console raport Core Web Vitals wciąż oznacza część adresów jako „wymaga poprawy”.
Jak naprawić: Traktuj Lighthouse jako narzędzie diagnostyczne do znalezienia przyczyny, a dane CrUX (28-dniowe okno) jako ocenę, którą widzi Google. Obie wartości są potrzebne, ale nie są wymienne.
Testowanie wyłącznie na desktopie, bo tam pracuje właściciel firmy.
Jak wykryć: W PageSpeed Insights wynik mobile jest o 30–50 punktów niższy niż desktop, a w Search Console problemy dotyczą prawie wyłącznie grupy „telefon”.
Jak naprawić: Zawsze zaczynaj od widoku mobilnego. Na Lubelszczyźnie większość ruchu lokalnego przychodzi z telefonu, więc to mobile wyznacza realny próg.
Wyłączanie modułów i wtyczek „na czuja”, bez sprawdzenia, co jeszcze robią.
Jak wykryć: Po dezaktywacji znika funkcja, o której nikt nie pamiętał — np. podatek, sposób dostawy, walidacja NIP — albo wysypuje się koszyk.
Jak naprawić: Pracuj na kopii sklepu. Przed wyłączeniem sprawdź hooki i zależności modułu w dokumentacji (PrestaShop Developer Documentation) i przejdź pełną ścieżkę zakupu.
Dokładanie kolejnych wtyczek cache i minifikacji zamiast diagnozy.
Jak wykryć: Na stronie działa równocześnie kilka warstw cache, a w źródle widać podwójnie zminifikowany CSS lub JS. Po odświeżeniu raz działa, raz nie.
Jak naprawić: Zostaw jedną warstwę cache stron, jedną warstwę cache obiektowego i jedno narzędzie do kompresji. Resztę wyłącz i ponownie zmierz czasy.
Zrzucanie całej winy na hosting bez testu porównawczego.
Jak wykryć: Nie sprawdzono, ile czasu serwer potrzebuje na zwrócenie zwykłego, statycznego pliku HTML leżącego na tym samym koncie.
Jak naprawić: Wgraj na ten sam serwer prostą stronę HTML bez bazy i zmierz TTFB. Jeśli statyk odpowiada szybko, wąskie gardło jest w kodzie lub bazie, a nie w hostingu.
SEO techniczne to uporządkowanie tego, co widzi robot Google: indeksacji, struktury, szybkości i bezpieczeństwa. Dla firmy ze Szczebrzeszyna punktem wyjścia powinny być realne liczby — LCP, INP, CLS, TTFB — a nie wynik z jednego narzędzia. Zanim zaczniesz cokolwiek zmieniać, zapisz baseline, bo bez niego nie odróżnisz poprawy od przypadku. Cała reszta, czyli treści i linki, zaczyna działać dopiero na sprawnym fundamencie.
Nie. Szybkość to jeden z filarów SEO technicznego, obok indeksacji, struktury adresów, danych strukturalnych, canonicali i bezpieczeństwa. Można mieć szybką stronę, której połowa produktów wypada z indeksu, i to nadal będzie problem techniczny. Pracę warto prowadzić w tej kolejności: najpierw dostęp robota do strony, potem szybkość, na końcu drobne usprawnienia.
Wgraj na to samo konto hostingowe prosty plik HTML bez bazy danych i zmierz czas odpowiedzi serwera. Jeśli statyk odpowiada w kilkadziesiąt–kilkaset milisekund, a sklep w kilka sekund, wąskie gardło jest w kodzie, bazie lub konfiguracji, a nie w samym serwerze. Ten jeden test oszczędza najwięcej nieporozumień przy zmianie hostingu.
Nie da się tego ocenić po jednej liczbie, bo PageSpeed Insights pokazuje dane laboratoryjne z Lighthouse, a nie realny pomiar użytkowników. Wynik 78 przy dobrych Core Web Vitals z Chrome UX Report bywa akceptowalny, zwłaszcza jeśli raportowane problemy dotyczą skryptów, których i tak nie usuniesz. Z drugiej strony 92 przy jednoczesnych problemach z INP oznacza coś odwrotnego: strona ładuje się szybko, ale długo reaguje na kliknięcia.
Dane w Search Console liczone są z 28-dniowego okna, więc po wdrożeniu zmian wynik przesuwa się stopniowo — zwykle widać ruch w ciągu dwóch–czterech tygodni. Jedna wolna wizyta nie psuje oceny, tak jak jedna szybka jej nie ratuje. Dlatego oceniaj trend, a nie pojedynczy dzień.
CDN pomaga głównie na dystansie i przy statycznych plikach: obrazach, CSS, JS, fontach. Przy sklepie obsługującym klientów z okolic Szczebrzeszyna zysk bywa mniejszy niż przy sklepie wysyłkowym w całej Polsce — często więcej daje kompresja obrazów i ograniczenie liczby zewnętrznych skryptów. Kolejność powinna być taka: najpierw obrazy i cache, potem CDN, jeśli po pomiarach nadal brakuje czasu.
Minimum raz na kwartał oraz po każdej większej zmianie: aktualizacji sklepu, zmianie motywu, wdrożeniu nowego modułu, dodaniu czatu lub narzędzia analitycznego. Każda z tych zmian potrafi dołożyć skrypt do każdej podstrony. Jeśli nie mierzysz przed i po, nie masz jak tego wychwycić.
Nie podaję tu konkretnych kwot, bo zakres zależy od liczby szablonów, aktywnej bazy produktów i tego, co wyjdzie w pierwszym pomiarze. Sklep z 200 produktami i sklep z katalogiem ponad 5000 SKU to dwie różne prace — w drugim przypadku inaczej wygląda sitemap, indeksacja i odświeżanie cache. Wycenę zawsze zaczynamy od baseline i listy problemów, nigdy od z góry założonej liczby godzin.
Jeśli chcesz wiedzieć, gdzie dokładnie traci czas Twoja strona, zacznij od zapisania dzisiejszych pomiarów — możesz to zrobić sam według listy powyżej. A gdy potrzebujesz drugiej pary oczu przy diagnozie, napisz do nas i opisz, co pokazał test.