Skąd bierze się szkoda

Zewnętrzny widget prawie nigdy nie jest jednym plikiem. Wstawiasz na stronę kilka linijek, które dociągają skrypt startowy, ten łączy się z domeną dostawcy, pobiera konfigurację, potem właściwą paczkę kodu, style, ikony, czcionkę, często jeszcze zdjęcia konsultantów i historię rozmowy z pamięci przeglądarki. Z jednego odwołania robi się kilkanaście.

Każdy z tych elementów kosztuje w trzech miejscach naraz. Zajmuje pasmo, którego w tym samym momencie potrzebują obrazek nagłówkowy i arkusz stylów. Zajmuje połączenia z nowymi domenami, co przy słabym łączu mobilnym oznacza dodatkowe rundy negocjacji. I wreszcie zajmuje główny wątek przeglądarki, kiedy przeglądarka musi ten kod przetworzyć i wykonać.

Dochodzi rzecz, o której łatwo zapomnieć: te skrypty nie kończą pracy po wczytaniu. Czat utrzymuje otwarte połączenie, sprawdza dostępność konsultanta, odlicza czas do zaproszenia do rozmowy. To znaczy, że jego wpływ nie ogranicza się do pierwszych sekund wizyty, ale rozciąga się na cały czas przebywania na stronie.

Który wskaźnik cierpi i dlaczego

• Największy element widoczny na ekranie — cierpi wtedy, gdy skrypty startują przed tym, co ma być pokazane, i odbierają pasmo obrazkowi nagłówkowemu. Dzieje się to zwykle przez nieuważne wstawienie kodu na samą górę dokumentu albo przez menedżer tagów odpalany za wcześnie.

• Przesunięcia układu strony — to typowa wina karuzeli opinii wstawionej w treść. Miejsce na nią nie jest zarezerwowane, więc gdy dane w końcu dojdą, blok rozpycha się i przesuwa wszystko poniżej. Dymek czatu zaszkodzi tu tylko wtedy, gdy jest umieszczony w normalnym przepływie dokumentu, a nie na warstwie nad nim.

• Czas reakcji na dotknięcie — najczęściej i najmocniej. Przetwarzanie kilkuset kilobajtów kodu na średniej klasy telefonie to jedno długie zadanie, w trakcie którego strona po prostu nie odpowiada. Jeśli użytkownik trafi w tym momencie w menu, dostaniesz w danych z pola wynik, którego w żadnym własnym teście nie zobaczysz.

Ostatni punkt jest kluczem do zrozumienia, dlaczego dyskusja o wadze pliku prowadzi na manowce. Sto kilobajtów obrazka i sto kilobajtów JavaScriptu to dla przeglądarki dwa zupełnie różne obciążenia. Obrazek trzeba pobrać i wyświetlić. Kod trzeba pobrać, przetworzyć i wykonać, na jednym wątku, tym samym, na którym obsługiwane są kliknięcia.

Jak policzyć koszt konkretnego narzędzia

Nie zgaduję i nie polegam na zapewnieniach dostawcy. Robię prosty pomiar różnicowy.

Najpierw zapisuję stan wyjściowy z danych o realnym ruchu — dla całej domeny i dla najważniejszych szablonów, osobno dla telefonów i komputerów. Potem w narzędziach przeglądarki blokuję domeny dostawcy i powtarzam ten sam test laboratoryjny w identycznych warunkach, z ograniczeniem procesora i łącza. Interesuje mnie nie tylko końcowa nota, ale przede wszystkim, ile czasu na głównym wątku zajmowały skrypty spoza mojej domeny.

Osobno patrzę na listę długich zadań i sprawdzam, czy któreś z nich pochodzi z tego narzędzia. Jedno zadanie trwające pół sekundy jest gorsze niż dziesięć krótkich o tej samej sumie, bo tylko to pierwsze zablokuje reakcję na dotknięcie.

