jak testujemy widgety czatu

28 września 2026 · pisze kuba · 7 min czytania

Sprzedajemy widget czatu i zaraz zaczynamy serię wpisów, w których porównujemy go z sześcioma innymi. Benchmarkowi od vendora nie należy ufać z automatu, więc ten wpis to laboratorium za każdą liczbą: co mierzymy, jak, na jakim setupie, czego nie dało się zmierzyć i gdzie leżą surowe dane, żebyś mógł to sprawdzić.

Spookat, Tawk.to, Crisp, Intercom, Tidio, LiveChat i Chatwoot: ta sama szóstka, z którą porównujemy się na stronach porównań na tej stronie.

Dla każdego rywala bierzemy snippet instalacyjny z dokumentacji vendora i id widgetu, które vendor sam trzyma na swojej stronie głównej. Ta druga część jest ważna: nie zakładaliśmy nigdzie kont i nie pożyczaliśmy id od żadnego klienta. Ładujemy dokładnie to, co vendor serwuje odwiedzającym własną stronę, z jego własną konfiguracją.

Spookata ładujemy z produkcyjnego cdn.spookat.com, ten sam plik, który dostaje strona każdego klienta, z kluczem, który nie należy do żadnej strony. Przed kliknięciem w grę wchodzi tylko ten jeden plik, więc klucz nic nie zmienia.

co mierzymy i po co

Widget czatu siedzi na każdej podstronie, a większość odwiedzających nigdy go nie otwiera. Pierwsze pytania dotyczą więc tego, ile kosztuje ludzi, którzy nie klikają. Ostatnie tych, którzy klikają.

test	co zapisujemy	czemu to ważne
ważenie	bajty (skompresowane i nie), requesty według typu i domeny, przed jakąkolwiek interakcją	ściąga to każdy odwiedzający, większość na darmo
cookies	cookies, localStorage, sessionStorage, IndexedDB i domeny, z którymi widget gada przed interakcją	to, co ląduje w pamięci przeglądarki przed zgodą, decyduje, czy widget potrzebuje banera cookies
lighthouse	wynik performance, Total Blocking Time, Largest Contentful Paint, czas głównego wątku: sama strona vs strona z każdym widgetem	liczba, na którą patrzy twój człowiek od SEO, mierzona tak, jak mierzą narzędzia Google
klik do otwarcia	czas od kliknięcia do momentu, gdy da się pisać, z zimnym i ciepłym cache, na zdławionym setupie klasy telefonu	jedyny moment, dla którego widget w ogóle istnieje
telefon	rozmiar i pozycja launchera na ekranie 375×812, co zasłania, wielkość celu dotyku, co robi otwarcie, co się dzieje z klawiaturą	większość czatów dzieje się na telefonie
dostępność	axe-core na zamkniętym i otwartym widgecie, potem sama klawiatura: dojść, otworzyć, napisać, zamknąć, zobaczyć, gdzie ląduje fokus	widget, którego nie da się użyć bez myszy, odcina ludzi od twojego supportu

Każdy test dostaje własny wpis z własnymi liczbami. Ten opisuje wspólną metodę.

setup

