Performance sklepu internetowego

Rozmowa nagrana po polsku i opublikowana 17 października 2023 roku. Zapis jest lekko zredagowany: usunęliśmy powtórzenia i wtrącenia, nie zmieniając sensu wypowiedzi. Narzędzia i funkcje Shopify opisujemy w stanie z tamtego czasu, a tam, gdzie coś się zmieniło, dodajemy datowaną aktualizację z listopada 2026 roku.

Dlaczego szybkość sklepu jest ważna dla biznesu

Tomek: Cześć! Witamy was w kolejnym odcinku serii Flying with Shopify. Tematem dzisiejszej rozmowy będzie performance sklepu internetowego, a naszym gościem Kamil Patyk, CTO agencji wecanfly. Zapraszamy. Cześć, panowie.

Kamil: Cześć, Tomku.

Maciek: Cześć, Kamil.

Tomek: Miło, Kamilu, że znalazłeś czas, żeby się z nami dziś spotkać. Chciałbym, żebyśmy porozmawiali o tym, jak w ogóle rozumieć performance sklepu, dlaczego jest ważny i dlaczego naszym zdaniem praca nad nim jest naprawdę istotna z punktu widzenia biznesu. Panowie, chyba zgodzicie się, że nie ma nic bardziej frustrującego w sklepie niż długi czas ładowania. Klient będzie pierwszym, który po prostu zrezygnuje z zakupu. Dlatego o słabym performance mówi się wręcz, że to conversion killer. Co więcej, kiedy klienci przychodzą do nas po audyt sklepu, czy to UX-owy, czy taki, który ma wskazać potencjalne problemy, wydajność jest jednym z głównych elementów, które analizujemy, i często główną przesłanką do tego, co robić dalej i jak ten sklep poprawić. Chciałbym więc, żebyśmy dziś z twoim udziałem, Kamilu, porozmawiali praktycznie: jak do tego podejść, jak pracować nad szybkością sklepu i jakie to może mieć przełożenie na biznes. Maćku, ty najczęściej odpowiadasz na moje pytania o definicje, więc zapytam ciebie: czym jest szybkość sklepu, szybkość witryny? Jak ją mierzyć i kiedy możemy powiedzieć, że sklep jest szybki albo wręcz przeciwnie?

Kiedy możemy powiedzieć, że sklep jest szybki?

Maciek: Myślę, że nikomu nie trzeba tłumaczyć, co to znaczy szybki sklep. Każdy czuje, kiedy strona czy aplikacja wolno działa i wolno się wczytuje. Google rekomenduje, żeby strona wczytywała się maksymalnie w dwie sekundy. A to, o czym mówiłeś, że czas wczytywania strony jest zabójcą konwersji, potwierdza wiele badań i źródeł. W zależności od serwisu wygląda to trochę inaczej, ale średnio każda dodatkowa sekunda wczytywania to spadek konwersji o 0,3 punktu procentowego, więc to dość istotny wskaźnik. Pokazują to też nasze własne doświadczenia: optymalizacja szybkości strony ma największe bezpośrednie przełożenie na user experience. Ale to nie wszystko, bo szybkość strony ma jeszcze dwa ważne aspekty. Po pierwsze wpływa na pozycję strony w Google. To istotny czynnik, który algorytm bierze pod uwagę, wybierając strony do wyświetlenia w odpowiedzi na zapytanie. Po drugie, jeśli używasz reklam Google Ads albo innych reklam pay per click, algorytmy, które decydują, jak często wyświetlać reklamy, też biorą pod uwagę szybkość wczytywania strony, znowu ze względu na cel: dać użytkownikowi jak najtrafniejszą odpowiedź. Wolna strona oznacza więc, że zapłacisz więcej za ten sam efekt. Szybka strona to po prostu dobry biznes. Tak możemy to podsumować.

Aktualizacja 2026: Google nie podaje dziś jednego docelowego czasu wczytania całej strony. Ocenia trzy wskaźniki Core Web Vitals: LCP (czas wyświetlenia największego elementu, dobrze do 2,5 s), INP (reakcja na interakcję, dobrze do 200 ms) i CLS (stabilność układu, dobrze do 0,1), liczone dla 75% wizyt osobno na mobile i desktopie (web.dev).

Co ma realny wpływ na performance sklepu?

Tomek: W porządku. W takim razie pytanie do ciebie, Kamilu. Co tak naprawdę wpływa na performance sklepu? Do tego, czy jest wysoki, czy słaby, zaraz dojdziemy, ale co realnie sprawia, że jest taki, a nie inny?

Kamil: Przede wszystkim od samych podstaw wpływa na niego wybór platformy. Shopify jest nastawiony na szybkie działanie i szybkie ładowanie sklepu, a odpowiada za to szereg rozwiązań, które wypracował, na przykład Shopify Storefront Renderer. To rozwiązanie zapewnia od dwóch do nawet trzech razy szybsze wczytywanie stron w porównaniu z innymi platformami e-commerce. Działa jak sieć dystrybucji, podobnie jak CDN, ale w różnych miejscach na świecie Shopify umieszcza nie tylko pliki pobierane przez przeglądarkę, lecz także system, który renderuje naszą stronę. Dzięki temu klienci z Europy dużo szybciej widzą stronę, bo jest renderowana w ich części świata. Znaczenie ma też cały hosting. W czasie szczytów, takich jak Black Friday, Shopify zapewnia prawie stuprocentowy uptime, czyli dostępność usług. Ta infrastruktura jest bardzo ważna i w dużej części odpowiada za to, jak szybko wczytuje się sklep.

Aktualizacja 2026: Shopify w artykule na swoim blogu inżynierskim z 20 sierpnia 2020 roku podaje, że Storefront Renderer odpowiada średnio 4–6 razy szybciej niż poprzednia implementacja Shopify, czyli porównuje go z własnym starszym silnikiem, a nie z innymi platformami (shopify.engineering).

Maciek: Okej, ale oprócz infrastruktury, czyli hostingu i silnika renderującego, znaczenie ma też sama architektura kodu, to, jak sklep został napisany.

Kamil: Tak, to drugi aspekt i tu dużo więcej zależy od nas, od tego, jak przygotujemy sklep. Poza platformą musimy zadbać o to, żeby storefront był zoptymalizowany pod szybkie wczytywanie. Możemy wykorzystać na przykład architekturę headless, żeby użyć dowolnej technologii i wczytywać tylko te skrypty, które są w danym momencie potrzebne. Ale możemy też skorzystać z tradycyjnego rozwiązania opartego na Liquid w Shopify. Wtedy bardzo ważne będzie, jak przygotujemy witrynę i szablon i jak podejdziemy do jego optymalizacji. To bardzo szeroki temat, ale Shopify nie zostawia nas tu samych i dostarcza wiele rozwiązań, które pomagają budować szybkie szablony.

Jak aplikacje wpływają na szybkość sklepu?

Tomek: Dobrze. Wiemy, że sukces Shopify opiera się nie tylko na wbudowanych funkcjach, ale też na aplikacjach, które merchant może doinstalować, choćby z Shopify App Store. Rodzi się podstawowe pytanie: jak na performance wpływa instalowanie aplikacji, a zwłaszcza ich zbyt duża liczba? Jaką strategię przyjąć, żeby wyważyć wpływ aplikacji na performance i funkcje, które nam dają?

Kamil: Myślę, że trafiłeś w bardzo istotny punkt, bo aplikacje, które rozszerzają funkcje sklepu, bardzo często znacząco wpływają na performance. Każda taka aplikacja dodaje do sklepu dodatkowe zasoby: skrypty JavaScript czy dodatkowe style. Trzeba o tym pamiętać przy wyborze aplikacji, a czasem zastanowić się, czy naprawdę jej potrzebujemy, czy możemy zastąpić jej funkcje czymś, co jest dostępne natywnie w Shopify, albo zbudować je sami, oczywiście z pomocą developera, na poziomie szablonu. To w dużym stopniu poprawi performance sklepu.

Jak mierzyć szybkość sklepu? Narzędzia

Tomek: W porządku. Skoro już wiemy, jak istotny jest performance, co doradzilibyście w zakresie narzędzi do jego mierzenia? Czy Google PageSpeed Insights jest jedynym wyznacznikiem, czy macie lepsze propozycje?

