Skrypty zewnętrzne: jak czaty, piksele i mapy spowalniają stronę i co z tym zrobić

Czym są skrypty zewnętrzne i dlaczego spowalniają stronę

Skrypty zewnętrzne to fragmenty kodu, które Państwa strona pobiera z serwerów innych firm, a nie z własnego serwera. Spowalniają stronę, ponieważ przeglądarka musi połączyć się z dodatkowymi domenami, pobrać z nich pliki, a następnie je uruchomić - i robi to na tym samym urządzeniu, na którym gość próbuje czytać ofertę i klikać w menu.

Koszt takiego kodu ma dwie składowe. Pierwsza to waga, czyli ilość danych do pobrania. Opracowanie serwisu web.dev o osadzaniu treści firm trzecich podaje, że osadzenia często zawierają ponad 100 KB kodu JavaScript, a zdarzają się takie, które sięgają 2 MB. Druga składowa to czas pracy procesora. Przeglądarka wykonuje niemal cały kod JavaScript w jednym miejscu, nazywanym wątkiem głównym, i potrafi w nim obsłużyć tylko jedno zadanie naraz. Gdy wątek jest zajęty skryptem czatu, kliknięcie w przycisk musi poczekać.

Zgodnie z materiałem web.dev o długich zadaniach za długie uznaje się zadanie trwające ponad 50 ms. W tym czasie strona nie reaguje na działania gościa, co pogarsza wskaźnik INP opisujący szybkość reakcji na kliknięcie. Szerzej piszemy o tym we wpisie o tym, dlaczego strona reaguje z opóźnieniem na kliknięcie. Kod firm trzecich ma też trzecią cechę: nie mają Państwo nad nim kontroli. Dostawca może go zmienić z dnia na dzień, dlatego wynik pomiaru sprzed kilku miesięcy nie musi być aktualny.

Które dodatki obciążają stronę: czaty, piksele, mapy, analityka i widżety

Stronę obciążają przede wszystkim te dodatki, które ładują się od razu na każdej podstronie, choć nie każdy gość z nich skorzysta. Typowy przykład to okno czatu uruchamiane przy każdym wejściu albo interaktywna mapa w stopce. Czat i mapa służą gościowi dopiero wtedy, gdy zechce ich użyć, natomiast piksele reklamowe i narzędzia analityczne służą firmie: gość ich nie widzi, a mimo to jego telefon wykonuje ich kod.

Tabela pokazuje ogólny kierunek, a nie gotową receptę. To, który dodatek jest w Państwa przypadku najdroższy, wynika wyłącznie z pomiaru.

Jak policzyć koszt kodu firm trzecich w Lighthouse i PageSpeed Insights

Najszybciej koszt skryptów zewnętrznych pokazuje raport wydajności w Lighthouse lub w PageSpeed Insights, w którym zasoby z obcych domen są pogrupowane według dostawców. Wystarczy wpisać adres podstrony, poczekać na wynik i odszukać pozycję dotyczącą firm trzecich w części diagnostycznej raportu.

PageSpeed Insights działa w przeglądarce pod adresem pagespeed.web.dev i nie wymaga logowania. Na ekranie startowym znajduje się jedno pole na adres strony oraz przycisk uruchamiający analizę, opisany słowem Analyze. Lighthouse jest z kolei wbudowany w narzędzia deweloperskie Chrome; sposób jego uruchamiania opisujemy we wpisie o tym, jak uruchomić audyt strony w Chrome.

W starszych wersjach Lighthouse zestawienie nosiło nazwę Reduce the impact of third-party code, czyli ograniczenie wpływu kodu firm trzecich. Według dokumentacji tego audytu narzędzie liczyło, jak długo każdy zewnętrzny skrypt blokował wątek główny podczas ładowania, sumowało te wartości i uznawało audyt za niezaliczony, gdy łączny czas blokowania przekraczał 250 ms. To użyteczny punkt odniesienia także obecnie.

