Video: Profiling JavaScript Performance in Chrome

By Tim Evko

In this video, I’ll dive into the Chrome Developer Tools Profiler and demonstrate how we can use it to analyze the performance of JavaScript running in the browser.

Loading the player…

  • These videos don’ work on Chrome, I need to use Firefox

    • Tim

      Hey Alex, what platform are you using? I’ve been able to access this video from Chrome on Mac and PC

      • I’m on Mac & Chrome (Version 44.0.2403.107 (64-bit)) too

        Here’s what happens

        • LouisLazaris

          Welcome to the web. :)

          That could possibly be a temporary server issue or even a network issue on your side. I saw the same thing on Chrome here, but it loaded after a few seconds and it was fine. Likely just a temporary glitch somewhere.

          • I don’t think so, it’s still not working, and is was happening with other videos too on this website, I think it’s worth investigating maybe.

          • Angela Molina

            Thanks Alex! We’ll be looking into this issue further.

          • Erica Wass

            Hi Alex, thanks for letting us know! Do you think you could email our support team at so that we can work with you to debug this with our system setup?

          • Done :)

    • ThomFoolery

      Player is not loading for me either, so I can’t watch the video. I’m seeing four 403’s erros in the console.

  • Mike Badgley

    This video wold have been a lot more helpful if you showed examples of real code slowdowns instead of just using third-party libraries as your examples. In other words, show code on your own site that is slow and then how your updates/fixes made a difference (to the overall profile report).

    I mean, with the example you showed your just guessing what the slowdowns are, right?

    • Tim

      Hey Mike, thanks for the feedback! In my experience, real code slowdowns are very often due to 3rd party resources. In the case of ticketmaster, the fix would be to pull the third party service out, and reimplement (if possible). When doing performance audits on websites that you didn’t build, your findings are often only as good as the tools you’re using. In this case, we didn’t get a ton of helpful information, but we were able to pinpoint what file the issues were occurring in. This information would be very helpful to the developers of the site, who could then pinpoint what the file was responsible for, and fix as needed.

  • gonchuki

    So, what about the s.c_r function? Because that’s where 1.2s are being spent, not sure why you focused on the sub-200ms slowdowns.

    • ld0rman

      That’s what I was thinking the whole time

  • Mike

    This was pretty interesting but I agree with Mike Badgley. It seemed like all you did was show how to identify where a try-catch was producing unoptimized code and how to find which file was doing that. Didn’t do much in terms of performing an in-depth performance analysis. Suggesting swapping out a slow 3rd party library for something faster isn’t really helpful.

Get the latest in Front-end, once a week, for free.