Zewnętrzne skrypty a SEO sklepu: analityka, chat i reklamy

Sklep internetowy rzadko działa wyłącznie na własnym kodzie. Do strony dochodzą skrypty analityczne, system reklamowy, tag manager, czat, narzędzia do nagrywania sesji, mapy, recenzje, rekomendacje produktów, formularze, zabezpieczenia i różnego rodzaju widgety. Każdy z nich może być uzasadniony biznesowo. Problem zaczyna się wtedy, gdy dodatki dokładane przez marketing przestają być kontrolowane pod kątem wydajności.

Fraza zewnętrzne skrypty sklep SEO opisuje więc nie tylko temat szybkości ładowania. Chodzi również o sposób, w jaki przeglądarka wykonuje JavaScript, obsługuje kliknięcia i przelicza stronę podczas interakcji. Sklep może mieć dobrze zoptymalizowane obrazy, szybki serwer i poprawny kod własny, a mimo tego działać wolniej przez kilka usług ładowanych z obcych domen.

Zewnętrzne skrypty sklep SEO: od czego zacząć analizę

Nie zaczynaj od wyłączania wszystkiego. Najpierw ustal, co faktycznie jest ładowane i po co znajduje się na stronie.

Właściciel sklepu powinien przygotować prostą listę wszystkich usług zewnętrznych. Przy każdym wpisie zapisz nazwę dostawcy, funkcję, miejsce wdrożenia oraz informację, czy skrypt jest potrzebny na każdej stronie. To ostatnie często daje największe pole do optymalizacji.

Analityka może być potrzebna na całym sklepie, ale widget opinii może być potrzebny wyłącznie na kartach produktów. Czat może mieć sens na stronie kontaktowej i podczas zakupów, ale jego stałe uruchamianie na każdej podstronie wymaga już osobnego uzasadnienia. Mapa może być konieczna na stronie kontaktowej, lecz nie ma powodu ładować jej na stronie kategorii.

Podobnie trzeba spojrzeć na tagi marketingowe. W tag managerze łatwo zostawić kod po zakończonej kampanii, stare narzędzie testowe albo drugi system analityczny, który zbiera dane niemal identyczne jak pierwsze rozwiązanie. Sam fakt, że tag znajduje się w kontenerze, nie oznacza, że nadal powinien być uruchamiany.

Jeżeli problemem jest JavaScript ładowany jeszcze przed wyświetleniem głównej treści, przydatne będzie również sprawdzenie jak znaleźć ciężkie skrypty blokujące renderowanie, ponieważ zewnętrzny kod może być tylko częścią większego problemu z wykonywaniem JavaScriptu.

Co dokładnie obciąża przeglądarkę

Wpływ zewnętrznego skryptu nie sprowadza się do jego rozmiaru. Przeglądarka musi nawiązać połączenie z kolejnym serwerem, pobrać zasoby, przetworzyć kod, wykonać JavaScript i obsłużyć czynności, które skrypt uruchamia później.

Przy wielu usługach dochodzi także do kolejnych żądań. Jeden fragment kodu może pobrać następne pliki JavaScript, obrazy, arkusze stylów, dane konfiguracyjne lub zasoby z kolejnych domen. W efekcie prosty wpis w kodzie strony może uruchomić znacznie większy łańcuch operacji.

Znaczenie ma również główny wątek przeglądarki. To właśnie on zajmuje się między innymi przetwarzaniem JavaScriptu, obsługą DOM i reakcją na wiele działań użytkownika. Jeżeli zostanie zajęty długimi zadaniami, kliknięcie w przycisk, zmianę wariantu produktu czy otwarcie menu może obsłużyć z opóźnieniem.

Dlatego dwa skrypty o podobnym rozmiarze mogą mieć zupełnie inny wpływ na sklep. Jeden pobierze dane i zakończy pracę, drugi będzie intensywnie wykonywał kod, dodawał elementy do strony i reagował na kolejne zdarzenia.

To także powód, dla którego samo sprawdzenie liczby kilobajtów w raporcie nie wystarcza. Trzeba zobaczyć, ile czasu dany dostawca zajmuje główny wątek oraz jakie zadania wykonuje podczas ładowania i interakcji.

