Wow…just realized its been nearly a *year* since I posted last.  WTF?  OK, that needs to change, because I’ve been digging very far into the SPA world during the past 18 months and as of late, much deeper into the intricacies of optimizing client-driven applications.  I might have made the same lofty “optimize” statement eight years ago, but that would have involved an entirely different technology stack and toolset.  We’re moving past server optimization whereby you instrument your .net call stacks and figure out you have some  bloated architecture, or going nuts with late-binding, or have some over-the-top sql query hitting every non-indexed column it can find.  Nope, I’m presuming we’ve already done/solved that and instead focusing on the sort of performance issues that surface once the request leaves the asp.net pipeline, rips through IIS and hits the HTTP train over to the user.

Web performance *after* the server means everything from analyzing your resource and network utilization (do you have 1 compressed minimized js file or 25 bloated ones??), down to a seemingly-innocuous css class assignment that causes your page to slow down or cause jank.  Web optimization means taking full advantage of the rich set of tools available to look very closely at things like javascript heap allocations to search for bloat or maybe objects that are totally over-staying their welcome way after the last garbage collection cycle has run.  Maybe you’ve taken advantage of some of chrome’s (or Canary’s) flags to expose rich additional functionality and internals exposure.  These tools can help us figure out that a simple hover effect for something like an increased border width (or anything that changes the geometry within the DOM for example) you added to that cell in your pseudo-table just caused a nasty reflow and paint, slowing down the user experience.  We use these same tools to help us figure out why we’re clobbering the browser, getting in the way of frames (forget 16 frames per second, we’re down to like….1….) and causing a jank-fest for your users.

Ouch!  That’s a lot of stuff to learn about, but there’s good news!  It’s actually fun as hell to work on.  It’s very challenging, and can be time-consuming, however, the results can be extremely rewarding both for you in your role as an awesome web developer – and most importantly – and rewarding to your users who get to have a rockin’ app.  Who the heck wants to interact with a single page app if the damn thing freezes all the time…heck they’ll be asking for something silly like Silverlight at that point.  Yuck.

So, I’m pretty certain this is considered witchcraft to some people, but I hope to blog a bit more in the future to provide some helpful experience I’m gaining first-hand as well as point out great resources and show you it’s not witchcraft at all.  So, to that end, we’ll wrap up this post by giving high praise to Google.  They have the tooling that makes this stuff reasonable.  Using chrome’s developer tools, or speed tracer, or deep-dive into chrome://tracing, they got it all.  If you are unfamiliar with this world, take a look into the Chrome developer world to get started.  Also, check out some of the sessions from the awesome Chrome Dev Summit 2013 on youtube.

I probably have like 2 people that read this blog, but my guess is this topic may generate some interest as we continue to move away from postback purgatory and onto this new wonderful single page frontier.  Let me know if this sounds interesting or useful.  That may help me gauge how much effort to put into this blog…clearly I need to step that up 🙂