Why my web gui was slow to load.

[Alex the firewall]

I know why my WebGui is slow, makes sense that if you have the firewall logs on the dashboard it will slow the GUI down.. I watched the requests using the browsers debug console and in the code tens of times in my case because I had 5 interfaces worth of logs was the below, each one of those is a reverse DNS lookup. I removed the panel and the page load of 11sec has dropped to 488ms, thats 20x quicker.

<td>INTERNETOFTURD</td>
<td><a href="diag_dns.php?host=xxx.xxx.xxx.xxx"
	title="Reverse Resolve with DNS">xxx.xxx.xxx.xxx</a>
</td>
<td><a href="diag_dns.php?host=xxx.xxx.xxx.xxx"
        title="Reverse Resolve with DNS">xxx.xxx.xxx.xxx</a>:7000			</td>
</tr>

Leaving this here for others who might have the same Q's.

Peace

Alex

[Gertjan]

@alex-the-firewall

Nearly all 'webgui is slow' issues are really 'I have DNS issues'. Checking out the many 'webgui is slow' forum threads normally end with ..... nothing, as the author silently undid his previous DNS settings and doesn't erport back here, or are explained in the forum and then DNS is corrected.

After all, DNS needs to work for not only the pfSense WegGUI, but pretty everything on your local networks.
I mean, when pfSense default DNS settings get altered, its very possible that overall DNS functionality gets impacted.

Btw : most host names shown by the GUI are only known to the local DNS == the resolver or the forwarder. Resolving them doesn't produce any time taking requests to public resolvers. These public resolvers can't even resolve host names that are only known to your local network - they will try, searching through their billion records database, and give up by sending back a "we don't have what you are asking - unknown on the Internet", also known as a NXDOMAIN answer.

I advise you to do everything that is possible to reduce the number of restarts of the resolver (or forwarder). It will build a cache with previously resolved host names

Then you activate :

and after a while you enter 'DNS warp speed'.

These are some of my unbound/resolver stats.
Note that unbound can get restarted by, for example, pfBlockerng-devel (other events might also restart unbound/dnsmasq). The cache will get dumped just before the stop, to get read back in while it's starting.

Last but not least : the core functionality of pfSense, routing and firewalling, is build into the kernel. pfSense is more then that, and adds a lot of other options, functionalities and even gadgets. Most of these are implemented using some web server scripting like PHP, perl, python etc. So, all these take processor == webserver (nginx) time.
Depending the type of processor, and Intel Mega Lax Core isn't equal to some low power ARM processor.

Why did you add the waterfall download example of a zillion js files ? That's not DNS related.
That's just downloading those stupid js files that declare themselves most often as 'non cache-able' by your web bowser, to visiting these sites using these bootstrap js file will always be slow == depending your uplink/downlink.