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/Tho…
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…
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/i…
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.