Client-Side Performance Measurements @ XING

Real-world observations are worth more than theoretical measurements. We´re more aware than ever that performance, speed, is very important to overall user experience. That is why we do more than benchmarking and pure performance research to guarantee great performance for peak traffic of 50,000 concurrent users. We want to take a holistic approach that incorporates all of the factors affecting a user’s experience, in a positive or negative way. Because of this, we recently deployed client-side performance measurements on our whole platform for end-to-end performance. So, if we swap a piece of hardware and see remarkable performance improvements, we will know. If we create JavaScript algorithms or page layouts that lead to poor user experiences, we will know. And we will be hot on the heels of fixing the problem.

But there’s more: Since we can accurately measure the full user experience speed, we can incrementally improve site performance by tweaking many small adjustable screws. These would be unrecognized by users separately, but as a whole, these changes really matter and help us to squeeze out some more milliseconds of the user-perceived performance.

So how does this magic work?

The short version: It’s all in the JavaScript. We measure everything. A timing point is set right at the beginning of the page. After the loading process has finished, the onload event is triggered and transfers the measured data to our logging server. This is achieved using an AJAX request, which means all the key/value pairs are included in the query string of the request. The server responds with an empty 204 OK. Currently, we measure every thousandth request, plus every request with a particularly long duration. But while we’re measuring the whole page performance, we don’t leave out some interesting spots along the way. For example, we want to know how long it takes until our users can interact with the page, so we measure it. Anything interesting on the client side, we measure it.

If you’re really into this issue, you may be wondering why we are not using Jiffy for user experience performance tracing. Well, the answer is simple: Jiffy adds more than 300 lines of code to be delivered to the client, while our own solution is kind of free. The downside of our approach is that it does not work across requests, so we start measuring when a new page loads. In contrast to this, Jiffy measures from the point of time when a user clicks a link in the previous request. We decided to roll our own solution nonetheless as we’ve worked hard to shrink the JavaScript load and we want to keep it this way. The benefits of Jiffy do not justify the extra load for us. The same goes for Steve Souders’ Episodes framework: If you want to make it work in all major browsers, as we do, you have to add another 13 kB of JavaScript to your library, and this is the gzip-compressed number already. Although we may take up the Episodes syntax to be compatible with third-party extensions as the standard evolves in the future.

You may be asking yourself why an external performance measurement provider does not deliver sufficient results. While those are great in many cases, they do not use a real browser to gain results. This is a downside, especially because of the increasing importance of JavaScript-performance. Furthermore, performance checks from external providers are artificial. You will never reach the rich diversity of operating systems, connection speeds and browsers that you are confronted with in real life. Think of someone traveling on a train trying to connect to XING with their Blackberry or iPhone! While you can more or less simulate these situations, we decided to go with the real thing and measure real usage performance.