We are a group of volunteers who review and approve themes submitted to be included in the official WordPress Theme directory.
We do license, security, and code quality reviews.
We help build and maintain default themes.
The primary focus of the team is to help theme authors transition to blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.-based themes.
While it has been widely known that you might not need jQuery for most of your interactive theme features, jQuery is still a common JavaScriptJavaScriptJavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. dependency found in WordPress themes – for example, 7 out of the 11 default themes since Twenty Ten are using jQuery in the frontend. jQuery has been bundled in WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. for more than a decade, and it has been the most used JavaScript library across the web for a long time. However, it became popular when browsers were still very inconsistent in their JavaScript implementations and feature sets, and jQuery made it easy to navigate that. But the browser landscape has significantly improved over the past decade, and as of today there is little benefit of using jQuery, especially when using just jQuery core. If you are using jQuery UIUIUI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. or other extensions that provide user-facing features, migrating away is likely to be more complicated – but it is still worth looking into lighter non-jQuery alternatives for those libraries.
Using jQuery in WordPress themes may not seem like a problem from that perspective – after all, it still offers some useful utility functions, and some developers may be more familiar with using jQuery than with vanilla JavaScript. However, there is a real negative performance impact from using jQuery, which is especially relevant when using it for the frontend of a website where it can harm end user experience. Since the frontend of a WordPress site is primarily driven by themes, they play a substantial role in eliminating this performance offender.
You may be familiar with the recommendation to not use jQuery for performance reasons, but maybe you haven’t seen any evidence yet. To dive deeper into the topic, I recently conducted an at-scale analysis looking at popular WordPress themes, to see whether jQuery is in fact a notable performance offender or whether it is all just some myth – TL;DR it has a significant negative impact on performance. In this article I will share the results of the analysis and outline ways to reduce usage of jQuery in WordPress themes, so that we can enhance performance across the web.
jQuery is the most common JavaScript-based performance problem in themes
I ran an analysis using the PageSpeed Insights API, gathering performance reports for the most popular 100 WordPress themes according to the wordpress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ Themes APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.. The first interesting aspect to look at was finding out how many themes of those even use jQuery and whether it is in fact as widely used as believed. And yes, the reports flagged jQuery as by far the most notable JavaScript file that leads to performance issues, in 76 of the 100 themes. The table below shows the most flagged WordPress core JavaScript files commonly loaded by themes.
#
WordPress core JS file
Number of themes flagged out of 100 themes tested
1
/wp-includes/js/jquery/jquery.min.js
76
2
/wp-includes/js/jquery/jquery-migrate.min.js
31
3
/wp-includes/js/comment-reply.min.js
14
4
/wp-includes/js/jquery/ui/effect.min.js
5
5
/wp-includes/js/imagesloaded.min.js
3
6
/wp-includes/js/jquery/ui/core.min.js
2
7
/wp-includes/js/masonry.min.js
1
Looking at these results, there are barely any common JavaScript offenders in themes except for jQuery. Of course this doesn’t mean that jQuery is the worst performance offender of them all, but it shows that it is a significant common problem, which can be fixed.
jQuery usage in themes correlates with worse LCP performance
After establishing that jQuery is a common performance problem, the next step was to quantify how bad its negative impact actually is. For this purpose I inspected the Core Web Vitals (CWV) metrics results for each theme, most importantly the Largest Contentful Paint (LCP) metric, which focuses on loading performance. Across all the 100 themes, the average LCP value of themes using jQuery is 65.6% worse than for themes without jQuery (4,585.14ms for jQuery themes vs 2,769.74ms for non-jQuery themes, a lower value meaning faster loading performance). Of course jQuery is by far not the only aspect that factors into LCP, and the performance between different themes varies greatly. Yet, the at-scale analysis shows a clear correlation indicating that removing jQuery from a theme will bring a performance boost.
It may be argued that themes using jQuery may only be slower because their interactive features are more complex or extensive than those in themes without jQuery. While this is partly true, looking at the byte weight cost of JavaScript flagged by the performance reports shows that for many themes the problem really is jQuery itself: In 48 out of the 76 themes using jQuery, the cost of jQuery is even higher than the cost of all other JavaScript combined. This is summarized in the figure below: On the left it has the themes with the highest amount of non-jQuery JavaScript code, where the relative cost of jQuery is less extreme, but this applies only to a few themes – for most themes, the cost of jQuery is higher than the cost of all other JavaScript code combined.
Removing jQuery may lead to 80% less JavaScript load
The at-scale analysis already shows how substantially jQuery usage can affect performance, specifically in themes where it is loaded only for a couple of rather basic interactive features. In order to get a better idea of what this means in practice, I took a deeper look at two of those simpler themes in regards to interactivity, choosing the default WordPress themes Twenty Twelve and Twenty Fifteen. I modified all their frontend JavaScript files that depend on jQuery (1 for Twenty Twelve, 2 for Twenty Fifteen) to use vanilla JavaScript and then eliminated jQuery as a dependency so that it is not loaded. Those code changes can be found in two new WordPress core pull-requests, for Twenty Twelve and for Twenty Fifteen.
After modifying the theme, I ran comparison reports for both of them, with 6 test runs for each in order to get more accurate median results for the metrics. The results showed that the JavaScript byte weight of both themes gets reduced by more than 80% when not using jQuery (for Twenty Twelve it dropped from 47,797 to 7,457 byte, for Twenty Fifteen it dropped from 49,290 to 9,120 byte). The median LCP impact for the two themes is not as huge as when looking at the average difference between all themes (1.2% better for Twenty Twelve, 8.4% better for Twenty Fifteen), but it still showed as a consistent improvement across all test runs when not using jQuery.
Using vanilla JavaScript instead of jQuery
As mentioned before, especially using jQuery without any of its extensions as of today does not justify the negative performance impact its usage comes with. In fact this applies quite widely as 52 out of the 76 themes tested that use jQuery don’t use any of its extensions. jQuery extensions often offer complex features that may require a lot of code to manually recreate, but for themes that only use jQuery itself, migrating to use vanilla JavaScript instead should be a rather straightforward effort. This can be seen when looking at the WordPress default themes for example: The older themes (up to Twenty Seventeen) have been relying on jQuery for their frontend features, while the newer ones (starting with Twenty Nineteen) do not load jQuery in the frontend – a positive development, which also shows how little benefit jQuery provides for those scenarios, as the newer default themes in no way lag behind the older ones in its interactive features.
If you are developing a new theme or maintaining an existing theme that currently relies on jQuery, consider using vanilla JavaScript instead, especially if you do not intend to use any jQuery extensions. Websites like youmightnotneedjquery.com or posts like “Cheat sheet for moving from jQuery to vanilla JavaScript” are an excellent starting point for developers that would like to migrate code away from jQuery or that are more familiar with jQuery than vanilla JavaScript.
To provide a concrete example, a common JavaScript-based WordPress theme feature is using a button to toggle the navigation menuNavigation MenuA theme feature introduced with Version 3.0. WordPress includes an easy to use mechanism for giving various control options to get users to click from one place to another on a site. in mobile viewports. The example code below is inspired by how a lot of themes implement that behavior with jQuery, and below you find the same functionality using vanilla JavaScript.
For more concrete and real-world examples, feel free to inspect the aforementioned pull-requests to remove jQuery from Twenty Twelve and from Twenty Fifteen.
Migrating away from jQuery extensions
If you are using jQuery extensions, for example anything based on jQuery UI, migrating away may be less trivial, depending on the complexity of the feature that the extension provides. You may want to research alternatives not based on jQuery that offer similar functionality – if there is one that satisfies your needs, it may be worth migrating your codebase to it, as jQuery still adds some overhead compared to using vanilla JS. For example, Twenty Thirteen relies on jQuery-based Masonry, but it could easily use vanilla JS-based Masonry instead. It should be evaluated on a case-by-case basis though – for some complex use-cases replacing jQuery may not be feasible. Or it may not be worth the effort, for example if the vanilla JS extension that would replace the jQuery extension and jQuery core is not notably smaller or more performant. Yet, not using jQuery can always be considered the general recommendation.
Potential next steps in reducing jQuery usage
If you are a theme developer relying on jQuery, starting to look into migrating away from jQuery in your themes will be a great step to make your themes more performant and thus enhancing the user experience for all the sites that use your themes. From a WordPress core perspective, there are a number of work streams that could reduce the usage of jQuery over time, one of them being to migrate all the older WordPress default themes away from using jQuery in the frontend, which has already started as part of the analysis, with a Trac ticket for Twenty Twelve and another ticket for Twenty Fifteen. Potentially WordPress Coding Standards PHPCS rules or the WordPress theme checker could be enhanced to warn about usage of jQuery, making clear that it is discouraged. Maybe further down the road jQuery could even be marked as deprecated in WordPress core? 🙂 Let’s not get carried away, but if not before, now is a great time to start replacing jQuery with vanilla JavaScript in your WordPress themes (and plugins too, if you use it there). If you have alternative ideas, questions, or concerns, please share them in the comments.