---
title: "Low Latency LiveView"
description: "LiveView sends HTML fragments over a WebSocket connection, allowing Phoenix applications to update the DOM in response to server or user activity. For interactions such as a like button, however, a server round trip can make feedback feel slow: a sub-100ms sequence may be acceptable, while many interactions benefit from responses under 40ms. The post presents client-side state prediction as one remedy, where the browser displays an expected value immediately and later reconciles it with the server. Its preferred “boring” alternative is reducing round-trip time by running application processes near users in multiple cities, connecting Phoenix instances over a private network and enabling clustering. A seven-region Counter deployment is shown with fly regions set and fly scale count 7, while Phoenix.PubSub and Phoenix.Presence handle clustering transparently."
---

# Low Latency LiveView

[Fly.io](https://yomu.fyi/company/fly-io) · Apr 5, 2021

**Type:** Explainer

## Summary

LiveView sends HTML fragments over a WebSocket connection, allowing Phoenix applications to update the DOM in response to server or user activity. For interactions such as a like button, however, a server round trip can make feedback feel slow: a sub-100ms sequence may be acceptable, while many interactions benefit from responses under 40ms. The post presents client-side state prediction as one remedy, where the browser displays an expected value immediately and later reconciles it with the server. Its preferred “boring” alternative is reducing round-trip time by running application processes near users in multiple cities, connecting Phoenix instances over a private network and enabling clustering. A seven-region Counter deployment is shown with fly regions set and fly scale count 7, while Phoenix.PubSub and Phoenix.Presence handle clustering transparently.

## Context

LiveView interactions can feel slow because user input travels to the server, is processed, and returns as updated HTML. The source says sub-100ms responses may work for a like button, while other interactions benefit from responses under 40ms, especially when users are far from the application.

## Approach / What changed

The source describes two main responses: predict state on the client and reconcile it with the server, or reduce round-trip time by deploying application processes close to users. The latter uses multiple regional instances, a private network, clustering, and routing users to nearby instances; Phoenix.PubSub and Phoenix.Presence support transparent clustering.

## Takeaways

- Client-side prediction can display an expected state immediately, then let the server correct it if the prediction was wrong.
- The source describes Phoenix clustering as an eight-line configuration using Phoenix.PubSub and Phoenix.Presence to coordinate instances across a network.
- The example deploys a LiveView Counter app to seven regions with fly regions set iad lax ams nrt syd sin scl and fly scale count 7.

**Tags:** [Elixir](https://yomu.fyi/topic/elixir), [Latency](https://yomu.fyi/topic/latency), [Phoenix LiveView](https://yomu.fyi/topic/phoenix-liveview), [WebSockets](https://yomu.fyi/topic/websockets)

- Source: [Fly.io](https://fly.io/blog/low-latency-liveview)
- Source URL: https://fly.io/blog/low-latency-liveview
- Ingested by Yomu: 2026-09-03T01:25:09.771Z

[Read original post](https://fly.io/blog/low-latency-liveview)