After seeing how slow the Google +1 button loads and how it can actually degrade your website’s overall pageload time, I started looking around for answers. First of all, I found that I’m not the only one complaining about the issue. Numerous others have started to point out the speed issues with the +1 button. My second thought was to perhaps remove the button from the site, although considering the effect the +1 button has on your website’s ranking that would mean less love from Google.

So what’s a developer to do? If we keep the button on our site, overall pageload times spike. But if we remove the button, or not add it, we might lose out on a potential piece of the social voting pie which most believe affects your search performance.

So here are my techniques for making Google +1 button load faster, or at least not slow down your site. Interestingly enough these techniques are the same set of tips and tricks that Google’s own Page Speed recommends for webmasters.

1) Save a step, Use Https

Make sure you use the HTTPS protocol in the URL for the JavaScript source, as the original version of the button snippets given out by Google included the HTTP version http://apis.google.com/js/plusone.js which just does a redirect to https://apis.google.com/js/plusone.js This issue has since been corrected by Google when you use Google’s +1 button generator site.

2) Don’t load the script on Mobile devices

As stated by Google, currently the Google +1 button does not support mobile devices like the iPhone, iPod touch, iPad, or Android. This means if you have the button code on a mobile site you’re basically wasting HTTP connections and adding extra weight to your site’s throughput. To get around this fact you need to write a little utility function in JavaScript that sniffs the userAgent for unsupported devices, and only makes a call to the script if your client is not one of those devices.
For example in the case of an iPhone and iPad website, you would do something like this:

function isMobileUser(){
  return (/iphone|ipod|ipad|android|blackberry|mini|windows\sce|palm/i.test(navigator.userAgent.toLowerCase()));  
}
if(!isMobileUser()){
	//include the plusone.js code here
}

3) Load the plusone.js script asynchronously

HTML 5 has introduced the ability to load scripts asynchronously allowing the rest of the page to load independently of potential bottlenecks. This feature is actually already in use for the Google Analytics code. Keep in mind that only Chrome and Firefox 3.6 and above support the async feature at this time. But it does not hurt your non-supporting browsers in any way so it’s safe to use. Here’s the code that combines the check for unsupported mobile browsers from before to load the +1 button script asynchronously. Note that since this code is loaded asynchronously it doesn’t matter if you put the call in the footer or header.

function isMobileUser(){
  return (/iphone|ipod|ipad|android|blackberry|mini|windows\sce|palm/i.test(navigator.userAgent.toLowerCase()));  
}
if(!isMobileUser()){
// create a new script element in the DOM
var gp1script = document.createElement('script');
// set it's type attribute, not really needed in HTML 5 but just to be safe
gp1script.type = 'text/javascript';
// set the HTML 5 attribute of async to true for the script tag
gp1script.async = true;
// set the source attribute to the https version of the google pluseone code
// change this to your own server path if you are cosidering using option 4 below
gp1script.src = 'https://apis.google.com/js/plusone.js';
// add the new script tag to the head or body of the page
(document.getElementsByTagName('head')[0]||document.getElementsByTagName('body')[0]).appendChild(gp1script);
}

You would then place the tag where you want the +1 button to render, which since it is a proprietry tag will just be ignored if the script is not present on your page.

<g:plusone></g:plusone>

If you’re not comfortable with the tag, you can also use an HTML 5 version to render the +1 button on your site, which uses a css class of g-plusone and sets attributes as needed. For example you can display a standard +1 button with counts using this HTML 5 tag.

<div class="g-plusone" data-size="standard" data-count="true"></div>

Note that you can also place multiple +1 buttons on a single page. For example you might have a +1 button that directs its vote to your main parent homepage like so:

<g:plusone href="http://www.your_tld.com/></g:plusone>

4) Host the plusone.js file yourself

This option has been suggested by some users, although I personally argue against it just because you’ll be responsible for continuously monitoring changes and updating your version. The big benefit here is avoiding that dreaded HTTPS server, but keep in mind the script still will make that second call to load the plusone library so you’re still not home free. Only go this route if you’re seriously considering a site improvement and are willing and capable of pushing out updates to your version of the script. I’m sure the Google +1 team is making lots of changes and adding bug fixes which you will miss out on if you forget to update the script on a daily basis. In the extreme case you could perhaps write a program that downloads the latest version of the script from Google’s servers and updates your version on a daily basis, but then again this becomes a new task to keep an eye on.

Hope this helps and let me know if you have other tips and or feedback regarding these ideas. For more details be sure to read the +1 button API page.

1. Make fewer HTTP requests
2. Use a CDN
3. Add an Expires header
4. Gzip components
5. Put CSS at the top
6. Move scripts to the bottom
7. Avoid CSS expressions
8. Make JS and CSS external
9. Reduce DNS lookups
10. Minify JS
11. Avoid redirects
12. Remove duplicate scripts
13. Configure ETags

My blog gets a C grade, ouch, but shouldn’t 79 really be C+ or B-?

So How are the grades computed?

This is from the docs for YSlow which outlines these rules and give you more tips on what to do to improve your grade.

The grades for individual rules are computed differently depending on the rule. For example, for Rule 1, three external scripts are allowed. For each script above that, four points are deducted from the grade. The code for grading each rule is found in lint.js. The overall grade is a weighted average of the individual grades for each rule. The rules are approximately in order of importance, most important first. The specific weights are in the lintweights array in yslowcontext.js.

Here is the specific array mentioed above with the weights assigned to each rule:

this.lintweights = {
        "NumComps"     : 8,
        "CDN"          : 6,
        "Expires"      : 10,
        "Gzip"         : 8,
        "CssAtTop"     : 4,
        "JsAtBottom"   : 4,
        "Expression"   : 3,
        "ExternalFiles": 4,
        "Domains"      : 3,
        "Obfuscate"    : 4,
        "Redirects"    : 4,
        "JsTwice"      : 4,
        "ETags"        : 2
};

Let’s look at why I got some the grades.

Rule #2 Use a CDN

I got a letter of F in rule 2 for not using a CDN. Is Yahoo getting paid to promote Akamai? No but seriously, I doubt any personal blogs are going to start using professional CDNs anytime soon, not unless they are super successful. But if you are using your own personal image cache servers you should add your server host to the list of “known CDNs”, because the default CDNs are the ones used by Yahoo! and chances are these are not relevant to your web site. Here’s how to add them according to the YSlow docs.

1. Go to about:config in Firefox. You’ll see the current list of preferences.
2. Right-click in the window and choose New and String to create a new string preference.
3. Enter extensions.firebug.yslow.cdnHostnames for the preference name.
4. For the string value, enter the hostname of your CDN, for example, mycdn.com. Do not use quotes. If you have multiple CDN hostnames, separate them with commas.

Rule #3 Add an Expires header

This rule suggests adding Expires tags using the Apache server setttings. According to research at Yahoo they have come up with the 80/20 rule of reducing HTTP traffic.

Since browsers spend 80% of the time fetching external components including scripts, stylesheets and images, reducing the number of HTTP requests has the biggest impact on reducing response time.

These are the complaints YSlow has for my Expires tags.

These components do not have a far future Expires header:
•  (7/26/2007) http://pagead2.googlesyndication.com/pagead/show_ads.js
•  (no expires) http://stats.wordpress.com/e-200730.js
•  (7/26/2007) http://edge.quantserve.com/quant.js

Here are the docs for using mod_expires.  In this environment you can turn on this expires setting in your .htaccess file using these directives:

<IfModule mod_expires.c>
ExpiresActive on
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/x-javascript "access plus 1 month"
</IfModule>

I’m using 1 month expiration dates, but Yahoo is suggesting 10 years. You might want to pick something that suits your specific needs. By its nature having the expires tag should in turn reduce your browser’s HTTP requests, thereby improving your score on Rule #1 of Making fewer HTTP requests.

Rule #13 Configure ETags

Another point to touch up on is the Etags required in Rule #13. YSlow is complaining about Etags because of a known problem with the way Etags are written if you have a clustered server network. If your site is served off of one server this ETags score is pretty much useless. Etags is basically a string that Apache slaps on as a response header. By default this string is composed of 3 parts.

1. The file’s last modification date
2. its current size
3. its Unix inode

The problem is that with multiple server environments, your inodes are going to be unique and different for each server. So if you have a banner.gif on 12 servers, it will have 12 different Etags, therefore making the whole thing useless. YSlow suggests to remove Etags all together using the directive :

FileETag none

This seems to be the norm for most big portals such as Google and Yahoo these days. This way you not only reduce the complexity, but also reduce the HTTP response headers flying around. If you really want to use Etags you can remove the inode from the Etags string by using this directive which will only use the modified time and size of the file:

FileETag MTime Size

So in my case I have 3 files that have Etags that I have no control over, since they are external stats files and I would think that eventually these people would use YSlow and fix their FileEtag directives accordingly.

These components have an ETag:
• http://edge.quantserve.com/quant.js
• http://stats.wordpress.com/e-200730.js