Przeglądarka: Google Chrome 153.0.8010.53, zainstalowany stabilny build, sterowany Playwrightem 1.63. W trybie z oknem, bo niektóre widgety odmawiają startu, gdy przeglądarka ma w user agencie „HeadlessChrome”, a prawdziwe okno to to, co mają odwiedzający.
Czysty profil przy każdym przebiegu: każdy przebieg odpala Chrome z nowym profilem w świeżym katalogu tymczasowym. Pusty cache, zero cookies, zero storage, domyślne ustawienia Chrome. Kiedy test potrzebuje ciepłego cache, mówi o tym i celowo używa profilu drugi raz.
Strona testowa: zwykła strona zmyślonego sklepu z kubkami: nagłówek, kilka akapitów, siatka cen, stopka, systemowe fonty, bez obrazków, bez własnych skryptów. Snippet każdego widgetu idzie na koniec <body>, tam gdzie każą vendorzy. Sama strona to punkt odniesienia dla każdego porównania.
Maszyna: Mac na Apple silicon. Lighthouse przy każdym przebiegu podaje indeks benchmarku CPU i publikujemy go obok wyników.
Dławienie: Lighthouse chodzi na domyślnych ustawieniach mobilnych: ekran Moto G Power, symulowane wolne 4G (150 ms round trip, 1,6 Mb/s w dół) i 4× wolniejszy CPU. Test kliknięcia używa tych samych wartości jako throttlingu z DevTools, włączanego tuż przed kliknięciem. Ważenie i cookies idą bez dławienia, bo bajty i cookies nie zależą od prędkości.
Przebiegi: co najmniej 5 na widget na test, 7 przy ważeniu i Lighthouse. Podajemy mediany i publikujemy każdy przebieg.
Okno czasowe: testy sprzed kliknięcia patrzą na stronę przez 25 sekund, niczego nie dotykając. Kilka widgetów ładuje się długo po evencie load strony, a krótkie okno by im schlebiało.

cztery widgety nie ruszą na stronie testowej

To zmieniło plan. Crisp, Intercom, LiveChat i Chatwoot sprawdzają, na jakiej domenie działają, a id, których możemy użyć, należą do stron samych vendorów. Na naszej stronie testowej:

Crisp pokazuje obok launchera czerwoną etykietę „Invalid website”.
Serwer Intercomu odpowiada 403, a w konsoli stoi, że domena nie jest dozwolona.
LiveChat loguje, że domena jest „not added to the allowed domains”, i się wyłącza.
Okno czatu Chatwoota to iframe, który jego własna polityka bezpieczeństwa pozwala osadzać tylko na kilku domenach, więc przeglądarka go blokuje.

Tawk.to i Spookat startują wszędzie. Tidio też, ale vendor ustawił swój widget jako ukryty, więc nasza strona przed jakimkolwiek kliknięciem woła udokumentowane tidioChatApi.show(), żeby pokazał się launcher, jaki daje domyślna instalacja.

Mogliśmy oszukać przeglądarkę, że nasza strona testowa leży na domenie vendora. Nie zrobiliśmy tego. Te cztery widgety mierzymy więc dwa razy:

Na naszej stronie testowej, co pokazuje, ile ładują, zanim odmówią. Ta część jest prawdziwa i płaci ją każdy odwiedzający na złej domenie, ale to dolna granica, a nie pełna waga.
Na stronie samego vendora, tak jak widzi ją każdy odwiedzający. Liczymy tam tylko requesty pod własne adresy widgetu (na przykład client.crisp.chat albo js.intercomcdn.com) i każdy policzony URL jest w surowych danych. Przy cookies i storage ładujemy tę samą stronę jeszcze raz z zablokowanym widgetem, a nazwa liczy się jako należąca do widgetu tylko wtedy, gdy pojawia się z widgetem i nigdy bez niego. Przy Lighthouse porównujemy stronę vendora taką, jaka jest, z tą samą stroną z zablokowanym skryptem ładującym widget.

Strona vendora przychodzi z jego własnymi ustawieniami. Intercom na swojej stronie wypycha wiadomość do nowych odwiedzających, LiveChat otwiera się z kartą powitalną, Tawk.to pokazuje powitanie od AI. Domyślna instalacja na twojej stronie może ładować mniej albo więcej. Tam, gdzie to zmienia liczbę, wpis to mówi.

Jeszcze jedno ograniczenie: na stronie głównej chatwoot.com widget Chatwoota nie załadował się w żadnej z naszych trzech prób, więc używamy help center na tej samej domenie, gdzie się ładował.

czego nigdy nie robimy

Żadnych kont, triali ani id, które nie są vendora.
Żadnych wiadomości. Otwieramy czaty, w teście dostępności piszemy w polu tekstowym i nigdy nie klikamy wyślij. Żaden zespół supportu nie dostaje od nas fejkowego odwiedzającego.
Żadnego tuningu. Każdy widget chodzi z konfiguracją, którą wybrał jego właściciel (poza wywołaniem show u Tidio, patrz wyżej). Nasz też: Spookat nie ma opublikowanego wyglądu, więc pokazuje domyślny styl.
Żadnych liczb ze stron marketingowych. Jeśli liczba jest we wpisie, wyszła z przebiegu.

gdzie nasz ma łatwiej, a gdzie nie

Launcher i panel czatu Spookata ładują się z produkcyjnego CDN. Jedynym wyjątkiem jest socket czatu. Normalnie idzie do api.spookat.com i potrzebowałby prawdziwej strony, żeby ktoś odpowiedział, więc w laboratorium idzie do małej atrapy na tej samej maszynie, która wysyła tę samą pierwszą ramkę co nasz serwer. Przed kliknięciem to nic nie zmienia, bo launcher nie otwiera żadnego socketu. Po kliknięciu throttling z DevTools i tak obejmuje ten socket: sprawdziliśmy, pierwsza ramka przyszła po 587 ms z throttlingiem i po 1,3 ms bez. Atrapa pomija prawdziwy handshake TLS i pracę prawdziwego serwera, a wpis o kliknięciu mówi, ile to może być warte.

Wiersze Spookata zmierzyliśmy 27 września 2026 dwa razy. Pierwszy przebieg znalazł w naszym widgecie trzy rzeczy, które nam się nie podobały: pierwsze otwarcie, które szło trzema round tripami po kolei, launcher, który na telefonie siedział na dolnym pasku sklepu, i trzy uwagi z dostępności w otwartym panelu. Poprawiliśmy wszystkie trzy tego ranka, wypuściliśmy poprawkę na produkcję i zmierzyliśmy nasze wiersze jeszcze raz na tym samym setupie. Później tego ranka odchudziliśmy launcher i wyłączyliśmy dwa nagłówki do raportowania błędów, które nasz CDN dokładał do każdej odpowiedzi, i zmierzyliśmy jeszcze raz wiersze ważenia, Lighthouse’a i testu kliknięcia. Każda liczba Spookata w serii pochodzi z jego ostatniego przebiegu, a każdy plik z danymi oznacza wiersze Spookata tym, kiedy i czemu je zmierzyliśmy. Wiersze konkurencji są z pierwszego przebiegu. Od poprawki panel Spookata nie czeka na socket, zanim da się pisać, więc atrapa socketu nie zmienia jego czasu otwarcia.

jak nas sprawdzić

Każdy test zapisuje jeden plik JSON z metodą, wersjami, medianami i każdym przebiegiem:

Każdy plik ma też listę widgetów z dokładnym snippetem i id, których użyliśmy. Każdy wpis linkuje swój plik, a wpisy wchodzą po kolei w najbliższych tygodniach.

Skrypty też są publiczne: laboratorium widgetów serwuje każdy plik dokładnie w tej wersji, która chodziła, z jedną komendą na test (bun run weigh-in, bun run lighthouse i tak dalej). Nie potrzebujesz ich, żeby sprawdzić liczbę. Otwórz stronę vendora albo swój staging, otwórz DevTools, zaznacz „Disable cache”, przeładuj i przefiltruj zakładkę Network po domenach widgetu. To całe ważenie. Poradnik o dodaniu czatu bez spowalniania strony przechodzi przez to krok po kroku. Lighthouse masz w każdym Chrome.

Jeśli wyjdzie ci inna liczba, napisz. Widgety zmieniają się co tydzień, my też. Wolimy poprawić wpis, niż go bronić.

po co to wszystko

Uważamy, że widget czatu powinien kosztować stronę prawie nic, dopóki ktoś nie chce pogadać, i wokół tego zbudowaliśmy Spookata. Powiedzieć to jest tanio. Zmierzyć to obok wszystkich innych, opublikować surowe przebiegi i pokazać, gdzie nasz setup ma łatwiej, to jedyna wersja tej tezy, którą warto czytać.

Launcher, który testowałbyś, ma mniej niż 4 kb i robi 0 requestów do naszego API przed kliknięciem. Wrzuć go na staging i zważ go sam.