Virtualmain panel has become heavy

Virtualmin
21

Haha, yeah :grin: some of us still stick to the old reliable ones!
While I know the J8 isn’t exactly powerful, it used to run Virtualmin fairly smoothly.
Recently, though, it’s started to struggle a bit more — so I was curious if recent changes might’ve impacted performance on older browsers or devices.
Appreciate you taking the time to check

22

Just a quick note to share that after switching to the Framed theme, the performance issues I was seeing on low-end devices are gone — everything runs noticeably smoother now.

With the default theme on the J8, there is a delay of about 10 seconds when opening the menu and also in the internal menus, and sometimes it becomes impossible to continue. This test was done with a full battery, when the phone is connected to the charger and the power mode is set to Optimized.

It might be worth considering a lightweight or performance-optimized mode in Authentic for broader device compatibility.

Thanks again

23

That’s expected, the Framed Theme has almost no JavaScript and almost no client-side complexity. It’s basically plain old HTML. Does a lot less, so it can do it a lot faster on a small client.

But, I don’t see performance problems with Authentic on my four year old phone, though it was a decent phone at the time (Motorola one 5G ace, which has 6GB of RAM and I think a quad core CPU), and looking at memory and CPU-usage on my desktop my Virtualmin tabs are much less resource intensive than at least half of my open tabs
much less so than, e.g. YouTube or Slack or GMail or Amazon. It feels like it’s gotten faster, actually, to me. I do recall finding it a bit sluggish on my phone in the past, but I’m not seeing it with the current version.

So, I dunno, seems like there must be something pathological happening on your phone..it’s two years older than mine and a bit less RAM, but I don’t see evidence Virtualmin would be more demanding than many other websites you’re likely to use, so I would think every complicated modern site would be slow, too. Certainly modern web design makes more demands of the client than traditional HTML websites, and that’s a trade off we should be cognizant of, but I think in this case, it’s a problem specific to something about your environment, but I can’t really guess what. We’d need to see some kind of web dev tools output to figure out what it’s spending so much time on, since we don’t seem to be able to replicate it.

2 Likes
24

Thanks Joe — really appreciate your thoughts and comparison.

You’re absolutely right about Framed being minimal and faster by design. I also agree that newer phones with better specs seem to handle Authentic just fine — in fact, it performs okay on my newer tablet as well.

It’s just that the jump in client-side usage between versions surprised me, especially for older but still capable devices like J8. I’ll try digging deeper with the browser dev tools to see what exactly is causing the spikes during menu interaction.

Thanks again — I totally get the trade-offs modern UIs bring, and I appreciate your input.

25

Hi @Ilia and @Joe,

Just an important note — I tested the older version authentic-theme-23.03.1 on my server, and the interface now works significantly smooth, even on my older phone (Samsung J8).

It seems the recent performance issues I experienced may be related to newer versions of the theme.

Hope this feedback is helpful for your ongoing improvements.

26

Do you see it on all pages or just specific ones?

2 Likes
27

Thanks for your response @Ilia

The issue I faced was primarily with the left-side navigation menu. In newer versions of the theme, tapping the menu icon often led to a delayed or unresponsive reaction, and even when the menu did open, the items were either very slow to load or didn’t appear at all.

After switching back to version 23.03.1, both the menu toggle and item display began working smoothly and instantly — even on my older phone (Samsung J8).

Later, I did more testing and discovered that resetting the theme to default settings and clearing the theme cache resolved the issue in the latest version as well — despite the fact that my only customization was enabling dark mode.

It seems the problem wasn’t necessarily caused by the newer theme itself, but likely due to cached data or a minor configuration conflict.

Hope this feedback helps with troubleshooting or improving future releases.

1 Like
28

Just a general, vaguely related question. In the early days coders used to be forced to write compact efficient code. As hardware advanced this was less an issue so coding got a tad more bloated. Has the use of phones made a difference?

Disclaimer. I hate ‘smart’ phones and rarely do more than make calls and a few texts on mine. I always get cheap phones and using them is pretty much like being on dial up. :wink:

1 Like
29