Rule # 12. Remove duplicate scripts

YSlow noticed that the show_ads.js from Google’s AdSense program is loaded twice on this page. I’m currently using the terrific WordPress plugin AdSense Manager which interestingly enough seems to be putting in the JS tag once for each ad on the page. I’m not sure if this is something that might be required by Google. I would be interested in finding out if I can change the plugin to include the AdSense script file only once which would make more “sense” without leading to potential side effects on Google’s side of things.

1) Validate your code

Although JavaScript can be very forgiving when it comes to error handling, sloppy coding will come back to haunt you in the long run. So the first step is to validate your code. I use JSLint which scans JavaScript code for syntax errors and common mistakes and recommends fixes. JSLint piggy backs on Rhino which is an implementation of JavaScript written in Java from Mozilla. You can either use the online version or download and run the scanner locally. I prefer this local method which utilizes the java runtime.

To use JSLint locally:

1. Download and unzip Rhino to a folder on your computer. You need js.jar
2. Download and save the JSLint library file jslint.js
3. Run JSLint in the Rhino Shell passing it a JavaScript file to scan. Here is the command I use assuming js.jar, jslint.js, and MYBIG.js are all in the same directory.

java -classpath js.jar 
org.mozilla.javascript.tools.shell.Main 
jslint.js MYBIG.js

You will then see a list of errors found by JSLint and suggestions for fixing your code. Some of the most common items are:

• Missing end of line semi-colon delimiters ;
• Not using dot notation to reference DOM objects (ex. form['name'].input.value instead of form.name.input.value )
• Using == instead of === for comparing with null, undefined, booleans, zero and “”
• Variable scope issues caused by declaring variables inside of loops instead of declaring them first in functions definitions.
• Not using curly braces in your conditional blocks. So make a point to always do If(x){doX();}else{doY();} even if you have one liners.
• Stay away from using eval() or with(). eval is evil
• Create your arrays using literal notation [] instead of new Array()
• Create your objects using {} instead of new Object()
• Avoid using javascript:function() in URLs
• You can read more suggestions in the JSLint docs.

2) Join your files

If you have five separate CSS files and three different JavaScript files, your server has to answer 8 HTTP requests per client. Each request requires additional processing and slows down your page loading. By concatenating your CSS and JavaScript files to only 2, you should see page load time improvements, especially when client requests are coming from distant networks.

Another tip that I have seen is to move your JavaScript include tags to the very bottom of the page, right before the </body> tag. This will allow the browser to draw the DOM before loading your library files and the page will appear to load faster.

So after your various source files are nice and lint free, and combined into a single library file you are ready to start shrinking.

3) Shrink your library

Before shipping your code, shrink it. JavaScript and CSS files are not compiled and they contain lots of wasted whitespace which are nice to have when you’re coding but serve no benefit to the user of your website. There are four different tools you can use to filter out the unnecessary bits from your JavaScript and CSS files, and for the most part they are doing the same thing. I personally use ShrinkSafe which is a happy safe medium. The reason is that this tool does not mangle your code so that its API will stay in tact. If you choose to use a decryption based method to obfuscate your code, it can have harmful side effects. First, the size of the encrypted file can in some cases actually be larger than the original! Second, your scripted API can get mangled, forcing you to update all external pointers to your code. If you have any clients who use your API via JavaScript, you should obviously take great caution in using encryption methods.

Caution: As always, backup your code before making changes to them using these tools! There is no undo!

JavaScript Shrinking

1. JSMin removes extra white-space and comments. It also reduces the line count by increasing the maximum line width. The result a bit uglier and harder to read and debug but also a bit smaller. Unlike ShrinkSafe, though JSMin does not edit your function arguments. You can download it in a variety of flavors. Here is a DOS executable version and the command to run it.

   jsmin <big.jsb >min_jsmin.js "(c)2007 CORP"

2. ShrinkSafe removes extra white-space and comments, but keeps one statement per line which is easy on the eye if you decide to edit your shrunk file. It also shrinks function arguments by replacing them with consecutive _## values which tends to reduce the files size some more. Download the jar file here and run it as follows:

   java -jar custom_rhino.jar -c big.js > 
   min_shrinksafe.js 2>&1

3. Packer has a few options you can choose to minify your scripts. The normal option removes extra white-space and puts the entire file in one super long line. You can also choose to shrink function as well as encode your script using a base62 algorithm. You can try it online. Although your file size is considerably smaller, depending on the complexity and cleanliness of your code (see JSLint above) using the two options in Packer might introduce errors with your code. In my case I had no problems with them.
4. MemTronic – Hardcore shrinkers out there can try this online tool which produces the smallest file size in my tests. Be warned that this is only for the braveheart coders, has some known issues and may have some side effects.

I have run Prototype.js against these 4 tools and the results are shown below. The results show that you can save at least 20% on your file size without compromising much stability.

CSS Shrinking

1. Clean CSS – This tool creates the best results, reducing the files size while maintaining a nicely formatted and readable CSS file. It has a plethora of options to choose from as well. For example, you can sort the properties of all the selectors which is a godsend for neat-freaks like me. It will also compress your css by converting possible properties to use shorthand notations. You can choose to save your comments.
2. CSS Optimiser – This tool only has one option which is to remove line breaks or not. Does a good job however the final file size does not decrease much if you don’t pick that option, which makes the css tough to read.
3. Icey CSS Compressor – Here is another powerful tool with lots of options to go around. Here are a few of them: Convert colors to hex, combine identical rules, combine properties, combine selectors, remove useless padding and margin. It also outputs in a nice colorful format for you. However there is no option to keep line breaks in tact so you get the output all in one line, and in my case this actually created an error.
4. Flumpcakes Optimiser – This tool has a few useful options such as combining backgrounds, fonts, lists, borders, and style which appear in multiple places. It can also convert RGB to hex and absolute to relative.

I ran the CSS from EarthLink ReaDeR through the top four tools and the results are shown below.

4) Compress your files

The HTTP implementation covers accept-encoding and content-encoding in detail and most browsers today support these methods. Basically when a browser sends a request, it tells the server it would like to have the file back in a compressed format such as gzip or deflate. The server then compresses the file and sends it back, and the browser decompresses the file and renders it in the browser. The most common format used today is GZip. Here is how to setup GZip in two popular web servers.

1. Apache & mod_gzip – If you are running on Apache and have already compiled it with mod_gzip you can easily configure gzip compression by adding these lines to an .htaccess file placed in your web root or your http.conf file.

   mod_gzip_on Yes
   mod_gzip_item_include file \.php$
   mod_gzip_item_include file \.html$
   mod_gzip_item_include mime ^text/html$
   mod_gzip_item_include file \.txt$
   mod_gzip_item_include mime ^text/plain$
   mod_gzip_item_include file \.css$
   mod_gzip_item_include mime ^text/css$
   mod_gzip_item_include file \.js$
   mod_gzip_item_include mime ^application/x-javascript$
   mod_gzip_item_exclude mime ^image/

   If you don’t have access to your .htaccess file but do have php compiled with the zlib module you can rename your javascript files to .php extensions and add this to the top of your file.

   <?php ob_start("ob_gzhandler");
   header("Content-type: text/javascript;charset:UTF-8");
   header("Cache-Control: must-revalidate");
   $offset = 60 * 60 * 24 * 365; // one year
   $ExpStr = "Expires: " .
   gmdate("D, d M Y H:i:s",
   time() + $offset) . " GMT"
   header($ExpStr);
   ?>

2. JBoss and Tomcat – To enable compression in a J2EE environment running Tomcat within JBoss, you can now enable compression by editing your server.xml that sits in the tomcat.sar folder. Just add these attributes to the Connector node:

   <connector port="8080" compression="on" 
   compressionMinSize="300"
   noCompressionUserAgents="gozilla, traviata"
   compressableMimeType="text/html,text/xml,text/css,
   text/javascript, application/x-javascript,
   application/javascript" />

The Results

Finally, here are two pages that use the compressed versions of prototype.js and reader.css, one with gzip compression enabled, and the other without gzip compression enabled. Using the Net tab in FireBug we can easily see that the gzipped version of both the CSS and JavaScript files actually result in less network traffic and faster loads times.

We cut our total throughput by 44 KB or 70%! Also the total load time is cut by 521ms or 51%, basically reduced from 1 second to half a second. If we do some quick math, for a website that gets 1,000,000 unique visitors per day, this is a daily savings of 44GB of bandwidth, and a total of about 145 precious hours saved.

Size in KB	CSS	JavaScript	Total
No Compression	12KB	51KB	63KB
Gzipped	4KB	15KB	19KB
Reduction	8KB 67%	36KB 71%	44KB 70%
Savings for 1 mil uniques/day			44 GB

Time in Milliseconds	CSS	JavaScript	Total
No Compression	281ms	741ms	1022ms
Gzipped	110	391	501ms
Reduction	171ms 61%	350ms 47%	521ms 51%
Savings for 1 mil uniques/day			145 Hrs.