co widget czatu robi z twoim wynikiem w lighthouse
Puściliśmy Lighthouse na zwykłej stronie testowej z każdym z siedmiu widgetów czatu, po 7 razy, na domyślnych ustawieniach mobilnych. Sześć dostało 100, jeden 99. Brzmi jak dobra wiadomość dla wszystkich, a mówi głównie o tym, jak Lighthouse mierzy. Na stronach samych vendorów, gdzie widget dzieli stronę z prawdziwą treścią, te same widgety kosztują od 4 do 14 punktów. W tym wpisie są oba zestawy liczb i to, co za nimi stoi.
setup w skrócie
Lighthouse 13.5 jako moduł Node, sterujący Google Chrome 153 ze świeżym profilem przy każdym przebiegu. Domyślne ustawienia mobilne: ekran Moto G Power, symulowane wolne 4G (150 ms round trip, 1,6 Mb/s w dół) i 4× wolniejszy CPU. Tylko kategoria performance. Każda liczba to mediana z 7 przebiegów, zmierzona 27 września 2026 (wiersz Spookata jeszcze raz później tego ranka, po zmianach w launcherze). Indeks benchmarku CPU maszyny w Lighthouse wynosił przy każdym przebiegu około 4050.
Strona testowa to zwykła strona zmyślonego sklepu: tekst, siatka cen, stopka, systemowe fonty, bez obrazków, bez własnych skryptów. Ta sama co w ważeniu. Resztę opisuje jak testujemy.
z czego składa się wynik
Lighthouse 13 liczy performance z pięciu pomiarów czasu, każdy przelicza na wartość 0–100 względem danych z prawdziwego świata i waży:
| metryka | waga | co mierzy |
|---|---|---|
| Total Blocking Time | 30% | jak długo główny wątek był zablokowany przez zadania dłuższe niż 50 ms, między pierwszym renderem a interaktywnością |
| Largest Contentful Paint | 25% | kiedy pojawił się największy element na ekranie |
| Cumulative Layout Shift | 25% | jak bardzo strona skakała |
| First Contentful Paint | 10% | kiedy pojawiło się cokolwiek |
| Speed Index | 10% | jak szybko wypełnił się ekran |
Widget czatu może ruszyć wszystkie pięć, ale zwykle rusza dwa. Jego skrypty konkurują ze skryptami strony o główny wątek, czyli TBT. Jego requesty konkurują z obrazkami i fontami strony o wolne łącze, co może opóźnić LCP. Launcher, który wyskakuje i przesuwa treść, uderzyłby w CLS; żaden z siedmiu tego nie zrobił, na żadnej stronie.
na stronie testowej: prawie same setki
| widget | wynik | TBT | LCP | praca głównego wątku | bajty, które widział Lighthouse |
|---|---|---|---|---|---|
| sama strona | 100 | 0 ms | 750 ms | 117 ms | 3 kb |
| Spookat | 100 | 0 ms | 606 ms | 118 ms | 5 kb |
| Tawk.to | 100 | 0 ms | 606 ms | 318 ms | 223 kb |
| Tidio | 100 | 0 ms | 608 ms | 489 ms | 514 kb |
| Intercom | 99 | 106 ms | 750 ms | 399 ms | 290 kb |
| Crisp | 100 | 0 ms | 606 ms | 115 ms | 6 kb |
| LiveChat | 100 | 0 ms | 606 ms | 110 ms | 42 kb |
| Chatwoot | 100 | 0 ms | 606 ms | 102 ms | 11 kb |
TBT to Total Blocking Time, część wyniku, która mierzy, jak długo główny wątek był zbyt zajęty, żeby reagować. LCP to Largest Contentful Paint, moment pojawienia się największej rzeczy na ekranie. Praca głównego wątku to wszystko, co główny wątek przeglądarki zrobił w czasie przebiegu: parsowanie HTML, uruchamianie skryptów, style, layout. LCP skakało między 606 a 750 ms bez wzoru, który dałoby się przypisać jakiemukolwiek widgetowi, więc nic z tego nie wyczytujemy.
Dwie rzeczy rzucają się w oczy.
Wynik chowa prawdziwą robotę. Tidio dołożył stronie około 370 ms pracy głównego wątku, Intercom około 280 ms, Tawk.to około 200 ms. Wszystkie trzy i tak dostały 99 albo 100. Lighthouse liczy tylko te kawałki zadań, które przekraczają 50 ms, i tylko do momentu, gdy uzna stronę za interaktywną. Widget, który ładuje się później albo dzieli pracę na małe kawałki, dokłada robotę, którą telefon odwiedzającego wykonuje, a wynik się nie rusza. Launcher Spookata dołożył 4 ms, co mieści się w szumie między przebiegami samej strony (od 78 do 131 ms).
Lighthouse przestaje patrzeć. Lighthouse kończy przebieg, kiedy sieć i CPU przez chwilę są spokojne. Czego widget nie załaduje do tego czasu, tego nie ma w raporcie. W ważeniu, z oknem 25 sekund, Tawk.to przesłał 256 kb; Lighthouse zobaczył z tego 223 kb.
Liczy się moment startu. Snippety odpalają widgety w różnych momentach. Oficjalny snippet Intercomu czeka na event load strony, zanim w ogóle poprosi o loader. Tawk.to, Crisp, Tidio, LiveChat i Spookat wstawiają skrypt async, gdy tylko snippet się wykona, a Chatwoot ma async i defer. Żaden nie blokuje pierwszego renderu, dlatego FCP jest identyczne w każdym wierszu. Różni się to, ile roboty ląduje w sekundach tuż po nim, czyli wtedy, gdy Lighthouse wciąż mierzy TBT.
Wykonanie JavaScriptu mówi to samo co praca głównego wątku. Lighthouse podaje też, ile czasu strona spędziła na uruchamianiu skryptów. Sama strona: 3 ms. Spookat: 3 ms. Tawk.to: 136 ms. Tidio: 197 ms. Intercom: 229 ms, choć został odrzucony i doszedł tylko do swoich dwóch bazowych paczek. Na 4× zwolnionym CPU tyle wydaje średni telefon przy każdym wyświetleniu strony, zanim odwiedzający cokolwiek zdecyduje.
Trzy wiersze są niskie z innych powodów. LiveChat i Chatwoot odmawiają działania na domenie, której właściciel nie dopuścił, więc i tu stanęły wcześnie. Crisp też odrzuca naszą domenę, ale pod Lighthouse załadował jeszcze mniej niż w ważeniu: swój loader na 3 kb i nic więcej. Jego loader ma listę user agentów, dla których nie startuje, i są na niej „Lighthouse” i „GTmetrix”. User agent w naszych przebiegach nie zawierał żadnego z tych słów, więc sama ta lista tego nie tłumaczy. Podajemy, co się stało, i nie zgadujemy dlaczego.
na stronach vendorów: od 4 do 14 punktów
Strona testowa to najlepszy przypadek dla widgetu: nic innego nie konkuruje o sieć ani o główny wątek. Prawdziwe strony mają duże obrazki, fonty, analitykę i własne skrypty i tam koszt widgetu wychodzi w wyniku.
Dla czterech widgetów, które nie ruszą na naszej domenie, puściliśmy Lighthouse na stronie vendora dwa razy: taką, jaka jest, i z zablokowanym skryptem ładującym widget (blockedUrlPatterns w Lighthouse). Ta sama strona, te same ustawienia, po 7 przebiegów. Różnica to koszt widgetu na tej stronie.
| strona | wynik bez widgetu | wynik z widgetem | TBT bez → z | LCP bez → z | główny wątek bez → z |
|---|---|---|---|---|---|
| crisp.chat | 78 | 64 | 220 → 222 ms | 4,3 → 6,8 s | 1,35 → 1,32 s |
| intercom.com | 87 | 80 | 199 → 366 ms | 2,2 → 2,2 s | 2,48 → 3,34 s |
| livechat.com | 90 | 86 | 262 → 260 ms | 2,7 → 3,2 s | 1,87 → 2,06 s |
| chatwoot.com (help center) | 63 | 63 | 0 → 0 ms | 6,1 → 6,3 s | 0,71 → 0,90 s |
Każdy widget boli inaczej:
- Intercom to najczystszy przypadek: 860 ms więcej pracy głównego wątku i 167 ms więcej blokowania, czyli 7 punktów.
- Crisp prawie nie ruszył głównego wątku, ale największy render przesunął się z 4,3 na 6,8 sekundy, co kosztowało 14 punktów. Nasze przebiegi nie pokazują, który element stał się największym renderem, tylko że z widgetem na stronie przyszedł później.
- LiveChat kosztował 4 punkty, głównie przez późniejszy największy render i 190 ms więcej pracy głównego wątku.
- Chatwoot dołożył 194 ms pracy głównego wątku i 865 kb na stronie help center, ale wynik się nie ruszył: ta strona i tak stała na 63 z własnych powodów.
Te strony są zaszumione. crisp.chat bez widgetu dostawał w 7 przebiegach od 64 do 84, a livechat.com z widgetem od 67 do 92. Dlatego robimy 7 przebiegów i podajemy mediany, i dlatego pojedynczy przebieg Lighthouse na twojej stronie mówi bardzo mało. Wszystkie 7 przebiegów każdej strony są w surowych danych.
To porównanie ma jedno ograniczenie, o którym trzeba wiedzieć: na stronie vendora widget chodzi z ustawieniami vendora. Intercom na swojej stronie wypycha wiadomość do nowych odwiedzających, co ładuje więcej kodu niż cicha instalacja. Twoja strona z tym samym widgetem wyląduje gdzie indziej. Kierunek się nie zmieni.
czego jeszcze nie możemy pokazać
Nie mogliśmy postawić Spookata na stronie vendora i nie chcieliśmy wymyślać ciężkiej strony tylko po to, żeby dobrze wypaść. Strona Spookata ma w Lighthouse 100, a jak do tego doszła, opiszemy w osobnym wpisie. Co pokazuje strona testowa: launcher Spookata nie ruszył żadnej liczby w Lighthouse poza szum i przesłał 2,0 kb, najmniej ze wszystkich widgetów tutaj.
czemu wynik może być 100, a strona i tak wolniejsza
Wynik Lighthouse to ważona mieszanka pięciu pomiarów czasu, zmierzonych na symulowanym telefonie, w pierwszych sekundach ładowania strony. To dobre przybliżenie tego, czy strona szybko się pokazuje, i to właśnie raportują narzędzia Google. To nie jest pełny rachunek tego, ile strona kosztuje.
Widget czatu robi większość swojej roboty, gdy strona już się pokazała. Lighthouse liczy tę część lekko albo wcale. Telefon odwiedzającego i tak ją wykonuje: parsowanie, kompilowanie, websocket, timery, CPU i baterię, które to zjada, przy każdym wyświetleniu strony, czy ktoś czatuje, czy nie. Dlatego obok wyniku mierzymy bajty i pracę głównego wątku i dlatego ważenie jest tak samo ważne jak ten wpis.
Jeśli twoja strona jest lekka, większość widgetów nie zabierze ci setki. Jeśli już jest zajęta, a większość prawdziwych stron jest, widget może zabrać od 4 do 14 punktów, co pokazują strony samych vendorów.
wynik z laboratorium a to, co Google widzi od prawdziwych userów
Lighthouse to test laboratoryjny: jeden symulowany telefon, jedno ładowanie, nikt niczego nie dotyka. Ranking w Google opiera się na danych z pola, czyli Core Web Vitals zbieranych od prawdziwych userów Chrome: LCP, CLS i Interaction to Next Paint (INP), które w marcu 2024 zastąpiło First Input Delay.
Przy widgetach czatu warto myśleć o INP. Mierzy, jak długo strona reaguje, gdy ktoś stuknie albo coś wpisze, a przebieg w laboratorium bez żadnej interakcji w ogóle go nie zmierzy. Rośnie, gdy główny wątek jest zajęty w chwili stuknięcia. Praca głównego wątku z pierwszej tabeli, te 200 do 370 ms, które wynik zignorował, to dokładnie ten rodzaj roboty, która może stanąć przed pierwszym stuknięciem odwiedzającego na wolnym telefonie.
Widget może więc zostawić twój wynik w Lighthouse w spokoju, a i tak wyjść w danych z pola. Jedyny sposób, żeby to sprawdzić na twojej stronie, to raport Core Web Vitals przed i po.
co sprawdzilibyśmy przed wyborem widgetu
- Co ładuje się przed kliknięciem, w bajtach i requestach (ważenie).
- Pracę głównego wątku z nim i bez niego, a nie tylko wynik.
- Lighthouse przed i po na twojej prawdziwej stronie, tej najbardziej zajętej, mediana z co najmniej trzech przebiegów.
- INP z pola kilka tygodni po instalacji.
- Czy widget w ogóle potrafi poczekać na kliknięcie, czy upiera się, żeby startować razem ze stroną.
puść to na swojej stronie
Cały nasz przebieg to jedna komenda w laboratorium widgetów (bun run lighthouse). Nie potrzebujesz jej, żeby zmierzyć swój widget. W Chrome:
- Otwórz swoją stronę, otwórz DevTools, przejdź do zakładki Lighthouse, wybierz Mobile i Performance i puść trzy razy. Zapisz medianę wyniku, TBT i LCP.
- Otwórz zakładkę Network, kliknij prawym na skrypt ładujący widget i wybierz „Block request URL”.
- Puść Lighthouse jeszcze trzy razy. Różnica to twój widget.
Zajrzyj też w obu raportach do „Reduce JavaScript execution time” i „Minimize main-thread work”: tam widget wychodzi, nawet gdy wynik się nie rusza.
Nasze surowe dane leżą w /research/lighthouse-2026-09.json: każdy przebieg z wynikiem, FCP, LCP, TBT, CLS, Speed Indexem, czasem głównego wątku, czasem wykonania JavaScriptu, sumą bajtów i liczbą requestów, indeks benchmarku CPU, wersje Lighthouse i Chrome oraz dokładne snippety.
wniosek
Setka na stronie testowej to nic trudnego, dla nikogo. Wystarczy strona, na której nie ma nic więcej. Gdy tylko widget dzieli prawdziwą stronę z prawdziwymi obrazkami i skryptami, wszystko, co robi w pierwszych sekundach, konkuruje z resztą, a strony samych vendorów pokazują, ile to kosztuje: 4, 7 i 14 punktów i prawie sekunda dodatkowej pracy głównego wątku w przypadku Intercomu. Żeby utrzymać setkę na prawdziwej stronie, widget musi nie robić prawie nic, dopóki ktoś go o to nie poprosi. Tak zbudowaliśmy Spookata: launcher na 2 kb, 0 requestów do naszego API przed kliknięciem, a cała reszta ładuje się, gdy odwiedzający naprawdę chce pogadać.
Wypróbuj go na swojej stronie i puść Lighthouse przed i po. 14 dni, bez karty.