Here is my summary of the impact of latency on LiveView. I live in South Africa and our servers is in Europe, I have a 150-200ms ping to them. Our entire app is built in LiveView.
Initial page load: The first response is received in 200ms, the page is not actually “live” yet for another moment while the websocket connects, but users won’t really notice it because they don’t start interacting with the page that quickly. If all links are live_redirect and live_patch then initial page load really only happens the very first time you open the page. SPAs will also have a delay the very first time. This is a non issue.
live_patch and other “same view interactions”: If you click a link or interact and the result is shown within 200ms it feels fast. I would rate live_patch links as giving a good experience even with 200ms latency. Other interactions on the same LiveView (phx_change, etc.) give the same good experience. Again LiveView is the same as an SPA if you ask me.
live_redirect: This is where the problem comes in. You can only use live_patch within the same LiveView. The live_redirect links unfortunately seem to take about 2x or 3x latency. It first sends a phx_leave that takes a full latency trip, then sends a phx_join to open the new page. With a 200ms ping this feels slow and is slower than normal links, but if you revert to normal links then you have the initial page load every time. I think if live_redirect can be adjusted to take one round trip (perhaps a phx_leave_and_join event?), then latency really isn’t an issue for LiveView. The way it is now, it is unfortunately an issue without a good alternative. I’ve logged an issue here:
