A sleep does not really simulate a poor connection. We are reloading the page because the default timeout for a channel join (thus a LV mount) is 10s. This value can be bumped higher via the live socket constructor

new LiveSocket("/...", {timeout: 15000})

However, it seems less likely that your users are frequently taking a 10s round trip to the server. Are you doing any potentially longer blocking work on mount? You can accurately simulate poor network links with latency and packet loss to test a truly poor connection. OS X as a network link condition app, and I’m sure other systems do as well. You can also run these commands on osx:

# enable myapp.local 100ms latency 30% pkt loss
$ sudo -i
$ dnctl pipe 1 config bw 10Mbit/s delay 100 plr 0.3
$ echo "dummynet out proto tcp from any to myapp.local pipe 1" | pfctl -f -
$ pfctl -e

# disable
$ pfctl -f /etc/pf.conf && pfctl -d && dnctl -q flush

How edge are your users? If they consistently see 10s RTT then that will be a barely usable experience no matter what technology choices you make. Simulating 30% packet loss on LiveView applications yields a surprisingly solid experience for me, so we’d need to know more about their conditions and if your own mount is adding to the round trip latency.

One thing that can lead to spotty experience when there is frequent connects / disconnects are live view pages that aren’t coded to recover their state very well. Good examples are modals or other major UI elements that are present / absent on the basis of an assign that isn’t backed by a URL param or form element. If the user disconnects / reconnects, the liveview state is lost and the UI will “glitch” back to the base state.

I’d make sure that any user facing UI states are backed by something client side so that your live view can recovery cleanly.