Board Optimization - United-Forum CSS Sprites - ludicrous speed - NOW!

tl;dr Makes your forum faster.

Want an easy one-click installation for this addon? . Vote for this jira-entry

Add on currently is in beta stage

When visiting a website, speed is a very important factor not only for users but crawlers as well. Long loading times are a nuisance since your time is basically wasted during the waiting period. Hence, we are trying everything we can in order to speed up our site. One great way to improve loading times is by the use of css sprites. Unfortunately these are not implemented by vBulletin.

We therefore decided to develop our own css-sprite add on for vBulletin boards and want to share this code with the worldwide vBulletin community.

Live demo

The add on is permanently running in our vBulletin board ( > 2.000.000 posts), take a look:
http://www.united-forum.de

The add on will be supported via this thread. If you have any questions, issues, improvements or feedback regarding this add on, please feel free to post a comment or write us a pm at any time. We are happy to discuss

vBulletin performance using css sprites

Our tests are based on version 0.7.0. We used the analytic tools firebug network utility and the googlelabs.com page speed site

on the client side the following parameter were used:
download speed: 5.7 MBit/s
ping: 31ms

css sprites - what are they?

The intention behind css sprites is the bundling of many small graphics into one large graphic in order to decrease the number of required http requests. This shortens the loading times of the given website. In addition, the the accumulated size of all small graphics is higher than the size of the sprite due to reasons of compression.
You can find further information in a great article by Chris Coyier.

What is the gain in using css sprites?

Aside from the technical implementation, the question on how much one actually does gain by using css sprites is of the most interest. Obviously they decrease loading times - but how important are small loading times and what is the impact on vBulletin overall loading times?

A short time ago, Jasper Aguila pointed out that speed is one crucial stickiness factor in his blog on vBulletin.com.

Originally Posted by Jasper Aguila vBulletin Support

The internet has unfortunately contributed to the exponential decrease in attention span for many individuals. That's why this decade is seeing a trend in emerging technologies emphasizing the importance of speed request. It's crucial for your content to be promptly distributed in a timely manner, else bounce rate will increase - making you lose returning visitors. It's also important to note that slow sites may be penalized by search engines.

With better browsers, more powerful processors, and improved technologies constantly releasing each year, it's becoming quite difficult to provide excuses for slow loading pages. Therefore, try optimizing your server for speed. Read up and learn optimization techniques at vBulletin.com's Server Configuration forum.

In addition, the google ranking is influenced by the site speed as well.

Google Webmaster Central Blog

Originally Posted by 09.04.2010 - Google Webmaster Central Blog

You may have heard that here at Google we're obsessed with speed, in our products and on the web. As part of that effort, today we're including a new signal in our search ranking algorithms: site speed. Site speed reflects how quickly a website responds to web requests.

vBseo Webmaster Mert G?k?eimam

CSS sprites is a huge bonus for big boards , any big board owner definately should use it.

Last but not least, not only the user's loading time is reduced, but also does the server load decrease as the server will have to handle a lot less of http requests. This clears available connections and cpu time.

Add on features

In the current released beta version 0.7.2, sprites are available for FORUMHOME and FORUMDISPLAY. Coming up next SHOWTHREAD.

Sprites are created style based for all forum styles and saved in a folder which you can set via the imgdir_sprite stylevar. You have one additional button in the ACP (CSS-Sprites -> Refresh) which automatically creates all sprites, the according css definitions and includes those css definitions in the vBulletin css rollup files.

Installation

First of all, if you didnt want to change the templates manually, install the Template Modification System (TMS). Now proceed with the installation:

• upload the contents of the upload folder into your forum home directory.
• import the add on in the ACP
• upon installation a new stylevar imgdir_sprite will be created. Update this stylevar based on your file structure - default value is the vbulletin sprite directory. Make sure the folder is writable, else the sprites can't be saved!
• create the sprites via the ACP at CSS-Sprite using the Refresh option.
• If you have installed TMS, you are done now. This was an easy gained speed up, not? If you didnt installed TMS and didnt want to do it, proceed with the next point:
• in order to use the sprites, you then will have to edit some templates. The diffs (xou will find it in the do_not_upload folder show which parts you have to delete '<' and which parts to add '>' In addition, on top find the lines in which you will find the respective code.[/b]

[Mooff]

You probably do not have GD installed on your server.

[giorgino]

Originally Posted by Osbes

Hello giorgino,
i haven't added anything in connection to the attachment-system in this addon, so i didnt belive, that this problem has to do anything with it.


as far as i can see, you are using nginx and vbseo rewrite for attachments? an am i correct, that you problem is, that attachment-urls like http://www.propit.it/attachments/f66...-.4.09-005.jpg resolve into an 404 error? since our forum use nginx and vbseo too, i think i can help you anyway.

vbseo will rewirte the url of yout attachments to something like "attachments/f66/372d1280162113-firma-nostro-libro-ospiti-stlegdv14-1-1-.4.09-005.jpg". in our nginx configuration, nginx deliver jpeg directly and doesnt check each time if they exists, so it could use vbseo if it didnt exists.
since we didnt wanted to change this behavior of nginx we drop the rewrite of attachments with vbseo. hope this could help you.

Best regards
Sebastian

Hi Sebastian you're right. We've nginx with some difficult in configuration... (cry).
I don't understand your super nice help (my english is really poor, sorry for this) and I ask you for extended suggestions

[final kaoss]

Disable attachment rewriting in vbseo. How can you not understand that?

drop the rewrite of attachments with vbseo

Originally Posted by giorgino

Hi Sebastian you're right. We've nginx with some difficult in configuration... (cry).
I don't understand your super nice help (my english is really poor, sorry for this) and I ask you for extended suggestions

[Makaveli007]

Originally Posted by Mooff

You probably do not have GD installed on your server.

you are correct sir. thanks. resolved

[giorgino]

Originally Posted by extreme-gaming

Disable attachment rewriting in vbseo. How can you not understand that?

Great! Thank you, work perfect!

[Osbes]

Hi giorgino,

the commenly wrong assumption when working with nginx is, that every matching location directives will executed. Nginx will in general execute only one location directive.

To summarize, the order in which directives are checked is as follows:

Directives with the "=" prefix that match the query exactly. If found, searching stops.
All remaining directives with conventional strings. If this match used the "^~" prefix, searching stops.
Regular expressions, in the order they are defined in the configuration file.
If #3 yielded a match, that result is used. Otherwise, the match from #2 is used.

So if your nginx configuration looks like (http://www.axivo.com/community/threa...letin-3.123/):

location / {
    try_files        $uri $uri/ @vbseo;
}

location @vbseo {
    fastcgi_pass        127.0.0.1:9000;
    fastcgi_param        SCRIPT_FILENAME    $document_root/vbseo.php;
    fastcgi_param        QUERY_STRING    vbseourl=$request_uri;
    include            fastcgi_params;
    internal;
}

location ~ \.(jpg|jpeg|png|gif|ico) {
    add_header        Cache-Control public;
    add_header        Cache-Control must-revalidate;
    expires           7d;
    access_log        off;
}

and you want to access an vbseo rewrite attachment url like http://www.propit.it/attachments/f66...-.4.09-005.jpg the executed location directive will be

location ~ \.(jpg|jpeg|png|gif|ico) {
    add_header        Cache-Control public;
    add_header        Cache-Control must-revalidate;
    expires           7d;
    access_log        off;
}

Since this doenst call vbseo.php the url will not resolve in the correct attachment url and you get an 404 http error.


So you could either extend your nginx configuration to always use try_files and then call vbseo.php as fallback, or you disable the rewrite of attachments with vbseo.

On our Forum we disabled this rewrite, cause the gain of this is - for us - lower than the gain of performance, since using try_files for every file isnt that good.

Best regards
Sebastian

[giorgino]

Hi sebastian since you're so kind, I try to take advantage of your expertise.

This is my .conf

server {
	listen   80;
	server_name www.mysite.it mysite.it;
	access_log /var/log/nginx/it.mysite.www.log;
	error_log  /var/log/nginx/err_it.mysite.www.log;
   
	root   /store1/www/it.mysite.www/doc_root;
	index  index.html index.htm index.php;
	
	#
	# Setup Expire
	#
	location ~* \.(jpg|jpeg|gif|css|png|js|ico)$ {
        root /store1/www/it.mysite.www/doc_root;
        access_log off;
        expires 30d;
    } 

	#
	# Inizio Direttive per vBulletin/vBSEO
	#
	
	location ~ \.php$ {
		fastcgi_pass 127.0.0.1:9000;
		#fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		fastcgi_param SCRIPT_FILENAME $document_root/vbseo.php;		
		include fastcgi_params;
	}
	
	location / {
	  rewrite (sitemap_.*\.xml\.gz) /vbseo.php?vbseourl=vbseo_sitemap/vbseo_getsitemap.php&sitemap=$1 last;
	  try_files $uri $uri/ /vbseo.php?$args;
	}
	
	location /vbseo/(includes|resources/html|resources/xml)/ {
	allow      127.0.0.1;
	deny      all;
	}
	
	location ~ /admincp/
	{
		index  index.php index.html;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        	include fastcgi_params;
		if ($uri ~ \.php) 
		{
			fastcgi_pass 127.0.0.1:9000;
		}
		break;
	}
	
	# --- fine 
}

[Mooff]

Version 0.6.3 (23.07.2011)

• Added the possibility to use TMS for automatic template modification.
• Icons can now be merged into different sprites and css rollups instead of one big sprite.
• Addon is now compatible with vBulletin 4.1.x

New template edits:

• None

[giorgino]

Hi Mooff which template changes from 0.6.2 -> 0.6.3?
How upgrade? Simply overwrite files and rebuild sprites?

[Osbes]

Hi giorgino,

There are no template changes from 0.6.2 -> 0.6.3.

If you want to Upgrade from 0.6.2 -> 0.6.3, simply overwrite files, reinstall the addon (simply upload XML-product file with overwrite) and rebuild sprite.

If you want to switch from maually template changes to automatic template changes, there is additional work to be done:

• install the Template Modification System
• undo the template changes you did for sprites
• reinstall this addon (simply upload XML-product file with overwrite).

Now your Templates are automatic changed. This will help you in the next versions, since the upcomming template changes will also be done automatically.


I would advise to do it now, before more template modification need to be done.

Best regards
Sebastian

PS:
I will look into your nginx configuration later