liveview a bit delay on render/page refresh

Questions / Help
,
1

Hi! I cant pinpoint what’s the reason for another <1sec delay for page refresh of a liveview (is this normal?). It seems quick or should i say snappy in localhost (obviously), even though postgres is living in the same instance with the app.

Example 1 flystaging.nappy.co:

  • Deployed in fly
  • App and managed db (same region) vs localhost.
  • Every page refresh is noticeable unlike in my localhost.

Example 2 dev.nappy.co:

  • Deployed in vps (e.g. linode)
  • App and db in the same instance vs localhost.
  • Still the same delay as above.I really don’t know where’s the delay coming from.

Both of these examples are scaled up. Is this because of the initial double request of http + websocket connection?

2

What do the following commands show? (use your app names)

$ fly status -a myapp

And the db app:

$ fly status -a myapp-db

This way we can verify the web and db instances are running in the same regions. Thanks!

3

Hi @chrismccord here’s the output (both in Dallas):

app

App
  Name     = nappy-staging
  Owner    = nappy
  Version  = 4
  Status   = running
  Hostname = nappy-staging.fly.dev
  Platform = nomad

Instances
ID      	PROCESS	VERSION	REGION	DESIRED	STATUS 	HEALTH CHECKS     	RESTARTS	CREATED
48d903a0	app    	4      	dfw   	run    	running	1 total, 1 passing	0       	21h13m ago

db

App
  Name     = nappy-staging-db
  Owner    = nappy
  Version  = 4
  Status   = running
  Hostname = nappy-staging-db.fly.dev
  Platform = nomad

Instances
ID      	PROCESS	VERSION	REGION	DESIRED	STATUS          	HEALTH CHECKS     	RESTARTS	CREATED
97c1636e	app    	4      	dfw   	run    	running (leader)	3 total, 3 passing	0       	21h15m ago
4

Sorry I misunderstood your first post that your fly deploy was showing more latency than DO, but you are saying they are both showing it and asking about LiveView.

Just so I understand your question properly, what delay are you referring to? (the linked site is very snappy for me). LiveView will indeed make two round trips to the server when setting up the connected mount, but the “dead render” over HTTP will give you the same paint times as if you returned static HTML from the server. So there is an extra round trip worth of latency to established a connected LiveView, which then re-renders, but the end-user will still be served the content as soon as the first HTTP request completes. Are you perhaps referring to the time the loading bar (via topbar in your app.js is showing?). Thanks!

5

Thank you @chrismccord for clearing that up. Yes I’m referring to that extra latency for establishing a connection.