When a clipboard sync tool says “fast,” what does that actually mean? In ClipHop the answer is typically sub-500 ms round-trip from copy to paste, measured end-to-end on real devices over Bluetooth LE. This post walks through what that number is built from, how we measure it, and why we think sub-500 ms is the right bar.
It’s the kind of thing that sounds obvious until you try to define it precisely. There’s no industry-standard “clipboard latency” metric, so we had to define our own.
The bar#
Human perception studies are surprisingly consistent on this: anything below ~100 ms feels instantaneous, 100–300 ms feels responsive, 300–1000 ms feels like a slight pause, and above 1 second registers as a wait. For something as muscle-memory as copy-paste, you want to land in the responsive band — definitely under 500 ms, ideally under 300 ms in good conditions.
We set sub-500 ms as the design bar because:
- It’s well within the band where the user doesn’t consciously notice latency.
- It’s achievable on Bluetooth LE for plain text and URLs (most clipboard traffic).
- It’s an honest target — not “instantaneous” theater, just “fast enough you don’t notice.”
What “round-trip” actually measures#
The number we care about is end-to-end: from the moment you copy on one device until the clipboard is updated on the other device. Internally that decomposes into four phases:
- Detection. The source device’s clipboard observer fires when copy happens. On Android this is a
ClipboardManager.OnPrimaryClipChangedListener; on macOS it’s a periodic poll ofNSPasteboard.changeCount(Apple gives no real-time hook for clipboard changes, so we tick at ~60 Hz when active). - Encryption. The clip is wrapped in AES-256-GCM with the active session key. See How ClipHop encrypts your clipboard for the cryptographic detail. Encryption is well under a millisecond for clipboard-sized payloads on any modern device.
- Transmission. The encrypted payload travels over the BLE link to the peer. This is the variable part, dominated by BLE connection interval and RSSI.
- Application. The peer device decrypts the payload and writes to its system clipboard via
ClipboardManager.setPrimaryClip(Android) orNSPasteboard.setString:forType:(macOS).
Each phase is instrumented during debug builds. Production builds carry no telemetry — we don’t ship measurement code to users — but we have detailed traces from our own development devices to know where the time goes.
Where the time actually goes#
For a typical 200-byte clipboard payload (a URL or a paragraph of text) on a quality BLE connection:
| Phase | Typical | Notes |
|---|---|---|
| Detection | 0–8 ms (Android) / 0–17 ms (Mac) | Mac is slower because of the polling fallback |
| Encryption | < 1 ms | AES-256-GCM is fast on every modern CPU |
| Transmission | 100–300 ms | Dominated by BLE connection interval (15–60 ms typical) and number of round-trips |
| Application | 5–20 ms | Including write and any system-level clipboard observers firing |
Total: roughly 105–345 ms in good conditions. This is what most users see — clipboard items appear “instantly” on the other device.
L2CAP vs GATT — the multi-kilobyte path#
For larger payloads (long-form text, code snippets in the kilobyte range), how the clip moves over BLE matters a lot.
Modern path (Android 10+, macOS 13+): L2CAP connection-oriented channels. A single L2CAP channel can carry multi-kilobyte payloads in one logical frame, with the BLE controller handling fragmentation underneath. We negotiate L2CAP at pair time when both sides support it.
Fallback: GATT notify/write with chunking. Older devices use the standard GATT layer where each characteristic write is bounded by the negotiated MTU (often ~244 bytes after BLE 4.2’s MTU exchange). For a 4 KB payload this is ~17 round-trips, and the latency penalty is real — closer to 800–1500 ms instead of sub-500.
In practice, almost all currently-shipping Android phones (Android 10 was 2019) and Macs (macOS 13 was 2022) support L2CAP. The fallback exists for stragglers and degraded link conditions.
Conditions that push latency up#
The headline number assumes a healthy BLE connection. In reality, a few conditions shift it:
- Low RSSI (devices far apart, walls between them): BLE controllers throttle or retransmit, adding 50–200 ms.
- High BLE connection interval: the OS sometimes moves the BLE connection to a longer interval (e.g. 100 ms+) to save power. We request shorter intervals where the OS allows it, but the OS has the final say.
- Concurrent BLE activity: another paired BLE device (headphones, watches) can compete for radio time on shared chips.
- Background-throttled foreground service: if Android’s battery killer has put our service in a degraded state (which the install guide walks through fixing), wakeups slow down.
Under realistic worst-case home conditions — phone in pocket, Mac on desk, Apple Watch and AirPods both connected — latency typically lands at 600–800 ms. Still usable; you notice the wait but it’s not broken.
Why faster than 500 ms isn’t the goal#
We could, in principle, push for sub-100 ms by:
- Polling clipboards more aggressively (battery cost).
- Negotiating absurdly short BLE intervals (battery cost, OS pushback).
- Pre-encrypting common clip patterns (engineering complexity for negligible gain).
None of these are worth it. Once latency is under the perception threshold, additional speed doesn’t translate to user-visible improvement. The right engineering move is stay under the bar, then spend cycles on things users actually feel: pairing reliability, battery impact, content-type support.
This is the same calculus video games make at 60 Hz: once you’re below the bar, additional headroom is mostly bragging rights.
Why this matters for cross-device clipboard tools generally#
Clipboard sync gets compared against the “feel” of copy-paste on a single device, where it’s instant — there’s no transport at all. Any cross-device tool has to fight for that perception. The numbers above are what make the difference between “I sent it to my Mac and it just appeared” and “I sent it and… wait, did it work?”
Cloud-routed clipboard tools usually take 400–1500 ms even on a fast network because of the server round-trip. LAN-based tools can be very fast (sub-100 ms in good conditions) but require both devices to be on a common network. BLE direct is the only transport that consistently hits the perception bar without depending on infrastructure you don’t control.
For the transport rationale, see Why we chose Bluetooth LE for clipboard sync. For the cross-platform comparison, see ClipHop vs KDE Connect.
What we measure on every build#
For every release build, we run a regression suite that times the round-trip across a fixed device matrix. If the median round-trip on the reference devices crosses 500 ms, the build fails CI. It’s a blunt check but it’s enough to catch regressions early — most latency problems show up as 2x slowdowns, not 10% drift, so the threshold doesn’t need to be tight.
After launch, our user-side metric will be the inverse of complaints: silence. Most clipboard tools get bug reports about “it took forever to sync” within the first week of public use. We’re working to not be one of them.