Twitter is optimizing its web interface for speed, ditching several of the supposedly cutting-edge changes it made with the “new Twitter” revamp from 2010. The new Twitter redesign was controversial for its use of hashbang (#!) URLs and because it used JavaScript to build the entire page, content and all.

Now Twitter is returning to tried-and-true server-side methods of building webpages. It turns out using JavaScript to do everything is not such a good idea, at least not if you want your website to be fast.

Twitter says that returning to traditional means of serving webpages “dropped the time to first Tweet to one-fifth of what it was.”

Even better news for those concerned about the future of the web and the longevity of URLs is the news that Twitter is getting rid of its hashbang URLs. The hashbang syntax was originally designed to allow Google’s spiders to crawl Ajax content — content loaded dynamically — but sometime in 2010 hashbang URLs started popping up all over the web, including at Twitter.

The hashbang syntax works well if you use it as it was designed, to surface Ajax content that would otherwise be missed by Google. But it was always an awkward hack, not a cornerstone on which to build a well-designed URL, and extending it beyond its intended use often proves disastrous (as sites like Gawker can attest).

Twitter will begin phasing out hashbang URLs in the coming weeks, starting with its tweet permalink URLs.

Much of the write-up about the new speed enhancements on Twitter’s engineering blog reads like a web development best-practices tutorial from 2001, but there are some new ideas lurking toward the end, where Twitter Engineering Manager Dan Webb outlines Twitter’s new module-based JavaScript loading methods, built around CommonJS.

“We opted to arrange all our code as CommonJS modules,” writes Webb, “This means that each piece of our code explicitly declares what it needs to execute.” In other words, each piece of code is aware of what other pieces it needs to work. That means Twitter can tune how it bundles its code, “lazily load parts of it, download pieces in parallel, separate it into any number of files, and more — all without the author of the code having to know or care about this.”

Webb doesn’t mention Twitter’s front-end toolkit BootStrap in his post, but rolling together CommonJS and Twitter’s own dependency builder — which Webb says is similar to the RequireJS optimizer — sounds like a great addition for BootStrap 3.0.