My applications are part of a framework (LMS) that load a billion extra items on each page load.
To get around it I wanted to do that silly “twitter thing”. They’re the ones who get credited with it because for years normals were baffled by their url changing.
http://www.adequatelygood.com/2011/2/Thoughts-on-the-Hashbang
Additionally, if you’re interested in why the bang(!) is necessary, it’s not. It’s just to tell google to index the page. Otherwise they assume it’s just an anchor link.
https://developers.google.com/webmasters/ajax-crawling/
So I spent the last few hours changing all links in one of my current applications to do a “hashbang” sort of call instead of loading new pages. This significantly increased speed when using our clunky LMS.
This was especially annoying because our LMS forces changes with <a> tags.
What made this especially easy to implement was that I had already made all links go through a smarty plugin so altering all links in the application was just in one file and I could make those links specific to whatever authentication scheme / LMS the application is living in. So I just had to alter that plugin and the LMS specific layout and bam. The only thing that’s not covering is form submissions. But there are only a couple of those, so I’m not going to stress about that.
In continuing research obviously I had to investigate why twitter moved away from hashbangs.
http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html
The highlight of that being that with hashbangs, you have to go to the client and then back out, which reduces speed on the initial pageload. So twitter went a little fancier 6 months ago and used the history api’s PushState.
Implementing the hashbang urls was a very small amount of code, so I’m going to move forward with that for now, maybe next time I get a chance to do some research I’ll focus on converting that to PushStates.