If you run a website but you’re not aware of Google’s free Webmaster Tools, you need to get in the loop! These tools allow you to analyze a number of important aspects of how your site is viewed/analyzed by Google’s search engine index.
Yet, with all the power and insight these tools give, it still feels like it’s best-kept-secret kind of thing that such tools even exist. I never hear anyone talking or writing about them. But I fire them up probably at least once a month to keep an eye on my various sites.
But the hush-hush of Google’s toolset makes it more exciting to highlight a really cool addition announced today, the new Site Performance tool. True, it’s still in development and very early on, but it already is showing the promise to give great new insights into how your site is performing out in the wild.
We all got the hint a few weeks ago that Google is planning to start considering page-load speed in its indexing algorithm. It would seem to be somewhat “evil” for the world’s largest search engine to start holding page-load speed against everyone’s sites without being part of the solution. So it shouldn’t be a surprise that the G would begin releasing various “tools” to help the rest of us actually make our sites load faster.
Bye, bye, birdie!
Yesterday, the Google Analytics team released a long-overdue update to their suggested snippet for including “ga.js” in pages. They wisely ditched the horrid “document.write()” approach that has been the standard for the longest time, in favor of this new asynchronous loading technique. The reason? Quite obviously, this now will unblock the loading of GA from page loads, thus preventing Google from being at fault for slower load times!
Side Note: the suggested code that Google has released has been shown not to be safe with all page structures in some browsers, including (ironically!) Chrome, and Opera. The problem is a faulty assumption that “document.documentElement.firstChild” will always return a reference to the HEAD element to append the <script> to. As this documentElement.childNodes test page from @kangax shows (if loading in Chrome or Opera, for instance), it’s (too) easy to accidentally create your page in such a way that this assumption will fail. So, be careful before you jump to switching to Google’s new snippet. (hint: use LABjs instead. Simpler, easier, and much more reliable!)
But, snarkiness aside, the new “Site Performance” tool proves its worth when it shows you a graph of your page’s estimated average load speeds over the last several months, along with a few basic statistics. It also incorporates a number of Google’s PageSpeed rules and suggestions for how to reduce factors that are slowing down your page loads.
This information is a really great place to start when trying to attack the performance issues your site may have. In fact, it may help you identify issues you didn’t even know existed!
Where’s the visuals?
Imagine my elation when I pulled up one of my larger, more traffic’d sites in the tool and saw this graph:
Site page-load performance improvements over last few months
I went from an average of over 3.5 seconds per page load back in August down to a current average of less than 0.3 seconds, which the tool claims is better than 98% of sites! Oh, and btw, this site loads over 105k of JS, images, and CSS, so this isn’t some puny text-only site getting that kind of loading speed. It’s a testament to the results you can get if you start caring about page-load optimization on many fronts.
But you know the biggest and most obvious change I made back in July and August on the site in question? That’s right, you guessed it — that’s when I first installed early versions of LABjs for all the site’s scripts. And over time, I’ve not only improved the efficiency and capabilities of LABjs, but I’ve also refined more and more how I work to address page load speeds. To be fair, optimizing script loading was only one of many strategies I used, including CSS spriting and combining/concat’ing of JS files to reduce the number of HTTP requests.
But it’s plainly evident that LABjs was a critical part of this process!
No matter what you feel about dynamic script loaders and if they are useful or not, it’s clear that all of us have to get more serious about improving our page-load performances if we don’t want to get left in the Google-index dust. I just believe that script loading is an easy and hugely impactful place to start that process. Remember: optimize, optimize, optimize.
