Ghostbusting For Front-end Developers

Human sacrifice, dogs and cats living together... mass hysteria! We’d like to avoid that, right? Well, today we’re going to talk about how to improve the accuracy of your front-end testing environment so you’re not chasing ghosts. This is important for anyone building high-performance apps for the web.

All engineering requires environmental assumptions. This is particularly important when we’re measuring the quality and performance of the web experiences we create. A faster web is a better web, but before you can achieve this, you need to ask yourself - is your room clean?

We all remember being asked to keep our rooms clean when we were young. A quick Google search instructs us that keeping our rooms clean can be done in a few straight-forward steps:

1. Keep food out of your room.

2. Put things back where they belong.

3. Do simple maintenance cleaning.

4. Break the habits that lead to filth.

Cleanroom Testing

A similar set of criteria can be used to ensure more accurate results during any sort of performance testing. It’s been known forever as Cleanroom software engineering and it can save you chasing performance ghosts:

The Cleanroom software engineering process is a software development process intended to produce software with a certifiable level of reliability. The focus of the Cleanroom process is on defect prevention, rather than defect removal. The name Cleanroom was chosen to evoke the cleanrooms used in the electronics industry to prevent the introduction of defects during the fabrication of semiconductors

Performance testing sometimes feels like an inaccurate science. It’s like yelling "Hey, asshole!" in a crowd, just to see who turns around. Wouldn’t it be better if there was a little more certainty in our process?

Now that we know the definition of Cleanroom engineering, let’s assume that you do care about performance. Maybe you’re working on a client-side web app, an animation-rich site or a game for the web. You ideally want to stamp out things that keep you slow. I'm talking about memory leaks, excessive CPU usage, rendering & layout issues and anything which can generally lead to a sub-optimal user experience.

A savvy web developer will have been using their browser of choice (be it Chrome or otherwise) for a few years and built up a collection of extensions and apps that they've installed. They'll also have numerous desktop apps that are just running in the background. A lot of the time, you just forget they're there until you need them.

Whilst that might be okay for the casual user, developers need to be extra careful. You see these apps and extensions (whilst powerful) are susceptible to the same rules of using system resources and leaking memory as any normal application. This matters because if you're testing out your app in a browser with all of these apps and extensions running, they can impact your app's performance and thus your performance profiling.

One developer I know recently spent hours trying to nail down a memory leak slowing down their app only to discover it wasn't their app at all - it was an extension running in the background. That isn't to say extensions are the blanket cause of apps being slow (they most certainly aren't), but that we need to be super careful when testing in browsers.

Chrome and Opera

So, how you do profile in Chrome with a clean slate? You have a few options. The one I recommend the most often is testing in a fresh user profile. You can do this through the Chrome menu or via the command-line by opening up Chrome with the --user-data-dir="" switch (relevant docs). As long as you don't add extensions to the profile, it should remain clean.

To launch Chrome using the --user-data-dir switch with the path '/dev/null' on different platforms you can use these one-liners:

• OSX: open -a "Google Chrome" --args --user-data-dir=/dev/null

• Linux: google-chrome --user-data-dir=/dev/null

• Windows: "C:\Users\username\AppData\Local\Google\Chrome\Application\chrome.exe" --user-data-dir=/path/to/foo

To the best of my knowledge, now that Opera use Blink the above should work equally well.

Firefox

In Firefox, you can either create a new user profile through the Profile Manager or via the command-line with the -profile ‘..profile_path’ switch. Full details about the switches FF supports via the command-line are available.

IE

You can run IE in a stripped down mode (with add-ons disabled) via the command-line with iexplore.exe -extoff. You can also use the manage add-ons option to disable extensions and toolbars if you require further granularity.

5 Rules to live by

There are a few other rules worth keeping in mind, but in short:

1. Test your browser with an empty user profile

2. Ensure that no browser extensions are running

3. Ensure that you've closed unnecessary background apps

4. Close any unrelated tabs or secondary windows

5. Disable any overclocking you may have enabled

These may sound painfully obvious, but a high percentage of the developers I speak to benchmarking and profiling their pages forget to do any of the above. Let’s change that.

Wrapping up

When you're trying to test your app, assume laboratory conditions, avoid contaminations and just create a cleanroom testing environment. It's safer and more likely to save you time chasing ghosts. Chase real performance problems instead.

If I'm wrong, nothing happens! We go to jail - peacefully, quietly. We'll enjoy it! But if I'm right, and we can stop this thing... Lenny, you will have saved the lives of millions of registered Githubbers - real quotes, people. Real quotes.

Additional notes

• DevTools guide to creating a cleanroom testing environment worth checking out with related advice.

• Your users are likely to have apps and extensions running on their systems which may impact your page's performance. This is to be expected, however I try to keep average baseline is as good as it can be regardless.