Performance Is A Feature

Performance, like any other feature, doesn’t just “happen”; it has to be designed and built. To do performance well, you have to think about it, study it, write extra code for it, test it, and support it.

Since you can’t know how your application is going to perform in production, you need to write your application so that it’s easy to fix performance in production.

From one of my favorite papers on performance: Thinking Clearly About Performance, by Cary Millsap.

Improving Mobile Performance

Back in August Digiday wrote about how GQ cut its webpage load time by 80 percent ( emphasis mine ):

Before GQ relaunched its website July 1, pages took a painfully long seven seconds to load. With GQ’s mobile visitor at 53 percent of its traffic and growing, that was an unacceptable lag.

Always good to hear about sites doing more to improve the performance of their site ( mobile or not ). Unfortunately the only data point they provided was that the page took “seven seconds to load”. It isn’t clear what they were measuring that took seven seconds, or under what conditions the test was run.

So I went to and ran my own tests:

The mobile site is definitely lighter than the desktop one. Fully loaded desktop first view is 9.5MB and mobile is 5.1MB. Unfortunately under these test conditions the first view mobile site still took 61.6 seconds to fully load.

Hacking Both Ends

When you control the server and client sides of an application you can come up with some impressive performance hacks. Facebook’s changes to preview photos is a good example of that:

There are a few tables within the JPEG header, which accounts for its size. The question then became: Would it be possible to generate a fixed header that could be stored on client and therefore not need to be transmitted? In that scenario, only the payload would need to be sent, which would make this the winning format. The investigation began.

For some slow cases they were able to improve page load performance by 30 percent.

RUM for AngularJS

Soasta on how they deal with real user monitoring in AngularJS:

First, we now listen for AngularJS routing events, such as $routeChangeStart. Once we see that the visitor is about to view new content, we start listening in preparation for gathering performance metrics for the soft navigation.

Second, and most importantly, when the page is first loading, and when a soft navigation starts, we begin monitoring the HTML document for any new downloadable resources that get inserted. We do this via a MutationObserver.

Real user monitoring techniques for single page apps are becoming a big deal, and don’t easily have a one size fits all solution.

JavaScript Performance Monitor

stats.js is a nifty little performance monitor:

This class provides a simple info box that will help you monitor your code performance.

– FPS Frames rendered in the last second. The higher the number the better.
– MS Milliseconds needed to render a frame. The lower the number the better.
– MB MBytes of allocated memory. (Run Chrome with –enable-precise-memory-info)

The FPS monitor looks like this: