Some years ago, a well-known CEO stood on a stage and screamed that his company and the future was all about "Developers! Developers! Developers!" Since then, the sheer diversity of platforms has exploded, the web continues to advance in content and functionality, and the world supply of developers has grown with mixed result.
As a developer who takes pride in building advanced web applications, I have seen on more than one occasion the negative side of the focus on and proliferation of so-called "developers": trash code that is more often than not brittle, insecure, and clunky. To the average end user, this means that, despite all of the advances in processor, RAM, HDD/SSD, and network technologies, they continue to wait on the applications that they use on a daily basis.
Enter Google I/O. This year, perhaps more than ever, the recurring and overarching theme of the conference was performance. From Project Butter in Android 4.1 to a heavy emphasis on debugging and performance analysis in the WebKit Developer Tools, speed was the talk of the conference. And rightfully so.
Some of the tricks that I picked up at I/O for improving performance in my web apps are briefly described below. I would love to hear what you use to trick the most speed from your apps and/or your experience with one or more of these tools.
WebKit Developer Tools
Okay, so this doesn't really have to do with performance. But if someone can't use your application because they are visually or otherwise impaired, performance is a moot point anyway. Fortunately, the Chrome team has been working on a number of tools for helping developers improve the accessibility of their websites and applications. Tools such as High Contrast, ChromeVOX, and Accessibility Developer Tools go a long way toward making accessibility accessible for developers.
Server-side performance optimization
Too often, particularly with web applications, the real bottleneck is not on the browser. It's not even in the network. It's where the application relies on the server to do something. Make sure that your server-side stuff is optimized. Simple things such as setting expires headers, enabling gzip compression, etc., go a long, long way.
Some CSS rules bring the browser to a crawl while others can achieve virtually the same effect and still scream. Particularly with CSS3 transform3d and more, you can offload a pile of stuff to the GPU and radically improve performance.
Android 4.1 (aka, Jelly Bean) includes a plethora of tweaks to the ICS UI and UX which basically make life faster, smoother, and better. And while this probably isn't a developer tip, I am going to throw it out there. You want Jelly Bean. Not tomorrow. Or next week. But now. And sadly - or maddeningly, I think, from Google's perspective - OEMs and carriers are going to drag their feet in deploying it, and when they finally do push it out the door, they'll figure out how to bog it down with some hack-job custom UI and a pile of bloatware. Demand a vanilla Jelly Bean device from your carrier sooner, rather than later. Tell them that you would even pay extra for the thing so they didn't cripple it with bloatware and custom (read that, junk) UIs.
So there you have it. Just a few of the more technical takeaways that I brought home from Google I/O. Of course, this is a very quick hit list. And in order to actually utilize these tips, you'll have to do more research on your own. I would suggest that you start by going to YouTube and searching for related sessions from I/O 2012.