"A web page is slowing down your browser" - PiHole web dashboard unusable in Firefox 78.0.2

[cricalix]

In raising this issue, I confirm the following: {please fill the checkboxes, e.g: [X]}

• [X] I have read and understood the contributors guide.
• [X] The issue I am reporting can be replicated.
• [X] The issue I am reporting isn't a duplicate (see FAQs, closed issues, and open issues).

How familiar are you with the the source code relevant to this issue?:

1

---

Expected behaviour:

Responsive loads of charts on the dashboard; nagivation clicks not blocked by the chart loading

Actual behaviour:

Spinners on the charts, nagivation clicks blocked by chart loading, Firefox informing me that the page is causing the browser to be slow and offering Stop/Wait.

Steps to reproduce: Unknown. Performance of v5 was initially fine; mtime says I installed this version on June 1st. Haven't looked at it for several weeks, and now find that it doesn't work well. Every other page is fine, it's just the dashboards page.

Debug token provided by uploading pihole -d log:

https://tricorder.pi-hole.net/cge4o8bgv5

Troubleshooting undertaken, and/or other relevant information:

/opt/pihole# ./update.sh
  [i] Checking for updates...
  [i] Pi-hole Core:     up to date
  [i] Web Interface:    up to date
  [i] FTL:              up to date

  [✓] Everything is up to date!

Captured a performance profile. script_causing_slowness.zip

Total queries always loads. It's the other charts that fail to load properly.

Server-side load is negligible.

Impact of this issue is bad enough to cause the Firefox developer tools to take 10+ seconds to load, instead of the instant load normally experienced. Javascript issues?

Network requests stop when the perf trace goes idle. There's a 1 minute, 32 second delay (if I keep clicking Wait) between a ?summary XHR and ?getQueryTypes XHR. HAR file of transaction included.

192.168.0.53_Archive [20-07-13 07-46-20].har.zip

[cricalix]

Worth mentioning that whatever spin Firefox is being put in to, it means it takes up 30% of available CPU time according to task manager, and it's enough to cause my CPU fans to spin up to an audible level. Normally only games/CAD will cause my CPU fans to become audible.

[yubiuser]

Do you have any browser addons that might interfere with the side?

Can you replicate it in another browser?

[cricalix]

Tried Chrome (which has no extensions), same issue.

Tried Chrome-based Edge (which definitely has no extensions), same issue.

[PromoFaux]

Please can we get a debug token (pihole -d from the CLI), and also if you see any errors in the developer console on the browser, a screen dump of those would be good.

[cricalix]

A debug token is already in the initial report. There are no console errors.

[PromoFaux]

Whoops, sorry totally missed that!

[PromoFaux]

OK, debug log looks clean, there is an error in the lighttpd error log, but that is for pihole/index.php, which is a different page... so not that.

This is odd. I note you also have nginx listening on 7022. Presumably that is for something else entirely, and you're not accessing the web interface via :7022 ? Just trying to rule things out here

[cricalix]

Yep, that's the Ubiquiti UniFi controller; can't fathom how that would cause the browser to spin hard for ~90 seconds before loading the rest of the charts. To be sure, I just shut down the unifi controller and nginx, loaded the dashboard page, and watched the spinners occur.

[cricalix]

Huh. The ancient tech support query of "Have you turned it off, and back on?" has resolved the issue. Restarted the Pi that this is running on, and the charts loaded instantly once it was back up.

[PromoFaux]

Yep that's fine, my main query around that was whether you were using nginx to access the web interface on 7022, rather than accessing it via lighttpd, but if you are accessing via :80, then we can rule that out.

(Reason that is relevant is that sometimes we see people that prefer to use nginx or apache2 instead of the shipped lighttpd configuration - and in these cases it's as simple as a missing php package)

I'm stumped, I must say. What kind of numbers are we looking at for queries? As an absolute estimate from the info provided in the screenshot, I'd say you're hovering around 30,000... which shouldn't cause things to fall over.

[PromoFaux]

Ah, I didn't see your reply before I commited my reply then....

What hardware are you running on? Debug log only says arm7l, not sure what Pi model that translates to!

[cricalix]

Pi3B+ I think, 1 GB RAM.

Should have checked free before rebooting, but there's no sign in /var/log of ooms or anything else that might be indicative of memory pressure. Also wouldn't explain why once the charts loaded once, they would then take 90 seconds again to load on a browser refresh; if it was memory pressure, the relevant pages should have been swapped in, unless it was really suffering and promptly swapping everything back out.

[cricalix]

And the problem is back! Load on the pi is minimal (0.08 or so), using 1 MB of swap. Watching with htop, there's no major activity when the browser refreshes. Interestingly, doing a pihole upgrade (5.0 -> 5.1.1) doesn't resolve the problem completely. It's still slow to load the graphs right after the update.

More interesting - a reboot doesn't fix it. Graphs are still taking 20 seconds to load after a reboot, with the "slow script" banner kicking in at 10 seconds.

[ehb224]

I have been having the same issue with Firefox. Chrome give me error box that says "Page Unresponsive. You can wait for it to become responsive or exit the page. Pi-hole - raspberrypi". Edge displays error boxy that says "This page isn't responding." and gives an error code of "result_code_hung" when I exit the page.

[ehb224]

I have discovered that if I sign in to the settings page and then flush the logs I can access the dashboard.

[shadow00]

Same issue here, running PiHole inside an LXC container on a VPS (2 cores, 2GB ram total). If I reboot the container or the host the dashboard loads quickly again, but after a while it grinds down to a halt and I get the same warnings about a script slowing down the page. Not sure if the problem started on version 5.0 or 5.1, but I am certain it used to be fine on 4.3.3 running smoothly for weeks without a hitch. Perhaps some bug in the code that parses the logs?

[ehb224]

The issue started for me with 5.0

[dschaper]

Things like debug tokens really help us. Otherwise we're just blind and you'll not get any response from the developers.

[shadow00]

I'll try to provide a debug token when the issue arises again. Right now it's running fine again since I rebooted the vm just a few days prior.

[daprice]

I was able to reproduce what I think is the same issue in MacOS Safari and take a timeline recording. It looks like when the function updateClientsOverTime in index.js calls clientsChart.update(), the update method from Chart.js does things that take a long time to run (~5s on a relatively powerful machine) and blocks the main thread.

Here’s a debug token: https://tricorder.pi-hole.net/3zyqihd69l

And the timeline recording with call trees (can be unzipped and then imported into the Safari web inspector): pi.hole-recording.json.zip

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.