W wersji trzynastej Lighthouse stare audyty wydajności zostały zastąpione tak zwanymi wglądami, wspólnymi z panelem wydajności w Chrome. Jak podaje opis zmian w Lighthouse 13, dawny audyt kodu firm trzecich zastąpił wgląd o nazwie 3rd parties. Z dokumentacji tego wglądu wynika, że grupuje on zasoby według dostawców, zawsze jest oznaczony jako zaliczony i pojawia się w raporcie informacyjnie, gdy narzędzie wykryje żądania do obcych domen. Brak czerwonego ostrzeżenia nie świadczy więc o braku problemu: listę trzeba przeczytać i ocenić samodzielnie.

W tym samym raporcie warto przejrzeć pozycję dotyczącą czasu wykonywania kodu JavaScript, wskazaną w materiale web.dev o rozpoznawaniu wolnych skryptów firm trzecich. Pokazuje ona skrypty, których analiza i uruchomienie trwa najdłużej. Pozostałe części raportu wyjaśniamy we wpisie o tym, jak czytać raport PageSpeed Insights.

Jak zmierzyć koszt pojedynczego skryptu w panelu Sieć

Dokładny koszt jednego dodatku mierzy się w panelu Sieć narzędzi deweloperskich Chrome metodą porównania: najpierw strona jest ładowana w całości, potem z zablokowanym adresem wybranego dostawcy, a różnica między wynikami to cena tego dodatku. Metodę tę opisuje web.dev i nie wymaga ona żadnych zmian na stronie.

Narzędzia deweloperskie otwiera skrót Control+Shift+J w systemie Windows albo Command+Option+J na komputerach Mac. Panel nosi angielską nazwę Network, czyli Sieć. Po odświeżeniu strony pojawia się w nim tabela wszystkich żądań, czyli pobranych plików. Z opisu funkcji panelu Sieć wynika, że kolumna Domain pokazuje domenę, z której pochodzi plik, kolumna Size jego rozmiar w postaci przesłanej przez serwer, a kolumna Initiator to, co wywołało pobranie. Ta ostatnia pozwala ustalić, który skrypt doładował kolejne pliki.

Listę można zawęzić wyłącznie do cudzego kodu. Służy do tego opcja 3rd-party requests dostępna w menu Filters, w części More filters; pokazuje ona żądania, których pochodzenie różni się od pochodzenia strony. Pomocny jest też filtr tekstowy domain: wpisywany w pole wyszukiwania, który zostawia w tabeli pliki z jednej wskazanej domeny. Kliknięcie nagłówka kolumny sortuje tabelę, a pasek na dole panelu podaje liczbę żądań i wagę przesłanych danych.

1. Warunki zbliżone do telefonu

   Przed pomiarem należy włączyć spowolnienie sieci i procesora. Na szybkim łączu i mocnym komputerze wpływ kosztownych skryptów jest słabiej widoczny.

2. Pomiar wyjściowy

   Strona jest ładowana bez żadnych blokad. Notuje się czas ładowania, liczbę żądań i łączną wagę.

3. Blokada wybranego dostawcy

   Kliknięcie prawym przyciskiem myszy w dowolne żądanie otwiera menu z pozycją Block request URL. Zablokowane adresy trafiają do zakładki Request blocking w dolnej części narzędzi.

4. Pomiar po blokadzie

   Strona jest ładowana ponownie i wyniki porównuje się z pomiarem wyjściowym. Jeżeli różnicy nie widać, listę blokad zmienia się tak długo, aż uda się wskazać dodatek odpowiedzialny za spowolnienie.

5. Powtórzenie i mediana

   Każdy wariant mierzy się co najmniej trzy razy i porównuje wartości środkowe, ponieważ zewnętrzne dodatki potrafią pobierać inne zasoby przy każdym ładowaniu.

Załóżmy hipotetyczny sklep z Poznania, który ma na stronie czat, dwa piksele reklamowe i narzędzie nagrywające sesje. Pomiar bez blokad i pomiary z kolejno wyłączanymi dodatkami dają prostą tabelę: nazwa dodatku, waga, różnica w czasie ładowania. Taka tabela zamienia ogólne wrażenie, że strona jest wolna, na konkretną listę kosztów.

Jeśli potrzebna jest odpowiedź na pytanie, ile czasu procesora zajmuje dany dostawca, pomocny jest panel wydajności, w wersji angielskiej Performance. Według opisu jego funkcji pole wyboru Dim 3rd parties wyszarza na nagraniu zdarzenia pochodzące od firm trzecich, a zakładka Summary zawiera zestawienie z podziałem na własny kod strony i podmioty zewnętrzne, z wagą przesłanych danych i czasem pracy w wątku głównym. Dokumentacja zastrzega, że spowolnienie procesora jest względne wobec mocy komputera i nie odwzorowuje dokładnie telefonów. O różnicy między testem a doświadczeniem realnych gości piszemy we wpisie o tym, dlaczego wynik testu różni się od danych od użytkowników.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Usuwanie zbędnych skryptów: od czego zacząć porządki

Porządki zaczyna się od usunięcia tego, co nie jest już nikomu potrzebne, ponieważ to jedyna metoda, która likwiduje koszt w całości. Zalecenie usuwania skryptów, które nie wnoszą wyraźnej wartości, znajduje się w materiale web.dev o ładowaniu kodu JavaScript firm trzecich.

Podstawą jest spis. Dla każdej obcej domeny widocznej w panelu Sieć warto ustalić cztery rzeczy: co to za narzędzie, kto w firmie z niego korzysta, kiedy ostatnio ktoś zaglądał do jego danych oraz co stanie się po jego wyłączeniu. Pozycje, przy których nikt nie potrafi wskazać właściciela, są pierwszymi kandydatami do usunięcia. Z naszej praktyki typowe znaleziska to piksel platformy, na której firma dawno nie prowadzi reklam, narzędzie do testów wersji strony po zakończonym teście albo drugie narzędzie analityczne dublujące pierwsze.

Osobnym źródłem bałaganu bywa menedżer tagów, czyli narzędzie pozwalające dodawać skrypty bez udziału programisty. Web.dev zaleca ograniczanie liczby tagów oraz liczby osób, które mają do niego dostęp, a także regularny przegląd kodu firm trzecich. Dobrze sprawdza się prosta zasada: każdy tag ma w nazwie informację, kto o niego prosił i po co.

Część dodatków da się też zastąpić czymś lżejszym. Web.dev wskazuje, że osadzenie, które wyraźnie pogarsza wydajność, można zamienić na zwykły link otwierający treść w nowej karcie. Ramka z postami z Facebooka lub Instagrama w stopce może zostać zastąpiona ikoną z odnośnikiem do profilu.

Opóźnianie skryptów: atrybuty async i defer, leniwe ładowanie i start po interakcji

Skrypt, którego nie można usunąć, należy przesunąć w czasie tak, aby nie konkurował z treścią strony o łącze i procesor. Służą do tego trzy poziomy opóźnienia: atrybuty async i defer w kodzie strony, leniwe ładowanie ramek położonych niżej oraz uruchamianie dodatku dopiero wtedy, gdy gość zacznie korzystać ze strony.

Atrybuty async i defer

Zwykły znacznik skryptu zatrzymuje budowanie strony do czasu pobrania i wykonania pliku. Atrybut async sprawia, że plik pobiera się równolegle z analizą kodu strony, a przerwa następuje tylko na czas jego wykonania. Atrybut defer również pozwala pobierać plik w tle, ale uruchamia go dopiero po zakończeniu analizy dokumentu. Web.dev zaleca, aby kod firm trzecich zawsze miał jeden z tych atrybutów, chyba że jest niezbędny do wyświetlenia strony: async dla skryptów potrzebnych wcześniej, na przykład analityki, a defer dla mniej pilnych. To samo źródło radzi umieszczać cudze skrypty po kluczowych zasobach własnych, tak aby główna treść miała pierwszeństwo.

<link rel="preconnect" href="https://cdn.example.com">
<script src="/js/strona.js" defer></script>
<script src="https://cdn.example.com/widzet.js" defer></script>

Widoczny w przykładzie znacznik z wartością preconnect to wskazówka dla przeglądarki, aby zawczasu nawiązała połączenie z domeną dostawcy: odszukała jej adres, połączyła się i uzgodniła szyfrowanie. Słabszą odmianą jest dns-prefetch, który wykonuje tylko pierwszą z tych czynności. Obie wskazówki mają sens dla dodatków naprawdę potrzebnych na początku.

Leniwe ładowanie ramek z mapą i filmem

Mapa, film i inne osadzenia są zwykle wstawiane jako ramka, czyli znacznik iframe. Atrybut loading z wartością lazy powoduje, że przeglądarka pobiera taką ramkę dopiero wtedy, gdy gość zbliża się do niej podczas przewijania. Według web.dev atrybut ten obsługują wszystkie współczesne przeglądarki, a przy osadzonym filmie z YouTube pozwala zaoszczędzić około 500 KB podczas początkowego ładowania. Ta sama technika działa przy mapie osadzonej z Map Google.

<iframe src="https://www.google.com/maps/embed?..."
  width="600" height="450" loading="lazy"
  title="Mapa dojazdu do biura"></iframe>

Podana szerokość i wysokość pozwalają przeglądarce zarezerwować miejsce, zanim ramka się pojawi, dzięki czemu treść pod nią nie przeskakuje. Więcej o tym zjawisku piszemy we wpisie o tym, skąd biorą się przeskoki układu strony, a o samym mechanizmie we wpisie o leniwym ładowaniu obrazów i ramek. Web.dev zastrzega, że techniki opóźniania należy stosować do treści poza pierwszym ekranem lub drugorzędnych, tak aby najważniejsza treść pozostała dostępna od razu, także dla wyszukiwarek.

Uruchamianie po interakcji

Najdalej idącym opóźnieniem jest start dodatku dopiero po pierwszym działaniu gościa, takim jak przewinięcie strony, ruch kursora lub dotknięcie ekranu, albo po upływie określonego czasu bezczynności. Rozwiązanie to dobrze pasuje do czatu i widżetów, które nie są potrzebne w pierwszej sekundzie. Z naszej praktyki wynika, że w WordPressie taką funkcję mają wtyczki do optymalizacji, a w innych systemach wymaga ona kilku linii kodu od programisty.

Ładowanie po zgodzie: piksele i analityka uruchamiane dopiero po decyzji gościa

Ładowanie po zgodzie polega na tym, że skrypty reklamowe i analityczne nie uruchamiają się przy wejściu na stronę, lecz dopiero po tym, jak gość zaakceptuje odpowiednią kategorię w banerze zgody. Ma to dwa skutki naraz: porządkuje sprawę prywatności i zdejmuje z pierwszego ładowania kod, który gościowi do niczego nie służy.

W Menedżerze tagów Google służą do tego ustawienia zgody przypisane do każdego tagu. Według pomocy Menedżera tagów po otwarciu tagu należy przejść do części Ustawienia zaawansowane, a w niej do pozycji Ustawienia dotyczące wyrażania zgody. Sekcja Wbudowane mechanizmy sprawdzania zgody informuje, na jakie rodzaje zgody tag reaguje samodzielnie. Sekcja Mechanizmy sprawdzania dodatkowej zgody pozwala wskazać opcję Wymagaj dodatkowej zgody na uruchomienie tagu, a następnie dodać konkretne rodzaje zgody, takie jak ad_storage dla reklam czy analytics_storage dla analityki.

