how long a chat takes to open after the click
On a throttled phone-class setup, Spookat’s chat is ready to type in 0.80 seconds after the first click, and 0.13 seconds after that. One widget opened faster on the first click, by 0.15 seconds, because it had already downloaded its whole chat before anyone clicked. This post has the numbers, what each approach costs, and why one round trip is the whole trick.
what we measured
The moment a visitor decides to write is the only moment a chat widget exists for. So: from the click on the launcher to the first thing the visitor can use, the message box or, for widgets that open on a home screen, the button that leads to it.
The setup is the same lab as the rest of the series (how we test), with a few things specific to this test:
- Throttling. Lighthouse’s mobile values, applied with DevTools throttling: 562.5 ms of latency on every request, 1.47 Mbps down, 675 kbps up, and the CPU slowed 4 times. That’s a mid-range phone on a slow 4G connection. It’s switched on right before the click, so it only affects the opening, not the page load.
- Cold. A fresh browser profile. The page loads, the launcher shows, then we wait 15 more seconds so every widget has finished booting, and click the middle of the launcher with the mouse.
- Warm. Same profile, a new tab on the same page, so the widget’s files are in the browser’s HTTP cache. Same routine.
- Timing. From the click until the widget’s usable element is visible, checked every ~25 ms. So the numbers are good to about ±25 ms.
- Runs. 5 per widget, measured on 2026-09-27. We report medians. Spookat’s rows were measured again that morning, after the fix described below and once more after its launcher got lighter, with the same setup: its cold opens ranged from 776 to 829 ms.
Spookat, Tawk.to and Tidio ran on our test page. Crisp, Intercom, LiveChat and Chatwoot refuse to run on a domain their owner didn’t allow, so they were clicked on the vendor’s own site, with that vendor’s own settings. The chat panel for Spookat comes from our production CDN; its socket goes to a small local mock, and DevTools throttling slows that socket just like a real one (we checked: the first message took 587 ms throttled, 1.3 ms without). Spookat’s panel doesn’t wait for that socket to be usable, so the mock doesn’t change its time.
the results
| widget | cold: click → usable | warm | downloaded on the click (cold) | downloaded before the click |
|---|---|---|---|---|
| Chatwoot | 0.65 s | 0.53 s | 0 kb | 864 kb |
| Spookat | 0.80 s | 0.13 s | 17 kb | 2.0 kb |
| Tidio | 1.08 s | 1.08 s | 0 kb | 511 kb |
| Intercom | 1.64 s | 1.67 s | 151 kb | 1,006 kb |
| Crisp | 2.60 s | 0.09 s | 125 kb | 121 kb |
| Tawk.to | 5.09 s | 5.09 s | 120 kb | 256 kb |
| LiveChat | no click needed | no click needed | none | 358 kb |
The last column comes from the weigh-in: what each widget downloads when the page loads, before anyone touches it.
Read the two last columns together and the pattern is plain. Chatwoot and Tidio download nothing on the click because they already downloaded 864 kb and 511 kb on page load. Spookat downloads almost everything on the click, because it downloaded 2.0 kb on page load, and it still opens second, ahead of Tidio’s prepaid chat.
widget by widget
chatwoot: 0.65 s, prepaid
Chatwoot’s chat window is an iframe that’s already loaded and hidden when the page opens. The click just shows it, on its home screen with a “Start Conversation” button. Nothing came over the network, so the 0.65 seconds is the widget showing and drawing itself on a 4x slowed CPU.
tidio: 1.08 s, prepaid
Same idea. Tidio had its widget script (228 kb) loaded before the click, so opening needs no network at all. The 1.08 seconds is the same in cold and warm runs, which tells you it’s rendering and animation on a slow CPU, not downloading. Tidio opens on a home screen with a “Chat with us” button.
intercom: 1.64 s
On intercom.com the click fetched 12 to 14 more requests (31 to 151 kb, varying between runs) and opened straight into the conversation the site had pushed to us as new visitors, with a message box. Cold and warm are the same, so the time isn’t spent waiting on its own files.
spookat: 0.80 s cold, 0.13 s warm
Here’s where the 0.80 seconds go. The moment the mouse button goes down (or a finger touches the screen, or Enter or Space is pressed on the launcher), the launcher starts two downloads side by side: the chat panel (14.5 kb over the wire) and your style’s stylesheet (2.2 kb). The launcher already knows the site’s look, so it knows which stylesheet to ask for. When both are in, the panel shows with the message box focused. The socket to our API connects in the background, and a message typed before it’s up waits and goes out once it is.
That’s one round trip: 562.5 ms of latency, the download, and drawing the panel on a CPU slowed 4 times. Warm, both files come from the cache and there’s no round trip left, just the drawing: 0.13 seconds.
Spookat does it all in one round trip. The moment the visitor presses the button, the launcher starts the panel and the site’s stylesheet together, and the panel is ready to type in before the connection has even finished. Before the visitor reaches for the button, only the launcher is on the page, and nothing talks to our API before the click.
crisp: 2.60 s cold, 0.09 s warm
On the first click Crisp downloads 4 requests, 125 kb, before it shows its message box. In the warm tab the same files were already cached and loaded with the page, and the click opened the chat in 0.09 seconds, the fastest of any widget in any run.
tawk.to: 5.09 s, cold or warm
Tawk.to downloaded 13 requests and 120 kb on the first click, and 15 requests but only 2 kb on the warm one. Both took 5.09 seconds, within 25 ms of each other across all 10 runs. When a time doesn’t move with a warm cache, the wait isn’t the download. We didn’t dig into what Tawk.to waits for, only that it’s the same wait every time. On tawk.to’s own configuration the panel opens with an AI assistant’s greeting and suggested questions above the message box.
livechat: nothing to click
On livechat.com, the closed widget isn’t a round button. It’s a greeting card with a message box already in it, visible from page load. So you can type without clicking anything, and there’s no click to time. That’s a design choice, and a fast one for the visitor. It’s also why LiveChat loaded 358 kb before any interaction.
“usable” isn’t the same screen everywhere
We timed the first thing a visitor can act on, and that thing differs:
| widget | first screen after the click | what the visitor does next |
|---|---|---|
| Spookat | the conversation with a greeting and a focused message box | types |
| Tawk.to | the conversation with a message box and suggested questions | types, or picks a question |
| Crisp | a home view with a message box and suggested questions | types |
| Intercom | the conversation the site pushed, with a message box | types |
| Tidio | a home screen with a “Chat with us” button | clicks again, then types |
| Chatwoot | a home screen with a “Start Conversation” button and help articles | clicks again, then types |
| LiveChat | already a message box before any click | types |
So Tidio’s and Chatwoot’s fast numbers come with a second tap before anyone can write. A home screen isn’t wrong: it’s where help articles and suggestions live. But if the question is “how long until I can say something”, those two need one more step than the table above shows.
Spookat’s panel puts the cursor in the message box as it opens, so the first thing a visitor gets after the click is somewhere to type.
why latency beats bytes on a phone
Our click downloads 17 kb. At 1.47 Mbps that takes under 100 ms. The rest is waiting: 562.5 ms per round trip, where the phone sends a request and waits for the first byte back.
That’s why round trips matter more than size once a widget is small. Halving the panel would save about 50 ms. Doing everything in one round trip is what gets ours to 0.80 seconds with the same bytes. It’s also why the prepaid widgets do well in this test: they’ve already done their round trips during the page load, when nobody was counting.
the trade-off, in one table
| widget | total downloaded to reach a usable chat (cold) | who pays |
|---|---|---|
| Spookat | 19 kb | only visitors who click |
| Crisp | 246 kb | everyone for 121 kb, clickers for the rest |
| Tawk.to | 376 kb | everyone for 256 kb, clickers for the rest |
| LiveChat | 358 kb | everyone |
| Tidio | 511 kb | everyone |
| Chatwoot | 864 kb | everyone |
| Intercom | 1,157 kb | everyone for 1,006 kb, clickers for the rest |
A widget can be fast on the click in two ways. It can do the work ahead of time for every visitor, or it can do very little work, all of it on the click. The first makes the click feel instant and makes every page view heavier. The second keeps page views light and makes the first click wait for the network.
Most visitors never open the chat. For them, prepaid speed is pure cost: they download a chat they never see. For the ones who do open it, the gap between Chatwoot’s 0.65 seconds and our 0.80 is 150 milliseconds on a slow phone, bought with 864 kb for every visitor.
We chose the second approach on purpose. 2 kb on every page view, and 17 kb and under a second on the worst connection for the people who actually want to talk. On a normal connection, that round trip is tens of milliseconds, not half a second.
what we changed, and what we won’t
We’re not going to preload the panel for everyone. That would make us a 20 kb widget before the click, and the whole point is that we aren’t.
What we changed instead, without giving that up:
- The panel and the stylesheet load side by side instead of one after the other.
- Both start on
pointerdown, the moment the finger touches the screen or the mouse button goes down, a little before the click fires. From the keyboard, on Enter or Space. Tabbing past the launcher loads nothing. - The panel shows as soon as its files are in. It no longer waits for the socket and the site’s settings.
One round trip: 0.80 seconds cold, 0.13 seconds warm, 17 kb.
what this test doesn’t show
- Real networks. DevTools throttling adds a fixed latency to each request. A real phone network varies, and the first connection to a new server also costs DNS and TLS handshakes, which this setup doesn’t model for any widget.
- Real configurations. Four widgets ran with their vendors’ own settings on their vendors’ own sites. Your install of the same widget will open into a different first screen.
- What happens after. Sending a message, getting a reply, reconnecting after a drop: all of that is outside this test.
check it yourself
The raw data is at /research/click-to-open-2026-09.json: every run, cold and warm, with what was downloaded between the click and the usable chat, the throttling values and the exact snippets. The script is click.ts in the widget lab.
To try it on your own site: open DevTools, set the Network throttle to “Slow 4G” and the CPU to 4x slowdown in the Performance panel, reload, wait for the page to settle, and click the chat with the Network tab open. Watch what loads after the click and how long until you can type.
so
If opening speed on a slow phone is all that matters to you, one widget in this test opened 0.15 seconds faster than ours on the first click, and it had downloaded 864 kb for every visitor to do it. Spookat is 2 kb until someone reaches for the button, and then one round trip away from a message box.
Try the click yourself: 14 days, no card.