“The file transfer is slow” can describe failures at unrelated layers. Wi-Fi may be congested, the connection may be relaying through a distant TURN region, the browser’s send buffer may be saturated, the receiver may be slow to write, or the application may wait for an acknowledgement after every tiny chunk. Replacing a server after one speed test is an easy way to fix the wrong problem.
Comparisons are more useful than isolated numbers. Direct is fast but relay is slow. Screen sharing over the relay holds several hundred kilobytes per second while a file on the same peer connection stays in the teens. One large file is fine while a folder of small files crawls. Each observation narrows the search.
Make a repeatable baseline
Choose a non-sensitive test file around 200 MB. Record the selected route, sustained average speed, browser version, device, and network type. Ignore the first couple of seconds, and pause unrelated downloads or calls. If possible, repeat with one endpoint on a different network.
Progress should separate bytes queued by the sender, bytes acknowledged by the receiver, and final digest verification. Effective throughput should use acknowledged bytes. A bar that reaches 100 percent and then waits for a long time may reveal excessive local queueing or slow verification rather than a connection that stopped at the finish line.
Identify the active route
Devices on the same LAN should normally find a direct host-to-host route. TURN in that situation can point to guest Wi-Fi isolation, a VPN, a host firewall, or browser policy. Relay between separate restricted networks may be expected. Then the questions are whether the relay region is close, whether it has spare capacity, and whether the transfer protocol tolerates a longer round trip.
A useful rule of thumb: if media, screen sharing, and file data all slow down by a similar ratio, investigate the route and capacity. If file transfer alone collapses while screen sharing remains steady, look at the DataChannel application protocol first.
Respect bufferedAmount and backpressure
A successful call to RTCDataChannel.send() does not mean the peer received the data. It means the browser accepted data into a queue. Repeated calls raise bufferedAmount. An oversized queue consumes memory and places cancel, heartbeat, and progress messages behind megabytes of file content.
Use high and low watermarks. Pause at the high mark and continue after bufferedamountlow or after the receiver frees acknowledgement-window capacity. The threshold should be bounded for the device rather than set to a heroic number. A mobile browser should not carry hundreds of queued megabytes.
Tune chunks and the flight window together
Very small chunks spend too much time on message framing, indexing, and acknowledgements. Very large chunks are expensive to queue and retry. Tens of kilobytes is a reasonable starting range, but chunk size alone is not the control that fills a path. The important value is how many bytes may remain in flight.
A stop-and-wait design performs badly on a relay with a longer round trip. Sending 64 KB and waiting 100 milliseconds after every block caps ideal throughput near 640 KB/s before other overhead. Cumulative or range acknowledgements allow several chunks in flight so useful data continues moving while an acknowledgement returns.
Prioritize control and selective repair
Chat, cancel, transfer control, and bulk chunks can use separate channels, or they can share a scheduler with explicit priority. Control should run ahead of ordinary file chunks. Multiple files need round-robin or weighted fair scheduling so one large item does not freeze every other task.
After loss, the receiver can maintain arrived ranges and report holes. The sender selectively repairs those ranges instead of rolling back to the last contiguous byte. Repeated loss at the same offset may indicate a chunk-index, serialization, or storage-transaction bug; increasing a timeout indefinitely only hides it.
Inspect storage and CPU on the receiver
A modest phone may be receiving data, calculating SHA-256, committing IndexedDB transactions, and redrawing progress on one busy main thread. Move hashing to a Worker, batch storage writes, and reduce UI update frequency. Low disk space or a browser storage quota should produce an early, specific error rather than a transfer that appears to become slower forever.
Watch for a janky page, device heat, or a sharp drop when the browser enters the background. Mobile operating systems throttle background tabs. A large-transfer view should warn people to keep it foregrounded and reconcile state when it becomes visible again.
Debug in this order
- Confirm the speed definition and whether the path is direct or relayed.
- Change one network, then one device, to see which side the symptom follows.
- Compare screen sharing or another WebRTC flow to separate transport from file logic.
- Measure
bufferedAmount, in-flight bytes, acknowledgement delay, and repair rate. - Inspect receiving storage, hashing work, main-thread load, and available quota.
- Only then change chunk size, window limits, or relay deployment—one variable at a time.
First aid without developer tools
In the uCopy workspace, note the route, turn off a VPN, avoid guest Wi-Fi, keep both tabs in the foreground, and retry with one reasonably large file. If direct remains fast and relay remains slow, report the rough regions and sustained rate. If screen sharing is healthy while files crawl, include that comparison in a support report.
Performance work improves quickly once it stops relying on impressions. A known route, a repeatable file, and measurements at each layer reveal whether capacity is genuinely scarce or the application is failing to use the capacity already there.