Przy większej liczbie tagów wygodniejszy jest widok zbiorczy. Włącza się go w części Administracja, w Ustawieniach kontenerów, w sekcji Ustawienia dodatkowe, opcją Przegląd ustawień uzyskiwania zgody. Po jej włączeniu w zakładce Tagi pojawia się ikona otwierająca listę tagów, na której można zmienić ustawienia kilku z nich jednocześnie. Zmiany działają dopiero po opublikowaniu kontenera.

Ta metoda ma granicę. Gość, który zgodę wyrazi, pobierze wszystkie skrypty tak samo jak wcześniej, tyle że chwilę później. Ładowanie po zgodzie nie zastępuje więc porządków: pięć pikseli po zgodzie to wciąż pięć pikseli. Sam baner również bywa skryptem zewnętrznym i także powinien trafić na listę mierzonych dodatków.

To, które narzędzia wymagają zgody i jak powinien wyglądać sam baner, jest kwestią prawną, a nie techniczną. Ogólne zasady opisujemy we wpisie o tym, jak zaprojektować baner zgody na pliki cookie; w konkretnej sprawie rozstrzygająca powinna być opinia prawnika.

Fasady: lekka atrapa zamiast czatu, filmu i mapy

Fasada to nieruchomy element, który wygląda jak osadzony dodatek, ale nie zawiera jego kodu, a prawdziwy dodatek pobiera się dopiero po kliknięciu. Gość widzi miniaturę filmu z symbolem odtwarzania albo ikonę czatu w rogu ekranu, a koszt ponosi wyłącznie ten, kto faktycznie chce z dodatku skorzystać.

Wzorzec opisany w dokumentacji Lighthouse o fasadach składa się z trzech momentów. Przy ładowaniu strony wyświetlana jest sama fasada. Po najechaniu kursorem fasada nawiązuje wstępne połączenie z serwerami dostawcy, aby skrócić późniejsze oczekiwanie. Po kliknięciu fasada zostaje zastąpiona prawdziwym dodatkiem. Dokumentacja wymienia jako typowe zastosowania osadzone odtwarzacze wideo, okna czatu na żywo oraz przyciski mediów społecznościowych.

Dla filmów z YouTube istnieją gotowe, otwarte rozwiązania tego typu; web.dev podaje, że jedno z nich jest według własnej dokumentacji około 224 razy szybsze od zwykłego osadzenia. Dla czatów stosuje się lekki przycisk wyglądający jak ikona czatu, który pełny widżet ładuje po najechaniu, kliknięciu albo po dłuższej bezczynności strony. Dla mapy najprostszą fasadą jest statyczny obraz: zrzut mapy zapisany w lekkim formacie i opakowany w link prowadzący do pełnej mapy. Hipotetyczna kancelaria z Krakowa, która pokazuje mapę dojazdu w stopce każdej podstrony, może w ten sposób zastąpić interaktywną ramkę jednym obrazem, nie odbierając klientowi możliwości wyznaczenia trasy.

<a href="https://www.google.com/maps/place/..." target="_blank" rel="noopener">
  <img src="/img/mapa-dojazdu.webp" width="600" height="300"
    loading="lazy" alt="Mapa dojazdu do biura przy ulicy Przykładowej">
</a>

Fasady mają ograniczenia i należy o nich powiedzieć przed wdrożeniem. Dokumentacja zaznacza, że nie oferują pełnej funkcjonalności prawdziwych osadzeń: przy czacie licznik nowych wiadomości nie jest widoczny od razu, a przy filmach automatyczne odtwarzanie może nie działać spójnie. Warto też wiedzieć, że audyt podpowiadający fasady został w trzynastej wersji Lighthouse usunięty bez następcy; autorzy narzędzia wyjaśnili, że wolą, aby dostawcy poprawiali własne rozwiązania. Sama technika pozostaje skuteczna, lecz raport nie podpowie jej już samodzielnie.

