Client-Side Performance

Download Time

Once the JavaScript is in the user's browser, things are both easier and harder to analyze. On the one hand, you (the developer) can download the program, test it and check the performance—and then, you also can use in-browser debugging tools to test and improve things.

One of the most important tools offered by both Chrome and Firefox is the display of files being sent to the browser. Even if your site appears to be loading and rendering quickly, a quick look at the download timeline almost certainly will be somewhere between surprising and shocking to you. You'll see how long it takes for each of the JavaScript (and CSS, and image) files to download and, thus, how much time it takes between the user requesting your page and the content actually appearing on it. This is a great way for you to identify potential bottlenecks and then reduce their effect on the slowness (or apparent slowness) of your site.

Even New Relic, which normally is considered a (commercial) server-side performance monitor, now offers some client-side performance checking. You place a small piece of JavaScript on your site; New Relic collects this information, and then tells you how long it took for your content to get to the user's browser and how long it took to render. This provides a surprisingly insightful view of whether you need to work on improving the speed with which your files are delivered or to optimize the code further, such that it runs faster. There definitely are other options, but I've found that even the free (not open-source, but free of charge) New Relic client-side benchmarking to be quite useful and helpful.

Once you have combined and compressed your JavaScript files, you seriously should consider putting them, as well as any other static assets (such as CSS files and images), on a content distribution network (CDN). A CDN handles only static content, but given how many large, slow-to-download files are static, that often can provide a significant improvement. CDNs not only have a great deal of bandwidth, but they also copy your content to multiple servers, using the geographically closest one to serve content to your user. Thus, a user in Tokyo will receive data from a local CDN server, whereas a Chicago-based user will receive it from a different CDN server. So, using a CDN reduces the load on your main web server, while decreasing the actual and perceived download times.

Benchmarking JavaScript

Although JavaScript has a (well deserved, I think) reputation for being a frustrating and quirky language, the fact is that modern JavaScript implementations run very quickly—assuming that you use the language in the right way. However, it's sometimes hard to know where your program is spending most of its time. Fortunately, the Chrome developer tools (a part of the Chrome browser) include a profiling tool. Go to the "profile" tab in the developer tools, and select the CPU option before visiting your site. You can run through your site for a few seconds or minutes before stopping the profiling from taking place. Once you've done that, you'll get a (very long) indication of which JavaScript programs were running, where they came from and how much time the CPU spent in each one.

You similarly can ask the profiler to examine memory usage. The more complex the application you're writing, the more necessary these tools will be. At the same time, you'll likely find that when you profile your JavaScript code, the most frequently used code probably will be code you didn't write yourself, but rather that is part of the underlying framework you're using.

In Firebug, the Firefox-based debugger, you can profile a page by going to the "console" tab and clicking on "profile". You'll see a table showing how much time was spent in each function, and what percentage of the total time was spent there. If you're a Chrome user, you can open up the developer tools and click on the "profiles" tab. You'll then need to choose whether you want to check CPU performance or memory performance (in two different flavors). After starting and stopping the profiler, you can analyze the resources that JavaScript used—and then, of course, change your code appropriately.

One tool I have begun to use more frequently is PageSpeed from Google. This collection of tools would appear to be an SaaS, an updated version of YSlow, which was my go-to tool for many years. For example, Google's tools will tell you how mobile-friendly your site is.

Moreover, the PageSpeed results always point to documentation that describes, in great detail, why issues are problematic and what steps you can take in order to fix them. This documentation is surprisingly well written, and it points to very practical, clear suggestions for how to improve the performance of your JavaScript and CSS. After running PageSpeed against one of my client's sites, I found that we still had some blocking JavaScript higher up than is perhaps necessary. It also suggested which images could be compressed and how much space we would save in so doing.

Summary

Although server-side programming still is a vital part of the web, the client is where much of the action is, and where the user often perceives lags and slowness. As a result, it's worth investing time to check your client-side performance and to address problems before your users start to complain (or leave you without complaining). Using a variety of tools to check your performance, as well as to reduce the size and time of JavaScript and CSS downloads, will go a long way toward improving your users' satisfaction with your site.

______________________