Totally fair — I use a desktop 99% of the time. But here’s the thing: as a server admin, I can’t always count on being at a PC when an issue hits.

That’s exactly why testing on low-end phones matters — they expose real UI regressions that might be invisible on desktop.

Plus, admin panels like Virtualmin are inherently modular and heavy (built on Webmin and featuring stats, DNS, mail, Apache controls, etc.), so optimising for minimal load is not just a bonus — it’s practical.

In short: desktops are great — but admins often rely on whatever’s closest. Panels should be snappy even on cheap phones. :wink:

30

If you disable real-time monitoring on the “Theme Configuration: Dashboard and real-time monitoring” page and fully refresh the page, does it change anything for your Samsung J8?

1 Like
31

If it does work better, did you change the default period for storing stats?

1 Like
32

Hi @Ilia

I’ve completed testing all three real-time monitoring settings, and here are the results:

  • 1. Yes and store state for 20 minutes (default):
    Slow menu behavior and increasing lag over time.

  • 2. Yes without storing stats:
    Same as above — no noticeable performance improvement.

  • 3. No (disable real-time monitoring completely):
    Significant performance boost. Menus and dashboard load quickly, and the interface remains responsive even after extended use.

These results suggest that the real-time monitoring feature itself — regardless of the “store stats” option — is a key factor in performance issues on low-end devices.

Additionally, I found that Firefox performs noticeably better than Chrome or Edge when using Virtualmin on Android (Samsung J8). It handles the UI more smoothly under the same conditions.

Please let me know if you’d like me to test anything further. If needed, I can also share browser DevTools logs or other diagnostics to assist with investigation.

33

I’m thinking about how we could address it
 For instance, we could run a small benchmark test on initial load, setting a slow mode flag and not opening background socket connections on those devices.

Try creating a small bench.html file on one of your domains and add the following JavaScript into it. Then open it on your mobile device:

<div id="perf-result">Checking performance...</div>
<script>
  (async function potato() {
    // Basic hardware signals
    const ram = navigator.deviceMemory ?? -1,
          cores = navigator.hardwareConcurrency ?? -1;

    // Simple benchmark
    await new Promise(r => setTimeout(r, 25));
    let sum = 0;
    const N = 1_000_000,
          start = performance.now();
    for (let i = 0; i < N; ++i) {
      sum += Math.sqrt(i % 100);
    }
    const time = performance.now() - start,
          isSlow = (ram <= 2 && ram !== -1) || cores < 4 || time > 50,
          output = `
    <p><strong>Benchmark time:</strong> ${time.toFixed(1)} ms</p>
    <p><strong>RAM:</strong> ${ram} GB</p>
    <p><strong>CPU cores:</strong> ${cores}</p>
    <p><strong>Slow device:</strong> ${isSlow ? 'Yes' : 'No'}</p>
  `;
    document.getElementById('perf-result').innerHTML = output;
  })();
</script>
1 Like
34

Ah, yes, I too disable realtime stats on the dashboard on low end Virtualmin systems.

I should have mentioned that in my earlier comment.

1 Like
35

We could make it automatic, though.

Anyone reading this, try the test on your mobile devices and let me know the results you get. Don’t forget to mention the device name.

1 Like
36

I tweaked the code so it doesn’t mark the device as slow when the RAM can’t be detected, which can only happen in Chromium-based browsers.

1 Like
37

Benchmark time: 41.2 ms

RAM: 4 GB

CPU cores: 8

Slow device: No

This is the result on a Moto G30 connected via VoLTE to a low end Virtualmin systems, vps01.indiax.com - the specs are mentioned in an earlier comment.

1 Like
38

Thanks!

I made it simpler for everyone—just open this link, and report the results:

:chequered_flag: http://virtualmin.dev/benchmark.html

39

This is much easier to report. Thanks Ilia!

Device: moto g(30)

Browser: Chrome

Benchmark time: 23.2 ms

RAM: 4 GB

CPU cores: 8

Slow device: No

2 Likes
40

Cool, thanks @calport! Let’s see what others report. I assume we can just use a simple test: if CPU cores are 2 or fewer then device is slow. I really wonder what @asadister reports back.