Jak sprawdzić third party scripts w Chrome DevTools

Do pierwszego audytu nie potrzebujesz płatnego narzędzia. W Chrome otwórz DevTools, przejdź do zakładki Network i odśwież stronę. Następnie sprawdź domeny, z których pobierane są zasoby.

Szukaj przede wszystkim adresów innych niż domena sklepu. Zwróć uwagę na liczbę żądań, wielkość pobieranych danych i czas ich ładowania. Następnie przejdź do zakładki Performance i wykonaj nagranie podczas ładowania strony oraz podczas kilku typowych interakcji.

Dobrym sposobem jest analiza kilku różnych typów podstron. Sprawdź stronę główną, kategorię, kartę produktu, koszyk i checkout. Nie zakładaj, że wszystkie strony mają ten sam zestaw skryptów. W praktyce często okazuje się, że konkretny widget pojawia się tylko w jednym miejscu, ale jest ładowany globalnie.

W Performance możesz grupować pracę według dostawców third party i zobaczyć, które usługi wykonują najwięcej pracy. Interesuje Cię nie tylko moment pobrania pliku, ale również późniejsze zadania wykonywane przez przeglądarkę.

Drugi etap to test z blokowaniem wybranego zasobu. Jeżeli podejrzewasz, że konkretny skrypt mocno obciąża stronę, zablokuj jego domenę w DevTools i wykonaj ponowny pomiar. Porównaj zachowanie strony przed i po blokadzie. Nie traktuj tego jako gotowego testu produkcyjnego, lecz jako sposób na ustalenie zależności.

Jeżeli po zablokowaniu usługi poprawia się praca głównego wątku, masz mocny argument, aby sprawdzić możliwość późniejszego ładowania, ograniczenia zakresu działania albo całkowitego usunięcia skryptu.

Jak zewnętrzne skrypty wpływają na INP

Pytanie jak zewnętrzne skrypty wpływają na INP pojawia się szczególnie wtedy, gdy sklep dobrze przechodzi testy ładowania, ale podczas korzystania z niego sprawia wrażenie ciężkiego.

INP mierzy responsywność strony na interakcje użytkownika. Jeżeli po kliknięciu w filtr, przycisk dodania do koszyka, menu lub selektor wariantu przeglądarka przez dłuższy czas wykonuje inne zadania, reakcja może zostać opóźniona.

Zewnętrzny skrypt może być przyczyną takiej sytuacji nawet wtedy, gdy nie odpowiada bezpośrednio za element, który użytkownik kliknął. Kod reklamowy, narzędzie analityczne albo widget może w odpowiednim momencie wykonywać JavaScript na tym samym głównym wątku, którego potrzebuje sklep do obsługi interakcji.

W praktyce analizuj więc nie tylko ładowanie strony. Otwórz kartę produktu, zmień wariant, użyj filtrów, otwórz menu, dodaj produkt do koszyka i przejdź do kolejnego kroku zakupowego. Obserwuj, czy podczas tych czynności pojawiają się długie zadania.

Jeżeli INP jest problemem, pomocne będzie zestawienie go z analizą opóźnień INP w sklepie internetowym. Dzięki temu łatwiej rozdzielisz problemy wynikające z kodu sklepu od pracy wykonywanej przez usługi zewnętrzne.

Nie przypisuj jednak automatycznie złego INP konkretnemu dostawcy. Najpierw znajdź konkretną aktywność w Performance i sprawdź, kiedy występuje. Ten sam skrypt może być niewielkim obciążeniem podczas pierwszego ładowania, ale generować dużo pracy po kliknięciu określonego elementu.

Czy Google Analytics spowalnia sklep

Pytanie czy Google Analytics spowalnia sklep nie ma jednej odpowiedzi. Sam fakt korzystania z analityki nie oznacza, że sklep będzie wolny. Znaczenie ma sposób wdrożenia, liczba dodatkowych tagów, sposób ich uruchamiania oraz to, jakie inne usługi są ładowane razem z analityką.

Najczęstszy problem pojawia się wtedy, gdy Google Analytics jest tylko jednym z wielu elementów uruchamianych przez tag manager. Kontener może wywoływać kolejne skrypty reklamowe, remarketingowe, testy, narzędzia analizy zachowania i inne integracje. Wtedy właściciel sklepu widzi jeden kod w źródle strony, ale przeglądarka wykonuje znacznie więcej pracy.

Sprawdź więc nie tylko samą usługę analityczną. Otwórz kontener tag managera i przeanalizuj wszystkie tagi, reguły oraz wywołania. Usuń rozwiązania, których już nie używasz. Zweryfikuj także, czy ten sam cel nie jest obsługiwany przez kilka systemów.

Jeżeli potrzebujesz danych analitycznych od początku wizyty, ustal z osobą odpowiedzialną za pomiar, które zdarzenia muszą być rejestrowane natychmiast, a które mogą zostać wysłane później. Nie każda informacja wymaga uruchamiania ciężkiego kodu w krytycznej części ładowania strony.

Które skrypty zostawić, a które opóźnić

Decyzję podejmuj na podstawie funkcji, a nie nazwy narzędzia. Podziel skrypty na kilka grup.

Pierwsza grupa to elementy wymagane do działania sklepu. Jeżeli bez danego kodu nie można obsłużyć podstawowej funkcji zakupowej, nie traktuj go jak zwykłego dodatku marketingowego. W tym przypadku szukasz sposobu na ograniczenie kosztu wykonania, a nie prostego wyłączenia.

Druga grupa obejmuje analitykę i pomiar. Tu sprawdź, jakie dane są naprawdę potrzebne i kiedy muszą zostać zebrane. Jeżeli skrypt nie musi działać przed wyświetleniem głównej treści, rozważ późniejsze uruchomienie.

Trzecia grupa to reklamy i remarketing. Tutaj szczególnie łatwo zebrać wiele usług pełniących podobne funkcje. Przeanalizuj, które tagi są aktywne, na jakich stronach się uruchamiają i czy nadal są wykorzystywane w kampaniach.

Czwarta grupa to widgety i dodatki. Czat, mapa, media społecznościowe, opinie, rekomendacje, filmy i podobne elementy powinny być ładowane wtedy, gdy rzeczywiście są potrzebne. Element znajdujący się nisko na stronie nie musi blokować pobierania zasobów potrzebnych do pokazania pierwszego ekranu.

Piąta grupa to narzędzia, których nikt już nie używa. Te skrypty należy usuwać, a nie optymalizować. Jeżeli kampania się skończyła, test został zamknięty, a widget zastąpiono innym rozwiązaniem, pozostawiony kod nie ma uzasadnienia.

Tabela: rodzaje skryptów third party i ich potencjalne obciążenie

Rodzaj skryptu	Przykładowe zastosowanie	Potencjalne obciążenie	Co sprawdzić
Analityka	pomiar wizyt i zdarzeń	niskie do wysokiego	liczba tagów, zdarzenia, czas wykonania
Tag manager	zarządzanie kodami marketingowymi	średnie do wysokiego	liczba tagów, reguły i wywołania
Reklamy	remarketing, sieci reklamowe	średnie do wysokiego	liczba żądań, JavaScript, iframe
Czat	obsługa rozmów z klientami	średnie	moment uruchomienia, praca po interakcji
Mapy	lokalizacja sklepu lub punktu	średnie do wysokiego	ładowanie dopiero po potrzebie użytkownika
Widget opinii	opinie i oceny produktów	średnie	liczba zasobów i elementów DOM
Nagrania sesji	analiza zachowania użytkowników	średnie do wysokiego	wpływ na główny wątek i zakres nagrywania
Wideo i media społecznościowe	osadzone materiały	średnie do wysokiego	lazy loading i moment inicjalizacji
Testy A/B	eksperymenty na stronie	średnie do wysokiego	wpływ na renderowanie i wykonanie JS

Tabela pokazuje potencjalne obciążenie, a nie gwarantowany koszt konkretnej usługi. Ten sam typ skryptu może być wdrożony lekko albo bardzo agresywnie. Ostateczną decyzję podejmuj na podstawie pomiaru konkretnego sklepu.

Chat, reklamy i mapy: kiedy ładować je później

Czat jest dobrym przykładem funkcji, która nie zawsze musi być gotowa w momencie pojawienia się strony. Jeżeli użytkownik może przejść przez stronę produktu bez otwierania okna rozmowy, rozważ inicjalizację czatu po pierwszej interakcji, po chwili bezczynności albo dopiero po wejściu w obszar, w którym czat jest potrzebny.

Trzeba jednak sprawdzić wymagania konkretnego dostawcy. Nie każdy system pozwala bezproblemowo rozdzielić pobranie biblioteki od jej uruchomienia.

Podobnie postępuj z mapą. Jeżeli mapa znajduje się na dole strony kontaktowej, nie ma technicznego powodu, aby jej ciężkie zasoby były priorytetem przed treścią znajdującą się na początku dokumentu. Można rozważyć lazy loading albo wyświetlenie lekkiego placeholdera i dopiero późniejsze uruchomienie mapy.

W przypadku reklam sytuacja jest bardziej złożona, ponieważ skrypt może mieć znaczenie dla przychodów. Nie oznacza to jednak, że każda sieć reklamowa musi działać natychmiast. Przeanalizuj, gdzie reklama faktycznie jest potrzebna, jakie tagi są wymagane oraz czy nie uruchamiasz kilku systemów do tego samego celu.

Jeżeli masz wiele tagów marketingowych, zacznij od listy właścicieli tych integracji. Każdy tag powinien mieć określony cel, miejsce użycia i osobę, która potwierdzi, że nadal jest potrzebny.

Jak ograniczyć third party scripts bez utraty danych

Najprostsza metoda to usunięcie kodu, który nie ma już zastosowania. Kolejna to ograniczenie zakresu jego działania. Dopiero później przechodź do technicznych zmian sposobu ładowania.

Jeżeli skrypt nie jest wymagany do wyświetlenia pierwszej części strony, sprawdź możliwość użycia async, defer albo opóźnienia inicjalizacji. Wybór zależy od tego, czy kolejność wykonania ma znaczenie i czy inne elementy sklepu korzystają z danego kodu.

Nie zakładaj, że samo dodanie async rozwiąże problem. Asynchroniczne pobieranie nie oznacza braku kosztu wykonania. Jeżeli przeglądarka musi przetworzyć duży pakiet JavaScript, główny wątek nadal będzie zajęty.

W przypadku elementów poniżej pierwszego ekranu sprawdź lazy loading. Dotyczy to przede wszystkim osadzonych filmów, map i części widgetów. Czasami lepszym rozwiązaniem jest pokazanie statycznego elementu, który dopiero po interakcji uruchomi właściwą usługę.

Ogranicz również liczbę domen. Każde dodatkowe źródło oznacza konieczność zestawienia połączenia i pobrania zasobów. Jeżeli kilka narzędzi korzysta z podobnych funkcji, porównaj je zamiast utrzymywać wszystkie równocześnie.

Przydatne jest również ograniczenie dostępu do tag managera. Im więcej osób może dodawać kod bez kontroli, tym większa szansa, że kontener będzie stopniowo obrastał niepotrzebnymi integracjami.

Jeżeli chcesz podejść do tego systematycznie, jak czytać wyniki INP, LCP i CLS pomoże połączyć obserwacje z narzędzi wydajności z konkretnymi metrykami dotyczącymi doświadczenia użytkownika.

Jak ustalić, czy skrypt naprawdę powoduje problem

Nie wyciągaj wniosków z jednego wyniku PageSpeed Insights. Zewnętrzne usługi mogą zachowywać się różnie w zależności od sieci, urządzenia, odpowiedzi serwera i aktualnej konfiguracji dostawcy.

Zrób kilka pomiarów tej samej strony. Następnie wykonaj test z wybranym skryptem i bez niego. Jeżeli różnica jest powtarzalna, przejdź do kolejnego kroku i sprawdź, czy możesz ograniczyć sposób ładowania.

Dobrym rozwiązaniem jest prowadzenie prostej tabeli audytowej. Przy każdym skrypcie zapisz nazwę, cel, właściciela, podstrony, na których działa, moment uruchomienia, wpływ na główny wątek oraz decyzję: zostawić, opóźnić, ograniczyć albo usunąć.

Po zmianie wykonaj ponowny test. Sprawdź nie tylko wynik laboratoryjny, ale też działanie sklepu. Jeżeli opóźniłeś czat, zobacz, czy nadal otwiera się prawidłowo. Jeżeli ograniczyłeś tag reklamowy, sprawdź, czy kampania nadal otrzymuje wymagane dane. Jeżeli zmieniłeś sposób działania analityki, zweryfikuj odbiór najważniejszych zdarzeń.

Takie podejście chroni przed pozorną optymalizacją. Nie ma sensu poprawiać wyniku technicznego kosztem funkcji, która jest rzeczywiście potrzebna do obsługi klienta albo pomiaru sprzedaży.

Audyt skryptów jako stały element utrzymania sklepu

Nie wystarczy zrobić taki przegląd raz. Sklep się zmienia. Dochodzą nowe kampanie, integracje, aplikacje, moduły i narzędzia analityczne. W pewnym momencie może się okazać, że kod dodany kilka miesięcy wcześniej nadal działa, mimo że jego funkcja została dawno zakończona.

Dlatego przy większych zmianach sklepu dopisz audyt third party do listy technicznej. Po instalacji nowego modułu sprawdź Network i Performance. Po uruchomieniu nowego systemu reklamowego porównaj liczbę żądań i pracę głównego wątku. Po dodaniu czatu albo widgetu opinii zobacz, czy kod ładuje się na wszystkich podstronach.

Właściciel sklepu nie musi znać każdego szczegółu JavaScriptu. Powinien jednak wiedzieć, jakie usługi są uruchamiane, dlaczego są potrzebne i na których stronach działają. Jeżeli nie potrafisz odpowiedzieć na te trzy pytania przy konkretnym tagu, jest to dobry kandydat do dalszej weryfikacji.

W przypadku większego sklepu można też ustalić wewnętrzny limit liczby usług zewnętrznych i wymagać uzasadnienia dla każdej nowej integracji. Nie chodzi o sztywną liczbę, lecz o to, żeby każda kolejna usługa miała właściciela i określony cel.

Co zrobić podczas kolejnego audytu szybkości

Zacznij od strony głównej i karty produktu, ponieważ właśnie tam zwykle spotyka się wiele elementów marketingowych. Następnie przejdź przez kategorię, koszyk i checkout. Zapisz wszystkie zewnętrzne domeny i przypisz im funkcje.

Potem sprawdź Network oraz Performance w Chrome DevTools. Zobacz, które usługi pobierają dużo danych, generują wiele żądań albo zajmują główny wątek. Oddziel elementy wymagane od tych, które są dodatkami.

Następnie blokuj podejrzane domeny pojedynczo i porównuj zachowanie strony. Tam, gdzie to możliwe, przetestuj opóźnienie inicjalizacji, lazy loading albo ograniczenie skryptu do konkretnych podstron. Po każdej zmianie sprawdź funkcję biznesową, którą dany kod obsługuje.

Jeżeli analiza pokazuje, że sklep ma dużo niekontrolowanego kodu zewnętrznego, audyt szybkości sklepu internetowego pozwala uporządkować ten proces wokół rzeczywistych problemów technicznych zamiast przypadkowego wyłączania kolejnych integracji.

Na końcu wróć do pomiarów INP, LCP i pozostałych elementów wydajności. Porównuj wyniki po zmianach, ale nie traktuj jednej liczby jako celu samego w sobie. Zadaniem optymalizacji jest ustalenie, które zasoby są potrzebne, kiedy powinny zostać uruchomione i jak ograniczyć ich koszt dla przeglądarki.

Zewnętrzne skrypty nie są z definicji problemem SEO. Problemem staje się brak kontroli nad tym, co robią, kiedy są uruchamiane i ile pracy przekazują przeglądarce. Analityka, reklamy, czat czy mapa mogą pozostać częścią sklepu, jeżeli ich wykorzystanie jest uzasadnione i odpowiednio zaplanowane. Audyt powinien więc prowadzić nie do usunięcia wszystkiego, ale do świadomego podziału na kod potrzebny teraz, kod potrzebny później oraz kod, którego sklep już nie potrzebuje.