No, that one is normal. You can see that it has a response code of 101 which means that it was an http(s) connection upgraded to ws(s) which is correct. Once that happens, the connection stays open for comms.
What you are looking for are either odd long gaps or oddly long responses in the timings of the other various resources being loaded.
If you look at the summary, I can see that the main page is taking around 2s to fully load. Which is reasonably long. There should also be a summary showing the overall stats:
I think there is indeed a problem. But I can't tell whether it is network or device problem. You appear to either have 5 connected clients there or the timeouts are causing Socket.IO to re-connect the single client with new socket id's (which I think is more likely).
You should never really be getting socket.io ping timeouts. It shows that either the socket.io server or the network cannot deal with the traffic. You might legitimately get transport errors if the client device or browser tab goes to sleep since that will make the client go away temporarily. When it wakes up, it will re-connect with a new socket id.
Which implies a memory leak probably. The server seems more than powerful enough, it is more powerful than my home server. Though you could try temporarily turning off the unifi controller if that is what you have running. That shouldn't affect your WiFi.
What is catcher.js? I don't see that on my example D2 page. It appears to be controlling the websocket. It is triggered from injector.js which I also don't see.
Please check what those js resources are and what they are doing.
How can I influence or configure the socket.io server as my (1GB) network is having lots of available capacity (I easily can stream several 4k videos at same time) and have as well done test with OpenSpeedTest and other bandwith tools.
I'm currently only running 1 browser to connect to this NR docker container and it is 1GB wired setup (no wifi) and dont understand why there should be 5 connects, so yes I think my single client is trying to reconnect
I have checked and connected the same broweser to another NR docker (with DB1) on same server but I do not see any socket.io issues ... there are as well no disconnect or unresponsive sessions with this NR docker and DB1
I'm not using wifi but wired 1gb network connect to connect to the NR docker with DB (but have done for testing purpose with same results
I dont know where those resulting from as I'm using the normal NR nodes and not aware which one is using catcher.js
Well generally, the only thing you want to change on socket.io is the max message size. But for D2, I'm afraid that I think it has any way to change settings on Socket.IO other than the max buffer/message size and connection middleware.
Right, you need to track down what those are. Any clues from the js files themselves? And where is that injector.js coming from? The network tab isn't showing it - if you click on that line and go to the resulting "Initiator" tab, it should show the thread of scripts that loaded it.
I tried with MS Edge and it has the same socket.io elements with the JS code. However in this it is not called catcher ... but highlighting a similar "SEND" command (this is for all socket.io events)
OK, well at least we've eliminated that as an issue.
I'm afraid that I'm stumped now though.
You're server seems more than capable enough and I assume you continue to monitor for memory, network and CPU issues. We've shown that it happens on different clients. So really, I think that leaves something in your ui_template code?
As an experiment, could you remove all input wires to all charts please and see if that affects it? I am concerned about the 86400 points you have on each chart. Even when it is not on screen the server still has to handle that data, though I don't see why that would particularly affect the loading of other pages. I still think it would be a worthwhile experiment. I am surprised the charts do not clobber the browser when they are on screen. Restart node-red so the charts are emptied.
i have disbaled all my chart-nodes, executed a full deploy and container-restart.
It is noe running for a few hours without any disconnect/deay or unresponsiveness but I will keep it running without any further change for at least 24h and report back
from static pictures to dynamic 