Jak rozmawiać o skryptach z działem marketingu

Rozmowa z marketingiem udaje się wtedy, gdy dotyczy kosztów i korzyści konkretnych narzędzi, a nie ogólnego hasła, że skrypty szkodzą stronie. Piksele i analityka nie są kaprysem: bez nich trudno ocenić kampanie i ustalić, skąd przychodzą klienci. Celem nie jest więc usunięcie wszystkiego, lecz ustalenie, które narzędzia zarabiają na swój koszt.

Dobrym punktem wyjścia jest tabela z pomiaru w panelu Sieć: nazwa dodatku, waga, wpływ na czas ładowania i osoba, która z niego korzysta. Przy takim zestawieniu pytanie nie brzmi już, czy wolno usunąć piksel, tylko czy dane z tego narzędzia były użyte do jakiejkolwiek decyzji w ostatnim kwartale. Warto przy tym przypomnieć wspólny interes: na tę samą stronę trafiają osoby z płatnych reklam, więc jej szybkość dotyczy także kampanii. O tym, jak strona docelowa wiąże się z oceną reklam, piszemy we wpisie o tym, z czego składa się Wynik Jakości w Google Ads.

• Każdy skrypt ma wskazanego właściciela w firmie i opisany cel.
• Nowy tag jest dodawany razem z terminem przeglądu, po którym zostanie oceniony lub usunięty.
• Skrypty kampanii zakończonych są wyłączane razem z kampanią.
• Jedno narzędzie do jednego zadania: bez dwóch systemów analitycznych i dwóch czatów.
• Dodatki są ładowane tylko na tych podstronach, na których są potrzebne.
• Przed dodaniem nowego narzędzia i po jego dodaniu wykonywany jest pomiar szybkości.
• Dostęp do menedżera tagów ma ograniczone grono osób.
• Przegląd wszystkich skryptów odbywa się w stałych odstępach, na przykład raz na kwartał.

Typowe pomyłki przy ograniczaniu skryptów

Najczęstszą pomyłką jest ocenianie strony wyłącznie po wyniku punktowym testu. Skrypty ukryte za banerem zgody lub opóźnione do interakcji mogą zniknąć z raportu laboratoryjnego, lecz gość, który zacznie korzystać ze strony, nadal je pobiera. Dlatego obok testu należy śledzić dane od realnych użytkowników, dostępne między innymi w raporcie Podstawowe wskaźniki internetowe w Search Console.

Druga pomyłka to opóźnianie wszystkiego jedną regułą. Skrypt, od którego zależy działanie menu, koszyka lub formularza, po opóźnieniu potrafi zepsuć stronę. Trzecia to pomiar jednorazowy: pojedyncze ładowanie bywa przypadkowe, dlatego źródła zalecają co najmniej trzy próby. Czwarta to brak kontroli po wdrożeniu - po każdej zmianie należy sprawdzić, czy formularze nadal wysyłają zgłoszenia, a konwersje są poprawnie zliczane.

Kiedy potrzebna jest pomoc specjalisty

Spis skryptów i usunięcie oczywistych pozostałości właściciel strony zwykle wykona samodzielnie. Pomoc przydaje się wtedy, gdy trzeba zbudować fasadę, przenieść tagi pod kontrolę zgody bez utraty pomiaru konwersji, ograniczyć dodatki do wybranych podstron albo ustalić, który z kilku skryptów odpowiada za słaby wynik INP. Takie prace prowadzimy w ramach usługi SEO techniczne, a przegląd kodu firm trzecich jest jednym z elementów, które obejmuje audyt SEO. Szerszy obraz pracy nad szybkością przedstawiamy we wpisie o tym, jak poprawić LCP, INP i CLS na stronie firmy.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl