Your site will be even quicker if you let vBulletin store your CSS as external files. Then they can cache in the browser and you send less with each page request
Your site will be even quicker if you let vBulletin store your CSS as external files. Then they can cache in the browser and you send less with each page request
AdminCP > vBulletin Options > Style & Language Settings > Store CSS Stylesheets as Files? = Yes
Note that vBulletin needs to be able to write the files to the folder:
Quote:
If you would like to store the CSS stylesheet for each style as a file, you must ensure that you have a directory called 'vbulletin_css' inside the 'clientscript' folder, and that the web server has permission to write and delete files within that directory.
So you will need to create the directory is it doesn't exist, and then CHMOD the directory in question to have permissions something like 755 or 775 depending on how your Apache is configured. You don't want to CHMOD it 777... you never want to do that.
You can usually set permissions via FTP programs or SFTP... but it can always be done from SSH or Telnet
AdminCP > vBulletin Options > Style & Language Settings > Store CSS Stylesheets as Files? = Yes
Note that vBulletin needs to be able to write the files to the folder:
So you will need to create the directory is it doesn't exist, and then CHMOD the directory in question to have permissions something like 755 or 775 depending on how your Apache is configured. You don't want to CHMOD it 777... you never want to do that.
You can usually set permissions via FTP programs or SFTP... but it can always be done from SSH or Telnet
And yes, I realise that 664 is probably a better chmod... but you know... some servers I've been on are just lovely and hardened and prevent writing withour very specific chmod values... 755 and 775 being the most common two... so I was being lazy in giving execute too as this prevents people bugging me about something unrelated to the hack
The full version screws up nicely formatted posts when you edit them, so I have used the "lite" version which doesn't do this.
Yes, I think I'll switch them around and suggest the lite version for all... and then those who want the aggressive version can opt for that if they wish.
On average I've been witnessing it strip about 8% of total page bytes from every generated page.
We all GZIP don't we? The benefits of this is that all gaps between HTML become the same pattern, and so they compress better for GZIP'ing.
David, can you show me examples of your findings? I generally don't believe that the compression ratio is that much affected by the mere presence of whitespace. But of course I could be wrong
David, can you show me examples of your findings? I generally don't believe that the compression ratio is that much affected by the mere presence of whitespace. But of course I could be wrong
Hehe, that was a nice challenge, but one I enjoyed.
To offer a proof I've done the following:
wget my forum index.php both compressed using the now default non-aggressive regexp, and also without this hack applied.
The sizes of the two files:
37,732 bytes = Compressed file
41,348 bytes = Uncompressed file
A 9% reduction in filesize.
I then ran gzip from within SSH, this should be the same as PHP gzip'ing them or a close approximation thereof:
The additional reduction of the size is higher than merely the white space being stripped and is an indicator that doing this does offer a benefit to GZIP.
So the compressed page (exactly the same HTML but without white space) ends up being 20% lighter with GZIP'ing than the non-compressed page.
Of course, the mileage varies on every page and with each style that you use. I should point out that the above was run against my current forum homepage which is not the default vBulletin style and that I've hacked my page quite a lot. So the filesize of your page and the amount it compresses and the amount it GZIPs are all factors depending on your configuration and the amount of whitespace in a page, etc.
The worst I've seen from this hack is a mere 3% reduction in file size on some of the smaller pages (such as the error messages).
The biggest benefit isn't the saved 1k of traffic... but the speed at which the rendering increases. Whether that is because the file transfered quicker, of the DHTML engine didn't have to work so hard ignoring whitespace, etc... I simply do not know... but it does appear to render faster and that is my prime goal
Page Output Compression - Whitespace stripper. Details »»
About Developer
Visit Web Site
No support by the author.
09-25-2004, 11:47 PM
[/high]
