BUG - WebGui and not compress js files and other resources
-
Yes accesing remotly, wan is 2mbit symmetric line.
Before compression 17seconds to load the main page. With compression 6 seconds.
Cpu utilisation less than 1% with gzip set at 6 as compression level;)
-
What widgets do you have?
Or are you talking just the login page?
-
After the login page. The main one. No widget enabled. Standard config of pfSense…
Even the login page is faster and all other pages are more faster...
-
Browser not caching?
-
I don't think it's caching…both chrome and IE have the same behaviour.
-
What specific change did you make in the conf? While I normally access the pfsense gui locally and its pretty freaking quick - be hard to tell if any speed up unless it was very drastic which I find hard to believe.. The current delays in the page "finishing" is all in the widgets, and the check to see if new version, etc.
But I do also access via vpn that has to take the long way around ;) Chicago to proxy in hou,tx or jax,fl back to chicago - so latency is high.. So I would be curious if your compression makes a difference that is of notice when doing that..
-
Added to this, what does this :
….nginx https://awesomediocrity.wordpress.com/2017/06/05/confine-webinterface-to-ssh-only-on-pfsense-2-4/ ...
it just explains, using 2.4 pfSense beta code, how to tunnel the the GUI access through a SSH tunnel. Tunneling will NOT accelerate things.
Checking out the 2.3.4 GUI nginx config, you will find out that CSS, javascript and other files are gzipped …
And what the heck is opnfense ? Another patch ?
Anyway. The GUI is a tool to set it up. When done, 99,99999 % of the firewall's live time you won't access it anymore.
I tend to say that the GUI is fast, very fast already. -
compressing wont have that kind of benefit, whilst 2mbit is not fast its not dialup either. HTTP compression was invented in the dialup era when it did actually make a difference.
Things like the javascript code sent to your browser is a small amount of data, which a 2mbit line will handle without a sweat unless maybe that line itself is extremely saturated somewhere.
Many webservers do still compress content, but this is out of stuck standards and google's recommendation to developers more than a actual technical need.
-
Added to this, what does this :
….nginx https://awesomediocrity.wordpress.com/2017/06/05/confine-webinterface-to-ssh-only-on-pfsense-2-4/ ...
it just explains, using 2.4 pfSense beta code, how to tunnel the the GUI access through a SSH tunnel. Tunneling will NOT accelerate things.
Checking out the 2.3.4 GUI nginx config, you will find out that CSS, javascript and other files are gzipped …
And what the heck is opnfense ? Another patch ?
Anyway. The GUI is a tool to set it up. When done, 99,99999 % of the firewall's live time you won't access it anymore.
I tend to say that the GUI is fast, very fast already.I wrote that the link is explainig how to make a config for nginx and not for the compression. Two different things!
Checking the gui of nginx you will find that is NOT compressed. I dont know where did you see this but the standard is compressing only css (period).
We all know what is the gui used for -
compressing wont have that kind of benefit, whilst 2mbit is not fast its not dialup either. HTTP compression was invented in the dialup era when it did actually make a difference.
Things like the javascript code sent to your browser is a small amount of data, which a 2mbit line will handle without a sweat unless maybe that line itself is extremely saturated somewhere.
Many webservers do still compress content, but this is out of stuck standards and google's recommendation to developers more than a actual technical need.
Yes of course but strangly google is compressing every single resource that is passing through http…
-
What specific change did you make in the conf? While I normally access the pfsense gui locally and its pretty freaking quick - be hard to tell if any speed up unless it was very drastic which I find hard to believe.. The current delays in the page "finishing" is all in the widgets, and the check to see if new version, etc.
But I do also access via vpn that has to take the long way around ;) Chicago to proxy in hou,tx or jax,fl back to chicago - so latency is high.. So I would be curious if your compression makes a difference that is of notice when doing that..
Gzip_types which is already there in the config. I added the mime types for other kind of resources
-
Checking the gui of nginx you will find that is NOT compressed. I dont know where did you see this but the standard is compressing only css (period).
I was comparing this part of the nginx setup with your finding :
... gzip on; gzip_types text/plain text/css text/javascript application/x-javascript text/xml application/xml application/xml+rss application/json; ....Then I found https://stackoverflow.com/questions/23939722/nginx-gzip-not-compressing-javascript-files : this explains what you are seeing - and what needs to be done ?
