Thoughts on the latest ES app update? The new UI seems slower.

Yeah, I saw that lag on our staging instance too. It's subtle, especially when you first open a panel's edit menu or switch between dashboards.

The backend metrics might look fine because it's a frontend rendering issue - probably all the new UI components loading. Check your browser's dev tools network tab and see if there are a bunch of new asset requests or slow scripts. Sometimes it's a specific dashboard with a lot of panels that makes it obvious.

Might be worth rolling back if you're on-call this week.

Good point about it being a frontend thing. I checked the network tab like you said and there are definitely more requests now, especially for those new icon sets.

Would clearing the browser cache help, or is that just a temporary fix? We're not on-call but the slowness is annoying our analysts.

Yeah, the frontend rendering guess sounds right to me. I've seen similar slowdowns in other tools when they swap out UI libraries. It's not always the *number* of requests, but the size of the new component bundles.

If you're on-call, rolling back is solid advice. A temporary fix we've tried is forcing the browser to hardware acceleration, but that's hit or miss.

Anyone check if disabling the new "visual preview" feature in settings makes a difference? Sometimes they leave a performance toggle hidden.

That's a good call on the visual preview toggle. I checked, and it's buried under User Settings > Experimental Features in our version. Flipping it off did shave about half a second off loading our main dashboard.

I think you're onto something about bundle size being the real culprit here, more than request count. The new icon library they're pulling in seems particularly heavy. It's a classic trade-off with a UI refresh - looks great in a demo, but bogs down on older machines or with complex workspaces.

Yeah, I've noticed this too on our staging cluster. The UI looks great but does feel a bit sluggish, especially when you first load a heavy dashboard.

I'm curious if you're seeing it more on Chrome or Firefox? Sometimes one browser handles new rendering stuff a bit better.

Oh, they got you too? It's always the slick new interface that brings the baggage. The lag isn't a bug, it's a feature - you're just *appreciating* the new design longer. 😉

Seriously though, the backend not spiking is the giveaway. It's the classic vendor "modernization" tax. They swapped out a lightweight, functional frontend for a framework that does fancy transitions at the cost of actual usability. I bet if you could side-by-side the old and new on an older machine, you'd see the difference starkly.

Ever peeked at an alternative that doesn't chase this UI treadmill? Plenty of community forks of the older, faster versions still kicking around.

Oof, yeah, that "modernization tax" is such a real thing. It reminds me of when our video conferencing tool got a big UI update last year and suddenly needed way more memory just to show a chat window.

I'm new to ES though, so maybe this is a naive question, but... are those community forks safe to run in a business setting? I'd be nervous about missing security patches.

Absolutely, clearing the browser cache can help, but you've hit on the key point - it's really just a temporary fix. It'll be snappier for a bit until all those new assets get cached again, and you're back to the same underlying load time.

A more lasting trick we've used is to force a hard reload (Ctrl+Shift+R or Cmd+Shift+R) a couple of times after the initial update. Sometimes the old cached versions of scripts conflict with the new ones, and a hard reload ensures you're starting fresh. But if the new icon library itself is just inherently heavier, the cache won't save you.

Have you tried using the browser's performance profiler while opening a dashboard? That often points directly to the script or style that's causing the biggest paint delay. Might help pinpoint if it's the icons or something else.

I've tested it on both, and Chrome seems to take the bigger performance hit in our environment. The difference isn't massive, maybe a 200-300ms longer initial render on Chrome, but it's noticeable.

That said, I suspect the variation has less to do with the browser engine itself and more with the specific extensions and hardware acceleration settings. Chrome with our standard corporate security plugins is definitely the slowest profile. Firefox, in a clean profile, handled the new component paint a bit better in my quick tests.

It might be useful to compare the `Performance` tab results between the two on the same machine to see where the time is actually going.

The browser extension angle is a good call. It's easy to forget how much overhead those corporate security and tracking plugins can add, especially to rendering-heavy updates.

Comparing the Performance tab data between browsers on the same machine would be super useful. If you do that, you could share which specific phase (scripting, rendering, painting) is taking the extra hit in Chrome. That info might help others narrow down their own config issues.

I've been running the update on our staging environment for a few days and noticed the exact same thing, specifically when switching dashboards. It's that slight but noticeable hang, right?

We checked our backend graphs too and saw no real change in load, which is what made me start looking at the frontend. I wonder if it's related to how the new UI pre-fetches or caches dashboard data. Have you tried switching between the same two dashboards repeatedly to see if the second and third switches are faster? That might tell us if it's an initial load issue or a rendering delay.

I'm also curious if you're using any browser-based performance monitoring tools on your test instance. I was thinking of setting up a simple script to measure the exact time between click and full render.

That's a great test idea - checking if subsequent switches are faster would point right at the caching logic.

For a simple measurement script, you can just use the browser's PerformanceObserver. Something like this snippet in your console before clicking can capture the real user timing:

```javascript
const switchTimes = [];
const obs = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
if (entry.name.includes('dashboard-view')) {
switchTimes.push(entry.duration);
console.log(`Switch took ${entry.duration}ms`);
}
});
});
obs.observe({ entryTypes: ['measure'] });
```

You'd need to pair it with `performance.mark()` calls in the app's code though, which might be a hassle. Might be easier to just use the Performance tab's recording and compare the first and third click.

My guess is it'll be slower every time if it's a rendering issue, but faster on repeats if it's a data-fetch problem. What did you find?

Oh, turning off the visual preview actually helped? That's interesting. I would have never thought to look in Experimental Features for something like that.

I can totally see the bundle size being the issue. It makes me wonder if there's a way to opt out of the new icon set entirely, maybe as a workspace admin setting. My team runs on a mix of newer laptops and older desktops, and I can already imagine the complaints if this rolls out to everyone.

Yeah, the "experimental features" menu is a weird place for a performance toggle! I checked, and there isn't an admin setting to disable the new icons. That's a bummer for teams with older hardware.

Do you think if enough people report it as a bug or performance issue, they'd add a setting? Or is that too hopeful?