Components would solve your issues in this case. The issue is we have to patch the entire LiveView DOM container for any change, and for large DOM trees, this requires traversing the tree as you alluded to. If you wrap the paragraphs in a component and/or the form in a component, it will allow LiveView to patch only those areas when they change, and also skip walking those areas when the parent LiveView needs to patch a DOM a non-component node that it owns.

It seems you are. LiveView does not process the resulting markup after assigns are interpolated. It only processes the templates. .leex templates are processed, so that static parts of the template are taken apart from dynamic parts. The dynamic parts also have dependency tracking, which allows to update only the parts, which actually depend on the data being updated.

<div class="<%= "foo" %>">

becomes something akin to (pseudo-code)

%{static: ["<div class=\"", 1, "\">"], dynamic: %{1 => %{depends_on: fn -> @foo end}}

where ["<div class=\"", 1, "\">"] can be sent once to the client and only the value of @foo is sent on updates.
… while

<%= raw(foo) %>

would be represented like this:

%{static: [1], dynamic: %{1 => %{depends_on: fn -> raw(@foo) end}}

where the whole raw(@foo) would be sent on each update.

If you now render a .leex template you don’t get back a plain string, but a struct, holding those details, where the runtime can now decide to send only the parts that matter to the client, significantly reducing the amount of traffic on the wire (imagine the above nested a few handful of layers).

Non .leex templates essentially result in the same unoptimized sending as the latter example.

Apparently I don’t need to do anything fancy. Setting a max height for the div did the trick.

Apparently the browser (Chrome anyway) is smart enough to know how to show a scroll bar the proper size for a div with a max height and can properly ignore all of the elements that are not in view, which brings down the time it takes to append down to 50-80ms consistently which is entirely within reason for me.

But you toss a div at the browser that doesn’t have a max height and is going to need to scroll it chokes because it cannot, for some reason, determine that most of the elements are not visible and so it does a ton more work. TIL.

Once I include batching of messages from the server side this will work perfectly well for my needs.

Thank you everyone for helping to expand my understanding and for helping me piece together where the issue was.