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.

Imagine how much code is powering this League of Legends fight


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.


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:



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:





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.


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.

Get New Posts via Email

I don't always post, but when I do, you can get it sent directly to your inbox.

Join 16 other subscribers

  • Did you mean 60FPS (Frames Per Second) by 60 times a second. It got a little confusing. You made good points but about embedding SVG as a way to reduce requests if you have a lot of embedded SVG then it’d be at the cost of your HTML file size. What I do instead is sprite my SVGs and make a single request to them. SVG sprites are even more awesome than raster image sprites

    • You’re correct: I meant 60 FPS.

      I figured 60 times a second might be more clear than 60 FPS if you’re not a gamer or game dev.

      I think a big single request is better than multiple small ones simply because there is an expensive time cost to making multiple network requests.

      Honestly I haven’t done much with SVGs, so tooling and optimizations around them are definitely not yet in my bag of tricks.

      How do you do SVG sprites?

      • If you check out http://kovalc.in It was developed by Chris Coyier and although it’s a great use there but he added the sprite right in the HTML which I wouldn’t recommend but that’s an example there. If you see my website http://strich.io I loaded the sprite into the DOM but not directly in the HTML which I think is the better approach towards it. Although I also didn’t do it asynchronously there which causes for the warning in the console. But the idea is use defining the SVG icons in within a large element. You can use for each of them under but is recommended and to use them in the code where there is a you simply can use as

  • Adim Ofunne

    Great post! I totally agree game developers are highly under-rated and they probably get paid the worst too when you think of developers in big corps like EA as supposed to developers at google. Also I am sure you already know but React was inspired by gaming engines so some frameworks/libraries are getting it right 🙂

    My one criticism with this post though is that the code samples you gave directly contradict the post you have before this one “Writing code for clarity” for example if you look at the first block of code for “Store DOM References” on the same line as the “if” statement you are assigning a variable in a JSON. I assume that is your else statement, which runs if the variable is not set. I know reading code for you now is like reading english but considering you did not even put comment for us mere mortals, use standard “If, else” statement or comment on the “{}” as a JSON, abeg oh remember us. LOL, how are we supposed to copy and paste your code when it is looking like Master Wun Lee wrote it and it is above our comprehension?

    LOL im just giving you shit, but you know if I don’t who will. LOL

    • Oh noooo it’s not like that at all.

      I probably should have used braces to make it more clear, but it was a cache check.

      If this element isn’t cached, find and cache it now.

      There is no else clause; it’s just an additional step in the procedure if a condition isn’t met.

      • Adim Ofunne

        I see you cannot help it. Isn’t that what an else clause is? “If a condition isn’t met”? LOL now your calling it “cache check” how are we supposed to google that? LOL

        You are just falling victim to my wahala today!

        • I don’t think it’s wahala though.

          I’m trying to make things as clear as possible so anything to improve it is definitely help, not trouble-making.

          is the line of code you’re talking about this:

          If so, it’s equivalent to this:

          How would you suggest I make my intent clearer here?

          • Adim Ofunne

            My Bad I totally misread that conditional statement. You wrote a one line IF statement and I misread it and thought you had an if and else. My bad. The braces would solve the clarity you are correct.

            Only other suggestion is negating an empty variable requires you to understand if js returns it as null or undefined or 0 so if you made the if statement

            if( dom_cache.main_header == undefined){

            dom_cache.main_header = jQuery(“#main-header”);


            You can argue it is “clearer” but I don’t know if I am being anal or if that is valid for clarity even though it is longer. Dont get me wrong I would have written the code you wrote above the same way you did but I am also on a quest to write that clearer code too

          • Hmmm. I see what you’re getting at.

            How about this?

          • Adim Ofunne

            I think that is VERY clear!

          • What’s amazing is I still use this technique.

            Very satisfied with this making schema. Code’s very clear.