Expensive

I have nothing but respect for game developers. What they create are nothing short of technical feats and they tend to work with anemic budgets.

If you think a second is fast, bear in mind the benchmark to reach in game development is processing and rendering sixty times a second! To put this in perspective, most websites are unable to process and render sixty times a second despite doing far less work.

 

How do game developers accomplish these awesome feats? They gain a working knowledge of the environments their games run in and figure out how to take advantage of it to accomplish their goals.

More practically, they identify what makes it impossible for their code to reliably run sixty times a second. The source of the limitation is labeled expensive and they use their knowledge of the environment to create clever ways to workarounds.

As web developers we can learn a lot from this practice. We need to understand what keeps our websites from running smoothly and work around them.

1. CREATING, READING AND SEARCHING HTML IS EXPENSIVE

This is a thorny issue because it’s not a difficult problem to solve yet bad practices around this point abound.

Plugins, libraries and frameworks of all sizes get it wrong. They store information on DOM nodes. They’ll query the DOM repeatedly to access the same node. They do indiscriminate DOM insertions.

Touching the DOM for any reason is expensive. We can’t escape dealing with it, but we can follow a few rules to make sure our websites have a reliably good website performance.

a. Store DOM References

It’s ridiculously fast to access a JavaScript variable so if there’s an element you access multiple times, store a reference to it instead of querying every time you need it.

Instead of:

jQuery( window ).resize( function(){

  console.log( jQuery("#main-header").width() );

});

 

Try:

var dom_cache = {}

jQuery( window ).resize( function(){

  if( !dom_cache.main_header ) dom_cache.main_header = jQuery("#main-header");

  var main_header = dom_cache.main_header;

  console.log( main_header.width() );

});

b. Save State in JavaScript

Similar to the first point, make sure you don’t need to go to the DOM to get relevant application information.

Store it in JavaScript to make sure getting that information never affects the performance of your app.

Instead of:

jQuery( "#main-menu" ).click( function(){

  var is_menu_open = jQuery( this ).hasClass( "active" );

  if( is_menu_open ){

    // close it
  }

  else {

    // open it
  }

  jQuery( this ).toggleClass( "active" );
});

 

Try:

var state = {};

state.main_menu_open = false;

jQuery( "#main-menu" ).click( function(){

  var is_menu_open = state.main_menu_open;

  if( is_menu_open ){

    // close it
  }

  else {

    // open it
  }

  state.main_menu_open = !state.main_menu_open;
});

 

2. NETWORK REQUESTS ARE EXPENSIVE

You’d think because the internet is built on the concept of making network requests that it’s a cheap thing to do. It isn’t. Look at the network tab in your browser and you’ll quickly realize most of the time spent on a network request is initiating the request. Not processing your request. Not generating the response. Simply initiating.

To make matters worse, mobile devices are severely disadvantaged when making network requests yet they are the preferred way to browse. This means the way people want to browse isn’t actually optimized for browsing.

Two types of network requests and how to make them less expensive.

1. Page Load

Your HTML, CSS and JS all live in separate files. There’s a good chance different CSS live in different files. Same with JS. Great development practice, but not necessarily during deployment.

Use tooling to combine all your CSS into one file, your JS into another file then embed those goes into your HTML.

This technique reduces the amount of network requests your website needs to make to load up. It’s typically better to have one big request than many smaller ones.

Image sprites also reduce the network requests. Same with icon fonts. Even better might be SVGs since they’ll be inside your code, meaning one less network request.

2. AJAX Requests for Data

AJAX is a beautiful thing. Instead of loading up a whole page, get only the information you need and act on it. Since it is the better of two evils, developers feel they’ve done enough by choosing it. It’s a good step, but we can do better.

Store data that doesn’t change frequently in JavaScript or Local Storage.

This requires a bit of thinking to find out what’s safe to save and what isn’t. A trick is to determine the likelihood of data changing before that user requests it again.

For example if I create my music playlists in a webapp, it’s probably safe to save a copy on the user’s device because no other user can unexpectedly edit the playlist. You can avoid network requests while I’m looking through my playlists for what I want to hear.

BEING FRUGAL IS TOTALLY WORTH IT

The hardest part about avoiding expensive things is realizing what you’re doing is expensive. Once you realize that, there’s all sorts of options on how to skirt it. Finding which one fits you best is trivial.

In the end, everyone is the real winner when you take time to optimize things. Your site visitors, because of the enjoyable responsive web surfing experience. You, for providing a superior experience than most sites can.