Na koniec — i to jest część, którą najczęściej się pomija — sprawdzam po drugiej stronie, ile ten widget przynosi. Ile rozmów miesięcznie faktycznie zaczyna się z niego i ile z nich kończy się kontaktem handlowym. Bez tej liczby rozmowa o kompromisie jest rozmową o jednej szali wagi.

Czat: co zrobić, żeby nie kosztował

Odpowiedź jest zwykle ta sama i rzadko wymaga rezygnacji z narzędzia: nie wczytuj czatu razem ze stroną.

Zamiast prawdziwego widgetu na start pokazuję lekką atrapę — zwykły przycisk z ikoną, kilka kilobajtów, wizualnie taki sam jak docelowy dymek. Właściwy skrypt dociąga się dopiero po pierwszym kliknięciu w ten przycisk. Użytkownik traci ułamek sekundy w momencie, w którym i tak zdecydował się na rozmowę, a wszyscy pozostali — czyli w praktyce ogromna większość — nie płacą za funkcję, z której nie skorzystają.

Jeśli atrapa jest z jakichś powodów nie do przyjęcia, drugim wyborem jest opóźnienie startu: po zdarzeniu oznaczającym zaangażowanie, na przykład po przewinięciu strony albo po kilku sekundach bezczynności, i zawsze poza kolejką rzeczy potrzebnych do wyświetlenia widoku.

Trzy rzeczy warto przy tym ustalić z dostawcą i z zespołem. Czy skrypt jest wczytywany asynchronicznie. Czy dymek jest pozycjonowany na osobnej warstwie, żeby nie ruszał układu treści. I czy narzędzie nie dokłada własnej czcionki, skoro na stronie są już dwie.

Widgety opinii: więcej niż wydajność

Tu sprawa jest ciekawsza, bo opinie mają wartość nie tylko dla użytkownika, ale i dla widoczności — pod warunkiem, że są wdrożone właściwie.

Najczęstszy błąd techniczny: cała karuzela dociąga się po stronie przeglądarki, z zewnętrznego adresu, bez zarezerwowanego miejsca. Skutek podwójny. Układ strony przeskakuje, a treść opinii nie istnieje w źródle dokumentu, więc nie liczy się jako część zawartości podstrony.

Rozwiązanie, które proponuję najczęściej, wygląda tak: treść opinii wstawiana jest w kod strony po stronie serwera — choćby ostatnie kilka wpisów, cyklicznie odświeżanych — a interaktywna karuzela dostawcy ładuje się dopiero, gdy blok wejdzie w pole widzenia. Miejsce na blok rezerwuję z góry, znając jego wysokość na obu wariantach układu.

Osobna sprawa to znaczniki danych strukturalnych z ocenami. Muszą opisywać opinie faktycznie widoczne na tej podstronie i tylko takie — samodzielnie wystawione oceny własnych produktów nie kwalifikują się do wyróżnień w wynikach wyszukiwania. Widziałem konta, na których agresywne oznaczanie ocen skończyło się ręcznym działaniem i utratą wyróżnień, więc to nie jest ryzyko teoretyczne.

Kiedy naprawdę warto coś wyłączyć

Jest kilka sytuacji, w których nie próbuję ratować narzędzia, tylko proponuję jego usunięcie.

Pierwsza: nikt nie umie odpowiedzieć, kto z niego korzysta. Czat bez obsługi po drugiej stronie, z automatyczną odpowiedzią „wróć w godzinach pracy”, jest samym kosztem. Druga: dwa narzędzia robią to samo, bo jedno zostało po poprzedniej agencji, a nikt nie odważył się skasować kodu. To trafiam na większości audytów, które prowadzę. Trzecia: skrypt zbiera dane, których nie obejmuje zgoda użytkownika — wtedy problem jest poważniejszy niż wskaźniki i wymaga decyzji niezależnie od wydajności.

Poza tymi przypadkami zwykle udaje się zostawić funkcję i odzyskać większość utraconej wydajności. Wymaga to jednak jednej rzeczy, o którą trudniej niż o kod: żeby ktoś w firmie miał listę wszystkiego, co jest wstawione na stronę, i wiedział, po co.