The blog of , a Ruby on Rails development team

The performance impact of removing jQuery (with pictures)

I focus my open-source efforts on Unpoly, the unobtrusive JavaScript framework for server-side web applications.

In the past 18 months I was able to make signficant boosts to Unpoly's JavaScript performance. Improvements correlated so strongly with the incremental removal of jQuery that I felt compelled to share some pictures.

Step 1: All in jQuery

Here is a flame graph for following a link in Unpoly 0.37 at 6x CPU throttling without network latency. This version used almost every function in jQuery's kit. DOM manipulation, promises and AJAX were all tunneled through jQuery:

Performance trace for Unpoly 0.37.0

You see the green dots on the bottom right? That's when the browser starts painting pixels. Everything before that is just waiting for the JavaScript.

Step 2: Native AJAX and Promises

This is Unpoly 0.50. It uses native APIs for AJAX and Promises, but still tunneled all DOM access through jQuery. Note how average stack depth has decreased significantly, but we didn't gain a meaningful performance boost:

Performance trace for Unpoly 0.50.0

Step 3: Slow functions removed

This is Unpoly 0.56. This version has been optimized as far as I knew how to, without removing jQuery entirely. Although jQuery is still used to manipulate elements, some slow jQuery functions like show(), hide(), css(), addClass() and removeClass() were replaced with their native counterparts:

Performance trace for Unpoly 0.56.0

Note that some of the improvements from 0.50 to 0.56 were realized by optimizing my own code, and were unrelated to jQuery. However, I ran into a glass ceiling here. Everything that could be optimized had been optimized. The only way to become faster was to remove jQuery.

Step 3: jQuery removed

Today I released Unpoly 0.60, which no longer uses jQuery:

Performance trace for Unpoly 0.60.0

It is not my intention to demean jQuery in any way. I've been an avid user for 10 years and I still work with it every week. And while the native DOM API has made great progress, it still can't compete with jQuery's productivity in many areas. But if you want to perform well, especially on mobile devices, you should take a look at where your CPU spends its cycles.

Growing Rails Applications in Practice
Check out our e-book:
Learn to structure large Ruby on Rails codebases with the tools you already know and love.

Recent posts

Our address:
makandra GmbH
Werner-von-Siemens-Str. 6
86159 Augsburg
Contact us:
+49 821 58866 180
Commercial register court:
Augsburg Municipal Court
Register number:
HRB 24202
Sales tax identification number:
Chief executive officers:
Henning Koch
Thomas Eisenbarth
This website uses cookies to improve usability and analyze traffic.
I accept or learn more