There has been plenty of buzz lately around optimizing front-end performance.

Tools like Google Page Speed, YSlow, and the built-in developer tools in most browsers make it easy to see how your front-end performance stacks up. They even make some pretty good automatic suggestions. Tips like reducing the number of HTTP requests, shrinking images and other static content, and offloading static assets to a Content Delivery Network (CDN) are pretty much no-brainers.

Front-end optimizations are the low hanging fruit because they are relatively straightforward to implement. They are so straightforward, even, that a bunch of companies are now offering fully automated solutions that optimize your site’s front-end performance without writing a line of code.

People love to apply the 80/20 rule to performance optimization, making claims like “80% of the time spent waiting on web pages is from the front-end.” This might be true for the Internet at large, since most of the sites out there serve mostly static content. But for real web applications, with serious data models and business logic, back-end performance plays a more pivotal role in overall user experience.

Why is back-end performance more important?

The truth is, back-end performance is especially crucial because it deals in the world of exponents. If you’ve ever run serious load/stress tests, you’ve seen a graph like this:

The “hockey stick” at the end happens when you hit a bottleneck. Even though user load increases linearly, the response times increase exponentially when a bottleneck is reached. This rarely happens on the front-end. If your images are too big, or the page has too many files, you’ll see a slow-down but it will be pretty much constant regardless of user load. It is unlikely you’ll hit a true bottleneck on the front-end.

The back-end, on the other hand, has a lot of potential bottlenecks. Not enough RAM or heap size? Thread contention? Too few database connections? A misconfigured database table, the wrong kind of locking, or missing indexes? A web server with max connections set too low? These are just a few possibilities. If any back-end factor becomes a bottleneck, you’ll see an exponential slowdown in performance.

If it’s so crucial, why doesn’t the back-end get more attention?

Mostly because finding and fixing back-end performance problems can be really hard. While every web application has a few things in common, no two are alike. Web applications are written in literally dozens of languages and hundreds of different frameworks. They all have different data models. There’s no universal guide for tuning them. Real application tuning requires a pretty thorough understanding of the architecture, which a casual 3rd party — or automated service — rarely has.

As a result, nobody has been successful at carving out a market for “automagic” back-end performance enhancers. Think CloudFront, Torbit, Blaze.io (recently acquired)… these guys all sell easy solutions for optimizing your front-end performance. However, nobody is out there talking about a “one-size-fits-all” equivalent for back-end performance.

If you’re developing serious applications and performance/scalability is an issue, you can’t really afford to ignore back-end performance. Back-end performance tuning requires a hands-on understanding of the architecture, a good way to measure performance repeatedly, and lots of trial and error. 

Over the next couple weeks, I’ll follow up with a series of blog posts with some of my own best practices for back-end performance tuning. Stick around!