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).
Trending in Proposals: Ideas
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #ai
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming











Showing Posts 1 to 6- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
chrismccord
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:
beepboop
Thanks. That’s how I’ve done it so far
. 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
Right, but you can do all this with the linked code above
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
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_sessionwith 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!
And in the logs:
chrismccord
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
Amazing, thanks for the quick response! That clears up my logs a lot
For anyone else who wants a client-only ping hook: