I’m looking for some suggestions for how to start troubleshooting my HA frontend. in the last 3 months or so i’ve noticed that the frontend is extremely slow to respond. I’ve got some dashboards where you can see in real time as each card gets rendered and added to the dashboard. Also find that just clicking on buttons can take seconds for the click to be registered. This also applies to things like tapping on the hamburger button to open the side menu on the mobile app.
This slowness seems to occur equally on the companion app and a desktop browser. Its hard to say when it started happening, but I would say some time this year (but as I can’t pinpoint when i’m not sure if it was a HA release or a change I made).
Now i’m open to the fact that I might just be doing too much in the frontend (although I don’t think my dashboard is that complicated), but I have no idea where to begin troubleshooting or profiling the front end to try to understand whether there is a specific thing thats behaving badly, or if its just overall load.
Hi, on top of tom’s tips you could create a new empty dashboard and copy your cards 1 by 1 to see if it’s because of cards used - which might be the case since you have the same behavior on your desktop and mobile.
Tip: copying can be quite easy if you put 2 sessions side-by-side and copy the YAML code from one dashboard to the other.
With slow performance, it would be good, as a starter, to check your network.
You did not ( as many others) specify, whether it’s over Wifi, i assume your companion is, but how about the desktop-browser ?
All traffic over wifi will have a huge impact upon how you perceive the performance of HA, it’s enough the you plug-in a bad/broken/old device which runs on i.e WIFI-g, can actually even happened that the “performance” drops to WIFI-b
A WIFI network aint faster than the slowest link ( in common )
Well to be honest, i have also noticed “some” unexplained “slowness” lately, and seems others have in few other Topics.
And as you mentioned rendering of View/Cards, and some button-actions, for me, in specific wifi-switch>wifi-light … Zigbee seems not affected
This gave me to understand that you don’t experience the same behavior on all your dashboards, hence my advice.
If you wrote that this slow response occurs on all your dashboards I would not have come up with that idea.
I have also noticed this suddenly today, not sure if this is the case after 2023.4 upgrade because I have done a few changes. My RPi is sitting low in cpu and memory. Before my dashboard load was instanteneous now I can see cards loading one by one in a matter of approx. one second, which obviously is not an issue, just not as neat and I am wondering what happened.
So after another update today to 2023.4.1, everything seems normal and fast again. I can’t see any fixes to this mentioned in the release notes, but hey, it works.
By way of another update, I’ve managed to improve things a bit more. I ended up having to crack out the javascript debugger to try to work out what was going on, and I was able to track down a couple of things.
I had cardmod loaded (but not actually in use). I found that cardmod related code seemed to be consuming a fair bit of cpu time for no apparent reason.
The second thing I found (someone else steered my towards it) was my use of auto-entites. It would seem that auto-entities subscribes to all events on the message bus (which makes sense for how it works). so with multiple auto-entities cards on a page, each one was processing every event. I’ve slowly been removing them and am finding performance improving as I go.
Its still not where I want it (or where I think it used to be), but it is slowly getting better. Just been frustrating that there doesnt appear to be a lot of instramentation available on the UI side as there is on the server side.
No not really sorry, not that I found anyway. I just kinda fumbled my way around, primarily looking a the flame graph and associated stack trace to try to work out what was burning CPU cycles.
So to close out the story (and for anyone else who has the same problem) I should add that I did finally get to the root cause of the problem, and it wasn’t the UI or lovelace or any cards.
It took me until about 2023.6 or .7 to notice that my known_devices.yaml had grown to a very large size. Around 9mb with some 86000 odd lines. Turns out somewhere at the start of the year I had turned on the ble device tracker (as a part of some other testing) and left it on, and apparently in that time it had tracked a lot of devices. I renamed the file to effectively remove it and rebooted, and low and behold the performance came back to where I expected it to be.
I am unclear on why exactly it was causing a problem, given there weren’t 1000’s of devices in the device registry, and there wasn’t a high volume of messages on the websocket. But when I removed it the difference was night and day.
Just for clarity, you had the same slow UI problem?? And was it solved by removing your known_devices.yaml?? And if so, do you know why you known_devices.yaml was so large?
Yes, exactly the same issue: unexplicable slow UI. And exactly the same cause.
I spent days looking into all directions on HACS frontend components that could have gone wrong, and also on template sensors. Ultimately the issue came from the 260k lines in known_devices.yaml, I assume 95% of them appeared since I played with ESP32’s BLE scanner some time ago, so it was only about (unused and unknown) BLE devices.