beepboop

beepboop

(re-post of: Feature idea: measure and expose socket latency · Issue #1890 · phoenixframework/phoenix_live_view · GitHub)

This is related to the following PR: buunguyen/topbar#15

Would LiveView developers be open to the idea of measuring the user’s latency, which could then be used to show loaders of any kind? With a pure timer, you still have a slice of users who can have a “negative experience”; with a 500ms cut-off, the most obvious slice would be the ones who have a 500-700ms latency. Latency-based loaders are better in this sense, since they use an actual signal to provide feedback to the user. To the user with a latency of 550ms, you can actually show the loader for 550ms, instead of for 50ms. Considering that the LiveView socket stays open, it provides an amazing opportunity to provide such feedback, with minimal drawbacks.

There is of course variance involved in various ways, but a decent implementation can account for it. It also relieves developers of having to measure latency manually (which I do in my projects).

Showing Posts 1 to 6

chrismccord

chrismccord

Creator of Phoenix

Check the LiveBeats source. Latency detection is very easy to add yourself. I thought about adding it to LiveView, but you often will want to access the latency calc on the server as well (as we do in LiveBeats), so it’s better left to user land in my opinion:

11
Post #1
beepboop

beepboop OP

Thanks. That’s how I’ve done it so far :slight_smile:. It’s quite rudimentary and works, but with LiveView one could even predict page load time ahead of time with a slightly smarter approach. E.g. if you can predict a page load will take ~300ms, you can show a loader immediately, without delaying it. Delaying the loader in my view effectively just pushes the problem further back and only improves the experience for a subset of the users. Measuring latency with various payloads in LiveView can give you a very good signal for how long an action might take.

Of course, alternatively there could be some sort of a plugin for this, not sure in which form though. Just food for thought, as I happened to spot the PR.

chrismccord

chrismccord

Creator of Phoenix

Right, but you can do all this with the linked code above :slight_smile: I agree you can do all kinds of interesting things with average latency calculations over the previous X period. You could even do this for buffer/quality calculations for media streaming. To handle the prediction usecase you mention, all you need to do is store the average latency in a reachable javascript object, then reference that in your progress bar code to determine whether or not to display a loader. I’ve been meaning to write a blog post on this, but the LiveBeats code gets you 95% of the way there in like a dozen lines of code total.

gus

gus

Nerves Core Team

This is really useful! I’m measuring the latency to my Nerves device and it works great. My one question is, can I turn off logging for the “ping” event handler?

I created a live_session with hooks attached on mount to have the ping event handler on all pages within the session, as shown below. I really just want to remove the ping event from the logs, since it shows up once per second and Nerves doesn’t store a very large log history.

I did notice that in LiveView modules you can disable the log with some overrides in the macro: use Phoenix.LiveView, log: false. But I didn’t find an equivalent for hooks, or individual events for that matter.

Thanks!

defmodule FirmwareUiWeb.CommonHooks do
 alias Phoenix.LiveView

 def on_mount(_name, _params, _session, socket) do
   socket = 
     socket
     |> LiveView.attach_hook(:ping, :handle_event, &handle_ping/3)

   {:cont, socket}
 end

 def handle_ping("ping", _params, socket) do
   {:halt, LiveView.push_event(socket, "pong", %{})}
 end

 def handle_ping(_name, _params, socket), do: {:cont, socket}
end

defmodule FirmwareUiWeb.Router do
 use FirmwareUiWeb, :router

 # ...

 scope "/", FirmwareUiWeb do
   pipe_through :browser

   live_session :default, on_mount: FirmwareUiWeb.CommonHooks do
     live "/", HomeLive.Index
     live "/settings", SettingsLive.Index
     # ...
   end
 end

 # ...

end

And in the logs:

15:07:41.138 [debug] HANDLE EVENT "ping" in FirmwareUiWeb.SettingsLive.Index
  Parameters: %{"rtt" => 10}

15:07:41.139 [debug] Replied in 247µs

15:07:41.138 [debug] HANDLE EVENT "ping" in FirmwareUiWeb.SettingsLive.Index
  Parameters: %{"rtt" => 10}

15:07:41.139 [debug] Replied in 247µs

15:07:41.138 [debug] HANDLE EVENT "ping" in FirmwareUiWeb.SettingsLive.Index
  Parameters: %{"rtt" => 10}

15:07:41.139 [debug] Replied in 247µs
chrismccord

chrismccord

Creator of Phoenix

note that there has been a phoenix channels level (so phoenix.js) feature for socket.ping(rtt => console.log("rtt", rtt))

From LV you could do liveSocket.getSocket().ping(rtt => ...)

gus

gus

Nerves Core Team

Amazing, thanks for the quick response! That clears up my logs a lot :slight_smile:

For anyone else who wants a client-only ping hook:

Hooks.Ping = {
  mounted() {
    this.timer = null
    this.ping()
  }, 
  reconnected() {
    clearTimeout(this.timer)
    this.ping()
  },
  destroyed() { 
    clearTimeout(this.timer) 
  },
  ping() {
    liveSocket.getSocket().ping(rtt => {
      this.el.innerText = `Ping: ${rtt} ms`
      this.timer = setTimeout(() => this.ping(), 1000)
    })
  }
};
— All posts loaded —

Where Next? Top

Trending in Proposals: Ideas Top

a3kov
I recently learned about this API and was surprised there’s no explicit support for it in the the Phoenix. Example use cases: A webs...
New

Other Trending Topics Top

GenericJam
Edit: 2026 May 15 - This post is archived. Mob is alive!! Main docs: mob v0.7.11 — Documentation A bit of explanation for the slightly c...
New
JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
mhanberg
Hi everyone! The first release candidate for the Expert language server project is now available! We’ve published a press release detai...
New
budgie
A little off-topic, but I feel like people here have a good head on their shoulders. I used to be quite good at making software. Was luc...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews