Excessive history graph web browser cpu load: Blocking GUI!

[slandroe]

Checklist

• I have updated to the latest available Home Assistant version.
• I have cleared the cache of my browser.
• I have tried a different browser to see if it is related to my browser.
• I have tried reproducing the issue in safe mode to rule out problems with unsupported custom resources.

Describe the issue you are experiencing

I have a panel with around 20 graphic history plots, each with 1-6 curves. After recent history graph "upgrades", the cpu load for displaying this panel on both my PCs and my iphone has increased to a level such that any graphical interactions with this panel is now virtually impossible, at least without a very very high degree of patience! For the PCs this is the same with both Edge, Chrome and Firefox browsers, The new possibilities of zooming and panning may in principle be nice to have, but with a fair number of curves in a panel, the response is so slow that also these features become unusable.

I am also missing the ability to click on the curves to enter the history mode and select any desired time segment for display (although this is still possible by using the history tab). Although a bit more tedious, I have previously been using the history method for zooming. The advantage is still that this autoscales for the values within the displayed time range, whereas the new zoom method keeps the same autoscaled value range based on the full time segment, irrespective of the values within the displayed time range.

So could you, please, either fix the web browser excessive load issue, or alternatively offer an option for selecting the old history graph implementation!

It would also be good to get back the possibility to quickly get into history mode by some way of curve clicking.

Describe the behavior you expected

See description above.

Steps to reproduce the issue

1.Set up a panel with a sufficient number of history displays, see above.
2.
3.
...

What version of Home Assistant Core has the issue?

core-2025.2.1

What was the last working version of Home Assistant Core?

core-2024.12, I think, but I only got fully aware of the issue after the 2025.2.1 upgrade

In which browser are you experiencing the issue?

any browser, including iphone app

Which operating system are you using to run this browser?

windows 10 and ios 18.3

State of relevant entities

Problem-relevant frontend configuration

Javascript errors shown in your browser console/inspector

Additional information

No response

[silamon]

Have you tried in safe mode as suggested in the checklist?

"I have tried reproducing the issue in safe mode to rule out problems with unsupported custom resources."?

[mvdwetering]

I was going to report unresponsiveness when zooming with the new graphs, but this issue seem to match so adding the video I made here.

The video is running HA in safe mode and I have a dashboard with the 1 week overview data from the sensors in my airquality measuring device. Note that other graphs on other dashboards are also slow, not just these. I did not use zooming in the "old" graphs extensively, but when I did it just worked, nothing to complain about.

On a sidenote the loading of the graphs also feels slower, but got no numbers.

In the video it shows the devtools console (which stayed empty), the chrome "task manager" showing memory and CPU of the tab and the dashboard itself. I put some annotations in the video of what I am doing.

Hmm, uploading the video here fails for some reason, uploaded to YouTube instead https://youtu.be/kPJq7CalTUg

Edit: When zooming I use CTRL + mousewheel

[MindFreeze]

Is this a single card with many entities?

[mvdwetering]

Yes, it has the 6 sensors of the device and a reference temperature sensor (ow and it is 10 days, not 7 I see now).

type: history-graph
entities:
  - entity: sensor.awair_element_94033_score
  - entity: sensor.awair_element_94033_temperature
  - entity: sensor.slaapkamer_sensor_temperature
  - entity: sensor.awair_element_94033_humidity
  - entity: sensor.awair_element_94033_carbon_dioxide
  - entity: sensor.awair_element_94033_vocs
  - entity: sensor.awair_element_94033_pm2_5
hours_to_show: 240
grid_options:
  columns: 36
  rows: auto
min_y_axis: 0

Edit: If I only keep 1 sensor it is better, but still far from interactive.

[dpgh947]

I have hit this, and I have found the following strange behaviour: I had the chrome browser window and the chrome task manager window side-by-side so I could see what cpu was being used where. I have found that if I click anywhere on the browser window so that it is the active window, and then try to zoom a graph, the cpu for that tab goes up well over 100 and the tab locks out for several seconds until it recovers. But if I click on the task manager window so that it is the active window, and then move the cursor to a graph and zoom without clicking, so the browser is still NOT the active window, the zoom works and continues to be responsive.

This is absolutely 100% reproduceable. I am using CTRL+mouse wheel to zoom.

UPDATE: in fact, you don't even have to zoom. Just holding down CTRL while moving the cursor around so the tooltip updates causes the same thing. If the "other" window is active, it works. If the browser window is the active one, it locks up.

ANOTHER UPDATE: Exactly the same behaviour in Edge browser - if the browser window is the active one, it freezes. If another window is active, it works.

[ildar170975]

Is it possible to switch off this animation?
Or is it not an animation - but just a slow processing?

That GIF was made in a "not-safe" mode - but absolutely same happens in safe mode.
Before 2025.2 the graph was drawn instantly.
This is a sensor which changes every 30 sec.

Note: I am not saying that "graphs are blocking GUI", but graphs are definitely drawn slower, it is more visible on weak clients (like iPad Air 2 with iOS 15.x).

[dpgh947]

I have narrowed down this behaviour even further. I have now found that if you only have ONE graph visible on the HA view, zoom works. If there are any other graphs on the same view, when you hold CTRL while moving the cursor around on a graph or try to zoom, it locks up.

UPDATE: Right, the above is not quite correct, the problem appears if there is a history graph card on show, whether that is the graph being zoomed or not. This is hard to explain but bear with me:

If I put a history graph card on a view on its own, it exhibits the lock up behaviour when zooming or just holding CTRL and moving the cursor around. If I put an entity card on a view by itself and then click on that to open the history graph in the entity settings, manipulating that graph works perfectly. If I put the history card and the entity card on the same view, and then click on the entity again to bring up the graph in the settings for the entity, I get the lockup behaviour.

Zooming elsewhere, for example on the energy display, also works perfectly. So it seems the lockup behaviour is triggered simply by having a history graph card on the view you are on, even if the graph you are trying to zoom is not being produced by a history graph card.

[MindFreeze]

@dpgh947 Very good investigation. Thanks to your explanation I think I know what the problem is. Will have a fix soon

[MindFreeze]

Turns out what I thought is just a small part of the problem. The main issues are:

• echarts does a full render for every option change and we manually change options to enable/disable zoom if the modifier key is pressed. Mainly because echarts doesn't support cmd on mac. Maybe we can use ctrl on mac as well
• when any sensor in a history-graph-card is updated, we receive a new data object for all the sensors and re-render all the charts in that card at the same time. This can block the UI when there is a lot of data.

I will keep working on this but for now I would advise to split your charts into 1 chart per card so they don't trigger unneeded updates in each other.

[slandroe]

In the mean time - would it be possible to add an option to use the old history graph method, or possibly reinstate the old history graph as a separate panel option - maybe with a sligtly different naming?

[MindFreeze]

Sorry, we can't bundle 2 graph libraries into HA

[f-fritz]

I had a sensor on my 24h history graph card that updated its value every second which made the entire dashboard very unresponsive like described above. Using a time_throttle filter sensor as a proxy solved the problem for me but I understand that might not be an option for everybody.

So far, I'd probably prefer the old history graph card over the updated one as well.

[cwitting]

I am also seeing this issue, especially with many plots with many entities per plot.
I also prefer the old history graph card as it just did its job.
Or at least have a way of configuring the history graph to behave like the old one.

[Eirik78]

Also have this problem both on desktops and in app. Different performing processors, but even the best ones cant handle this. resource usage is high and it locks up the interface. This card is not very useful after the last updates. The same problem also occur when open the more info for a sensor entity.

[MindFreeze]

@Eirik78 if a sensor causes this in more info, how often does it update and how long do you keep your recorder history (purge_keep_days) ?

[Eirik78]

@MindFreeze keep only 6 days. Slightly better performance on sensors only updating a few times every minute. But the point is that this was not slow until the graph card got its new features.

[MindFreeze]

The point is that in order to fix something we need to know what is causing it and I have only been able to reproduce this with unrealistic conditions.
Performance can and will be improved but constant complaining that we must never change anything is not helping.

[Eirik78]

Seriously? Complaining? Just pointing out that a recent change has caused problems not being there before the change. I haven't complained that there is upgrades, just made it clear it was no improvement. I'm sorry you had such a hard time getting that feedback. Well, I hope someone being able to repair this can give a hand.

[MindFreeze]

Was finally able to look into what Chartjs did differently before. As I suspected, they have downsampling by default while in echarts it is disabled by default. This is the main reason for the performance difference.
I will enable it but need to play around with the options to find good values.

[MindFreeze]

The above PR makes the new charts 2x faster than the old ones so this issue will be closed by it.
That said I found a few other inefficiencies that we can improve in the future. Like doing the downsampling in core instead of frontend and/or sending only the new data to the frontend instead of blasting the full history for all entities every time something changes.

[ildar170975]

@Eirik78

Slightly better performance on sensors only updating a few times every minute

I am curious, what kind of sensors do you use which have updates many times in a minute?

[cwitting]

@Eirik78

Slightly better performance on sensors only updating a few times every minute

I am curious, what kind of sensors do you use which have updates many times in a minute?

I do not think it is uncommon.

Most of my sensors update every 10 seconds, power, temperature, air quality, etc. Some every 5 seconds. I only have a few sensors which are slower than that.

[f-fritz]

@Eirik78
I am curious, what kind of sensors do you use which have updates many times in a minute?

Some third party sensors might provide updates at higher frequencies that cannot be modified by the user without interposing an additional processing or abstraction layer - unlike when building your own sensors like with ESPHome where the update frequency is a parameter.
For example, domestic energy meters usually publish a new state every second via SML. And I guess there are applications like network traffic monitoring, where you'd probably want intervals as short as possible because averaging could heavily affect the meaning of the plot.

It's not like one would specifically need that functionality in a home assistant dashboard. We rather commented this issue because it worked before the update.

[Eirik78]

I'm surprised that someone is surprised that there is sensors collecting data often. Most who have their electricity consumption, solar chargers, EV, heating, boilers etc incorporated in HA for supervising, control and automations have many sensors dumping in values almost realtime. Not all can be throttled, but that is neither a problem when the handling of the data does that.

So, now I'm happy to confirm that latest release resolves the issue for me. All back to how it was before. Thanks

[dpgh947]

I assume this is in 2025.2.5 ..... it seems better, but still poor if there's a graph with many entities on it on show. I have been working on converting some of mine to apex charts. It is not easy to make an apex chart that looks a lot like the stock history graph, but I'm getting there. This solves the scrollable legend problem too. A busy graph without a full legend on show is useless.

[MindFreeze]

I assume this is in 2025.2.5 ..... it seems better, but still poor if there's a graph with many entities on it on show. I have been working on converting some of mine to apex charts. It is not easy to make an apex chart that looks a lot like the stock history graph, but I'm getting there. This solves the scrollable legend problem too. A busy graph without a full legend on show is useless.

If it is still poor then it must be unusable with the old charts. Every benchmark I've seen says echarts is faster than Chartjs and my own testing within HA confirms it to be 2x faster after enabling down sapling.
The legend as we've said is not final and was quick patch. A new (again not final) design is already coming in 2025.3

[dpgh947]

I don't care about artificial bechmarks. We're not all making it up. It wasn't unusable before as you speculate, I never saw a hint of a problem before, now with several graphs on the view, or even just one with several entities on it, any attempt to zoom or just move the cursor around while holding ctrl still locks up the entire browser for several seconds. As for the legend, if a fix is coming then this update should not have shipped at all. Breaking something for a month or whatever is not a good way of upgrading and keeping people happy.

[MindFreeze]

So your issue is zooming? Do you realize the old charts only had zooming for about a month and it was broken?
I'm the one that added it and my fix for the most obvious bug was recently merged upstream into chartjs. It also had other issues though

[dpgh947]

I don't understand why you keep being so defensive. Of course I realise it's new, what's your point? I'm not the only person who had a problem, and I'm sure I won't be the only one to say it still isn't working fully after this latest release. I've just tried to help finding the problem, which apparently I did. I'll carry on with my alternatives now, I'm not interested in being attacked or just being told I haven't got a problem, or I must have had a problem before too.

[Eirik78]

I agree with @dpgh947 It looks a bit strange being arrogant and attacking those reporting problems. It only makes the person look like he lacks either skills or not fully able to understand other person's using the functions different or having a more advanced setup. It does at least not make the person superior of others.

Please let's go back to acting like adults and focus on the system and improvements.

[MindFreeze]

I don't understand how I attacked anyone but it was not my intention.
Was trying to explain the context and was genuinely surprised that we are talking about zooming specifically, as there have been a lot of statements of the type "it was better for 60 years and now it's ruined"

[nicois]

I have also seen a big slowdown in the last month or two with the graph rendering. It is not related to zooming, in that the load times in general were poor.

Reading the comments here, it does feel that the maintainer is reacting as though the user feedback is an attack, rather than intended as constructive feedback. For example , I don't think asking whether the old behaviour can be brought back warrants the response it elicited, whether or not it's viable.

