How to throttle WebSockets and DOM refresh

[CaliViking]

First - thank you to bigskysoftware and the htmx team - this is truly a new way to build web applications.

Background information

I have built an application where the web server has access to live data and is sending data to the client on data change using WebSockets. Some of the data can change quite fast, so I aggregate and fold the data to reduce the load (this works fine).

When I send the data to the client, I put as many targets in the ws message as possible given the aggregation time window. Updating 100 targets every second seems to work fine in Google Chrome. I send all 100 targets in the same ws message. If I increase this to 1000 targets every second, then everything gets delayed. Again all the 1000 targets in the same ws message. The message length is 114KB for 1000 targets.

I understand that there is a limit to how much I can do, but I am struggling with making it degrade eloquently.

Here is the issue:

I can see the messages being sent from the server in a timely manner. Using the network inspect tool, I can see the messages arriving in the browser, but they arrive every 3 to 6 seconds. It looks like the remaining messages are queued and the buffer queue gets longer and longer, as the browser will continue updating after I stop the server. The UI in the web browser will now be lagging the data from the server. It can be lagging by a lot, more than 1 minute.

If I keep running both the server and the web browser client, then at some point the buffer queue must fill up, as the server is being blocked from sending more messages and slows down.

My questions:

I assume that sending a single message is better as the DOM can be updated all at once, is this a correct assumption?

Is it possible for the server to detect that the web client is behind? If I could do that, then I could throttle the rate of the packets, which would keep the web browser current (even though it is updating slowly).

Is it possible to determine what is causing the delay? It looks like the DOM is updated immediately after the message is shown in the ws inspector in Chrome, but the messages are delayed when they arrive. My guess is that this is a JavaScript performance issue, but I could be wrong.

How can I speed this up?

Thanks in advance,
~Niels

[CaliViking]

An update....

I found that I can use htmx:wsAfterMessage to detect that a message has been delivered and processed. I combined this with including a counter in the message that I send, extract that counter and send the message back to the server to indicate that I have received WebSocket the message.

This allows me to throttle how many messages and how much data I send to the client as WebSockets are stateful.

However, it brings up a new question. How do I structure the message that is sent over the WebSocket? Right now, I just put a fixed-length counter at the front of the message outside the content to be swapped, but it feels ugly. Is there a way to modify or manipulate the message before it is processed by HTMX? It looks like there are tools to modify the outgoing message, but not the incoming.