Maciek: To powinien być kolejny krok: skoro wiemy, że to ważne, trzeba to zmierzyć. Większość właścicieli sklepów wie, że najpopularniejszym narzędziem jest Google PageSpeed Insights. Są też alternatywy, jak GTmetrix czy Pingdom. Ten pierwszy daje chyba najbardziej istotne wskazówki, bo te dane są brane pod uwagę przy ocenie strony, choćby przy jej wyświetlaniu w wynikach wyszukiwania. Sam czas wczytywania nie jest tu tak ważny jak w pierwszych wersjach tego narzędzia. Nacisk położono na mierniki, które Google nazywa Core Web Vitals. Odpowiadają one z jednej strony za szybkość, a z drugiej za tak zwaną postrzeganą szybkość, czyli za to, że strona jeszcze się wczytuje, a my już możemy z niej korzystać albo zorientować się, co się wyświetli. Kluczowe mierniki to time to first byte, czyli jak szybko po wywołaniu strony przyjdzie pierwszy sygnał. Cumulative layout shift, który pokazuje, czy w trakcie wczytywania nie skaczą nam sekcje na stronie. Largest contentful paint, który pokazuje, jak duży jest największy zasób potrzebny do wczytania strony. I first contentful paint, czyli ile czasu potrzebujemy, żeby zobaczyć pierwszy obraz i zrozumieć, o co chodzi na stronie.

Aktualizacja 2026: 12 marca 2024 roku INP (Interaction to Next Paint) zastąpił FID w Core Web Vitals (Google Search Central). Core Web Vitals to dziś trzy wskaźniki: LCP, INP i CLS. TTFB i FCP to wskaźniki pomocnicze, które pomagają znaleźć przyczynę słabego LCP. LCP mierzy czas, po którym wyświetli się największy widoczny element strony (zwykle zdjęcie albo blok tekstu), a nie rozmiar pliku (web.dev).

Jak merchant może sam poprawić szybkość sklepu?

Tomek: Czyli nie powinniśmy patrzeć tylko na jedną liczbę z wynikiem, bo to składowa kilku równie istotnych czynników, które Google bierze pod uwagę przy ocenie sklepu. W porządku. Kamil, teraz pytanie do ciebie: jak merchanci mogą zadbać o performance i go poprawić? Proponuję, żebyśmy podpowiedzieli, co mogą zrobić we własnym zakresie, co jest w ich rękach, a przy czym będą potrzebować developera czy agencji, ale też na co powinni tę agencję uczulić.

Kamil: Jasne. Myślę, że kluczowe jest zadbanie o performance już na etapie designu. Trzeba się zastanowić, czy potrzebujemy tylu animacji i filmów, czy strona powinna być tak długa i mieć tyle elementów, bo to wszystko będzie miało bardzo duży wpływ na to, jak szybko będzie działać i jak będziemy postrzegani od samego startu. To na pewno możemy zrobić po swojej stronie. Jest też wiele rzeczy, o które możemy zadbać już w trakcie korzystania ze sklepu. Bardzo ważne są zdjęcia i filmy: powinny być zawsze zoptymalizowane. To oczywiście zależy też od przygotowania szablonu, od tego, czy użyto rozwiązań, które dopasowują zdjęcia do wielkości elementów, w których się znajdują. Ładowanie zbyt wielu zdjęć na stronach z treścią czy na kartach produktów może pogorszyć wyniki. Do tego dochodzi to, o czym mówiliśmy wcześniej, czyli aplikacje rozszerzające funkcje Shopify. Na tym etapie nieraz warto się zastanowić, czy naprawdę potrzebujemy danego rozwiązania, skoro pogarsza performance. Za to też odpowiadamy sami, bo te rozszerzenia instaluje się bardzo szybko i łatwo, dodają funkcje, ale z każdą instalacją niestety spada performance sklepu.

Ile aplikacji w sklepie jest naprawdę potrzebnych?

Tomek: W tym miejscu podzielę się naszymi doświadczeniami. Niedawno przeanalizowaliśmy dość dużą część sklepów naszych klientów pod kątem tego, na ile realnie korzystają z zainstalowanych aplikacji, a na ile są one pozostałością po próbie jakiejś nowej funkcji i dalej wpływają na performance. Niestety nie zaskoczę was: zdecydowana większość klientów ma od 30% do nawet 50% aplikacji za dużo. Nikt ich w rzeczywistości nie potrzebuje. Jeden z naszych klientów miał zainstalowanych ponad 20 aplikacji, z czego realnie używał mniej więcej siedmiu. To mała dygresja i uwaga dla merchantów: warto wracać do listy zainstalowanych aplikacji. Tak jak powiedziałeś, Kamil, łatwo się je instaluje i bardzo łatwo testuje nowe rozwiązania. Ale samo wyłączenie aplikacji to nie zawsze jej usunięcie.

Kamil: Dokładnie. Dodałbym, że niektórych aplikacji potrzebujemy tylko na konkretną kampanię albo okres w roku. Kiedy aplikacja nie jest już potrzebna, warto ją usunąć ze sklepu. Warto też wspomnieć, że zmienił się sposób, w jaki aplikacje dostarczają zasoby do sklepu. Dawniej aplikacje bardzo często mogły wstrzykiwać kod do plików szablonu, więc po odinstalowaniu nieraz zostawało w nim mnóstwo tak zwanych śmieci. Merchanci, testując różne aplikacje, czasem nie zdawali sobie sprawy, że w ten sposób zaśmiecają sklep. Teraz ta sytuacja się poprawiła, powiedziałbym, że bardzo wyraźnie, bo wszystkie zasoby, które dostarczają aplikacje, są usuwane z szablonu razem z aplikacją. Mamy też tak zwane theme extensions, które pozwalają aplikacjom dodawać elementy bez dopisywania snippetów do szablonu.

Aktualizacja 2026: wymagania programu Built for Shopify mówią, że aplikacja działająca w sklepie musi budować swoje elementy jako theme app extensions, których bloki znikają po odinstalowaniu aplikacji, nie powinna dodawać, usuwać ani edytować plików motywu i nie może obniżać wyniku Lighthouse sklepu o więcej niż 10 punktów (shopify.dev). To wymóg dla aplikacji z odznaką Built for Shopify, więc jeśli kiedyś instalowaliście aplikacje, które dopisywały kod do motywu, po ich usunięciu warto przejrzeć pliki motywu.

Maciek: Jeśli chodzi o rzeczy, które merchant może zrobić sam, na pewno będzie to wyłączenie różnej maści popupów, które też działają na skryptach. Jeden czy dwa popupy nie zaszkodzą. Ale jeśli wszędzie mamy uruchomione automatyzacje, popupy reklamowe, zapisy do newslettera, kupony promocyjne czy popupy, które wyświetlają się, kiedy użytkownik próbuje wyjść ze sklepu, to każdy taki popup, zwłaszcza obsługiwany przez aplikację, to dodatkowe sekundy albo ułamki sekund spowolnienia. Kojarzy mi się też popularna funkcja, która dość mocno spowalnia stronę: tak zwany quick view, czyli podgląd produktu na listingu. Jeszcze nie wchodzimy na kartę produktu, ale po najechaniu kursorem zaczyna się wczytywać podgląd, w którym oprócz kilku zdjęć trzeba pobrać też inne informacje. Bardzo często jest to źle zrealizowane, czy to w gotowym szablonie, czy przez developera, i dość mocno obciąża stronę listingu.

Jakimi zasadami powinien kierować się developer?

Tomek: Skoro dotknęliśmy obszarów, za które odpowiadają developerzy: Kamilu, jakimi najważniejszymi zasadami powinien się kierować developer, który koduje sklep? Jakie wskazówki byś mu dał?

Kamil: Złapię się ostatnich słów Maćka o tym, że coś zostało źle napisane przez developera. To bardzo istotne, bo funkcje takie jak popupy czy quick view da się zrobić tak, żeby nie miały dużego wpływu na performance. Ale nie zawsze tak jest i trzeba to sprawdzić, zanim zaczniemy dodawać kolejne takie elementy w przekonaniu, że rozszerzają funkcje sklepu, zapominając, że rujnują wskaźnik performance. Developer odpowiada za cały szablon, całą architekturę sklepu. Bardzo dużym źródłem wiedzy jest tu dokumentacja techniczna Shopify, na przykład dotycząca Liquid. Jest w niej wiele rozwiązań, które pomagają zbudować szybki sklep, choćby filtry odpowiedzialne za to, jak ładowane są zasoby, na przykład obrazki. Shopify dostarcza wiele rozwiązań, dzięki którym obrazki, nawet wgrane w bardzo dużej rozdzielczości, są na stronie serwowane w odpowiednim rozmiarze i w formacie obsługiwanym przez przeglądarkę. I bez utraty jakości, co jest bardzo ważne, bo można przesadzić z kompresją, a to też źle wpłynie na odbiór serwisu.

Kolejna rzecz to korzystanie z hostingu na CDN Shopify, czyli to, żeby zasoby potrzebne do wyrenderowania strony nie znajdowały się gdzieś poza infrastrukturą Shopify, bo ona jest tak zaprojektowana, żeby zapewnić odpowiedni performance. Ważne jest też unikanie skryptów, które blokują wczytywanie strony na samym starcie. To łączy się z pierwszym punktem, czyli z tym, na co mają wpływ merchanci, bo dodatkowe kody śledzące, różnego rodzaju trackingi i piksele wpływają na działanie strony. Nawet jeśli developer wdroży je prawidłowo, każde takie rozwiązanie pogarsza performance. Jeśli chodzi o samego Liquida, czyli wczytywanie i renderowanie stron, trzeba już na tym poziomie zadbać o odpowiednią budowę szablonu i unikać różnego rodzaju pętli. Przywołam przypadek klienta, który kiedyś się do nas zgłosił. Jego strona kolekcji na Shopify wczytywała się około 30–40 sekund, co bardzo nas zaskoczyło. Po szybkiej analizie okazało się, że liczbę produktów na stronie ustawiono na 1000. Mimo że cache i renderowanie w Shopify są rozwiązane bardzo dobrze, efekt był właśnie taki. Takie przypadki też się zdarzają.

Aktualizacja 2026: CDN Shopify sam dobiera format zdjęcia do przeglądarki: WebP, a od 29 sierpnia 2022 roku także AVIF (changelog.shopify.com). Dokumentacja tagu paginate w Liquid pozwala dziś na 1–250 elementów na stronę (shopify.dev).

Preloading i lazy loading

Maciek: Kamil, mógłbyś opowiedzieć o dwóch technikach, które pomagają optymalizować performance, zwłaszcza ten postrzegany: na czym polega preloading zasobów, a na czym lazy loading?

Kamil: Tak. Lazy loading to mechanizm, który wstrzymuje wczytywanie elementów, dopóki nie pojawią się na ekranie. Dzięki temu na przykład zdjęcia czy skrypty potrzebne niżej na stronie nie są wczytywane na starcie i nie rujnują wskaźnika performance. Najczęściej kojarzy się to ze zdjęciami i filmami, ale w Shopify pojawiły się też narzędzia dla developerów, które pozwalają stosować lazy loading szerzej. Preloading z kolei pozwala wcześniej załadować zasoby, które będą potrzebne nieco później, a istotnie wpłyną na performance i na odbiór strony. Najczęstszy przykład to zdjęcie, które ma się pojawić po najechaniu na konkretny element strony. Jeśli załadujemy je wcześniej, odbiór będzie dużo lepszy i nic nie będzie migać na ekranie.

Aktualizacja 2026: od czerwca 2025 roku Shopify włącza we wszystkich sklepach na Liquid Speculation Rules: przeglądarka pobiera z wyprzedzeniem (prefetch) stronę, w którą klient klika, już w momencie dotknięcia ekranu albo wciśnięcia przycisku myszy. Działa to w przeglądarkach opartych na Chromium (shopify.dev). Według testów A/B Shopify opisanych 29 sierpnia 2025 roku przyspieszyło to wczytywanie średnio o ok. 130 ms na desktopie i ok. 180 ms na mobile (performance.shopify.com).

Co Shopify robi za merchanta w kwestii szybkości?

Maciek: Mówiliśmy o tym, co właściciel sklepu może zrobić sam i co z pomocą developera. Wspomnijmy jeszcze, co robi sama platforma, w tym przypadku oczywiście Shopify. Co platforma może zrobić za nas?

Kamil: W Shopify to przede wszystkim wszystkie kwestie, o których wspominałem wcześniej: optymalizacja zdjęć i przygotowanie ich w formacie, który zapewni najlepszą wydajność. Jest CDN, który dostarcza zasoby strony tak, żeby czas oczekiwania był jak najkrótszy z każdego miejsca na świecie. Jest wspomniany na początku Shopify Storefront Renderer, który przygotowuje stronę zależnie od lokalizacji. Jest też minifikacja skryptów i CSS, żeby zajmowały mniej miejsca i szybciej się wczytywały.

Aktualizacja 2026: od Shopify Editions Summer '25 podstawą nowych darmowych motywów Shopify jest rodzina Horizon, zbudowana na blokach motywu (shopify.com/editions/summer2025). Shopify nie podaje dla Horizon osobnych wyników szybkości. Każdy motyw w Theme Store musi mieć średnio co najmniej 60 punktów Lighthouse na stronie głównej, kolekcji i produktu, na desktopie i na mobile (shopify.dev). Jak przejść na nowszą architekturę motywu, opisujemy w tekście Migrating to Shopify 2.0 in 2026 (po angielsku).

Jak dbać o szybkość na bieżąco?

Maciek: Chciałbym się jeszcze podzielić jedną obserwacją o tym, jak merchanci podchodzą do optymalizacji. Często wygląda to tak, że sami korzystają ze swojego sklepu i w pewnym momencie mówią: „Nie, ta strona jest fatalna, wszystko wolno się wczytuje, musimy to przyspieszyć”. Wtedy na hura organizuje się audyt performance i strona zostaje przyspieszona. Mija parę miesięcy, pół roku, rok i jesteśmy w punkcie wyjścia: strona znowu jest wolna. Dzieje się tak pewnie dlatego, że wraz ze wzrostem złożoności, kiedy dodajemy nowe funkcje, połączenia, integracje i aplikacje, znowu komplikujemy kod, który trzeba wczytać. Kamil, skoro zgodziliśmy się, że to krytyczny czynnik, jak dbać o to, żeby performance był cały czas na dobrym poziomie?

Kamil: Myślę, że trzeba go na bieżąco monitorować. W samym Shopify mamy raporty, które pozwalają śledzić performance. To indeksy oparte na danych, które dostarcza Google. Uwzględniają stronę główną, stronę kolekcji i stronę produktu, a z tego powstaje uśredniony indeks. Bardzo często spotykamy się też z tym, że klienci subskrybują rozwiązania takie jak GTmetrix, które w ramach konkretnego pakietu i ustawień dostarczają na przykład codzienne albo cotygodniowe raporty dla konkretnych stron witryny. To też bardzo dobra praktyka, żeby na bieżąco kontrolować, jak wypada sklep pod względem performance.

Aktualizacja 2026: 31 stycznia 2024 roku Shopify zastąpił dawny Speed Score raportem Web Performance opartym na Core Web Vitals (performance.shopify.com). Podsumowanie jest na stronie Online Store > Themes, a pełne raporty w Analytics > Reports. Pokazują LCP, INP i CLS z danych prawdziwych użytkowników z ostatnich 30 dni, dla 75% wizyt, z podziałem na typ strony, adres URL i urządzenie (help.shopify.com).

Tomek: Dodałbym tylko, że przy bieżącym monitorowaniu wyników nie powinniśmy popadać w subiektywizm. Tak jak wspomniałeś, Maćku, czasem ktoś dochodzi do wniosku, że sklep działa wolno, i dlatego chce poprawić jego performance. Warto, żebyśmy jako merchanci ustalili konkretne KPI, czyli jakie wyniki w poszczególnych obszarach są dla nas satysfakcjonujące. Wtedy dużo łatwiej porównać wyniki z monitoringu z konkretnymi liczbami i wiedzieć, w którym momencie, a zwłaszcza w którym obszarze, trzeba zareagować.

Maciek: Jak najbardziej. Bardzo cenne jest to, co powiedział Kamil: żeby projektować i tworzyć z myślą o performance. Użytkownicy o wiele bardziej docenią szybszy, przejrzysty interfejs niż przeładowany i pełen wodotrysków. Taki będzie efektowny, ale nie efektywny.

Podsumowanie

Tomek: To brzmi jak bardzo dobra puenta tego odcinka, więc krótko podsumuję. Zgadzamy się, że performance ma istotny wpływ na biznes i prowadzenie e-commerce, więc powinniśmy go mierzyć, badać i poprawiać. Możemy to robić sami jako właściciele sklepów, ale też wymagać od agencji i developerów, którzy z nami współpracują, żeby stosowali dobre praktyki. Równie ważne jest to, że to nie jest jednorazowe zadanie. Poprawa performance i optymalizacja sklepu musi być procesem ciągłym, nad którym cały czas pracujemy i który cały czas monitorujemy.

Maciek: Totalna zgoda. To, co mierzymy, zostaje zrobione, a w przypadku performance na pewno zobaczymy bezpośrednie przełożenie na biznes.

Tomek: Jasne. Panowie, bardzo wam dziękuję za dzisiejszy odcinek, a tobie, Kamilu, za to, że znalazłeś dla nas czas i podzieliłeś się wiedzą. Wam dziękujemy za wysłuchanie i obejrzenie odcinka. Jak zwykle zapraszamy do komentowania, zgłaszania propozycji nowych tematów i do usłyszenia w kolejnym odcinku. Dzięki wielkie.

Maciek: Dzięki.

Kamil: Dzięki.