Anyway I haven't tried the latest patch release, and I hope it improves things. In my case I have a key dashboard with 6 cards showing more or less the same data, over different timeframes, as I prefer this to zooming. If I could speed things up on this dashboard by disabling the zoom feature, or even all mouse interactions, I would do it.

[ildar170975]

rather than intended as constructive feedback

Perhaps because some comments are too demanding & too abstract like "revert everything back".
Why not contribute then to a FREE software...

[Eirik78]

@ildar170975 Where have you seen this behaviour here? All I can see is feedback from people explaining well what they experience, making it possible to investigate. That is contributing. Do NOT bring in dork-complaints and behaviour on a random Facebook group where the users do not even bother to find out where they can post issues or how to identify faults.

[ildar170975]

@Eirik78 Same "Where have you seen this behaviour here?" question should have been asked to you a bit earlier. Let's not continue spamming here.

[Eirik78]

@ildar170975 I agree. Let's stop when you're not able to answer for the accusation. Have a nice evening.

[natp13]

I'm still seeing GUI hangs with:

Core 2025.2.5
Supervisor 2025.03.0
Operating System 14.2
Frontend 20250221.0

Anything I can do to help get to the bottom of this? I have a page with 3 separate charts:

1. last 10 minutes
2. last 3 hours
3. last 12 hours

Each chart has the same two signals, which push an update every second.

[natp13]

I assume this is in 2025.2.5 ..... it seems better, but still poor if there's a graph with many entities on it on show. I have been working on converting some of mine to apex charts. It is not easy to make an apex chart that looks a lot like the stock history graph, but I'm getting there. This solves the scrollable legend problem too. A busy graph without a full legend on show is useless.

@dpgh947 can you share your apex chart workaround?

[dpgh947]

@natp13 ok, here is an example. It has zoom enabled and works and responds well. NOTE that if you experiment with this on a page with other "old" history graphs showing, you will still see a performance problem (well, I do).

Most of it should be fairly obvious, but there is a bug I found with having the zoom toolbar on show, it overlays the legend - I found that experimenting with the "offsetY" value lets you get it in to a better position. I haven't got mousewheel zooming working, but you can use click/drag, or the toolbar.

One other thing which might not be so obvious - the value coded on the yaxis min setting means a min value 5 below whatever the lowest plot point.

I have lots more values plotted but only included a couple here as examples. Have fun :-)

EDIT - I noticed this one has a default time span, you can alter with (for example) graph_span: 18h

type: custom:apexcharts-card
header:
  show: true
  title: Room temps
  show_states: false
  colorize_states: true
  standard_format: true
all_series_config:
  stroke_width: 2
apex_config:
  chart:
    height: 350
    zoom:
      enabled: true
    toolbar:
      show: true
      offsetY: 45
  grid:
    show: true
    borderColor: "#505050"
    strokeDashArray: 0
    xaxis:
      lines:
        show: true
  annotations:
    xaxis:
      - fillColor: "#f9f9f9"
        opacity: 1
      - fillColor: "#ffffff"
        opacity: 1
      - fillColor: "#f9f9f9"
        opacity: 1
  legend:
    position: top
yaxis:
  - min: "|-5|"
    max: ~35
    decimals: 0
    apex_config:
      tickAmount: 10
series:
  - entity: sensor.wiser_lts_temperature_lounge
    name: lounge
  - entity: sensor.wiser_lts_temperature_dining_room
    name: dining room

[dpgh947]

@natp13 this is how it looks

[KoalaBear84]

The new charts looks great, especially the new legend! Also zooming with CTRL is great, but it's not working as intended.

Core 2025.3.0
Supervisor 2025.03.0
Operating System 14.2
Frontend 20250305.0

I'm also still having issues with zooming. Especially when using CTRL I see, but also just zooming was impossible to work with in the 2025.02 release. Waited until 2025.03 to check if it's a common problem.

The current page/dashboard has ~10 graphs with 24H data.

Two zoom actions costs 4,676 ms of JavaScript scripting time and causing the whole page to block. Every keydown event, which happening multiple times per second, costs around 110-150ms of scripting, which is like 100% of the time because the keyboard will sent around 30 times a second. But 30 times 110ms does not fit into a second so it completely blocks the GUI.

Hmm.. or it's not the keydown perse, but 'mousemove' ?

More details:

A Performance trace:

Trace-20250306T074731.zip