JavaScript ou jquery : quel choix pour votre site web ?

Combien de fois par mois je tombe sur un site qui rame lamentablement parce qu’un prestataire a empilé trois versions différentes d’une même bibliothèque ? Beaucoup trop. Vraiment beaucoup trop. Pas plus tard que mardi dernier, j’auditais le site d’un commerçant basé près de Compiègne qui ne comprenait pas pourquoi ses pages mettaient quatre secondes à réagir sur smartphone. J’ouvre l’inspecteur réseau de Chrome : bingo. Une vieille version 1.12 de jQuery chargée dans l’en-tête, une version 3.6 injectée par un plugin de slider, et par-dessus le marché, trois scripts maison codés avec les pieds.

La question revient constamment sur la table : javascript ou jquery ? Pour beaucoup de gens, la frontière reste floue. Certains pensent encore que jQuery est un langage à part entière (non, pitié, arrêtez avec ça). D’autres s’imaginent qu’on ne peut pas manipuler un élément HTML sans appeler le fameux dollar $. On ne va pas se mentir : il est grand temps de remettre les pendules à l’heure et de regarder ce qui se passe sous le capot de nos serveurs et de nos navigateurs.

Pourquoi jQuery a régné sans partage sur le web pendant dix ans

Pour comprendre où nous en sommes, il faut se rappeler le bourbier qu’était le développement web au milieu des années 2000. J’ai commencé à coder à cette époque. Vous n’avez pas idée de la purge que représentait le support d’Internet Explorer 6 et 7 face à Firefox ou Safari. Écrire une simple requête asynchrone AJAX nécessitait vingt lignes de code verbeux avec des conditions pour instancier ActiveXObject sur IE pendant que les autres utilisaient XMLHttpRequest. Un cauchemar sans nom.

En 2006, John Resig a sorti jQuery comme une véritable bouffée d’oxygène. D’un coup, une seule ligne suffisait pour cibler un élément dans la page, lui coller un écouteur d’événement et envoyer des données en arrière-plan sans recharger la page. La syntaxe $('#mon-bouton').click(...) a sauvé la santé mentale de milliers de développeurs à travers la planète. jQuery gérait silencieusement tous les bugs d’incompatibilité entre navigateurs. C’était magique. Indispensable, même.

Toute l’industrie s’est jetée dessus. Les concepteurs de thèmes, les modules e-commerce, et surtout l’écosystème WordPress ont standardisé cette dépendance. À ce moment-là de l’histoire, la question javascript ou jquery ne se posait même pas : ne pas utiliser jQuery revenait à s’arracher les cheveux pour rien.

Ce qui a radicalement changé dans le JavaScript moderne

Les navigateurs ont arrêté de se faire la guerre en vase clos. Ils se sont mis autour d’une table avec le consortium W3C et le comité ECMA International pour standardiser le web. C’est là que le standard ECMAScript 2015 — le fameux ES6 — a tout balayé sur son passage. En l’espace de quelques années, le JavaScript natif (qu’on appelle souvent « Vanilla JS » dans le jargon) a comblé l’intégralité de son retard ergonomique.

Aujourd’hui, tous les navigateurs modernes intègrent nativement des méthodes ultra-puissantes que jQuery nous fournissait jadis. Vous voulez sélectionner un nœud HTML complexe ? La méthode querySelector sur le MDN fait exactement le même travail sans aucune surcouche logicielle. Vous devez faire un appel réseau ? L’API standard fetch() gère les promesses avec une clarté exemplaire. Le besoin d’une bibliothèque tierce pour unifier les comportements est mort le jour où Internet Explorer a été définitivement enterré.

Continuer d’embarquer une bibliothèque de 85 Ko juste pour masquer un menu déroulant ou ajouter une classe CSS, c’est l’équivalent technique d’utiliser un camion semi-remorque pour aller chercher une baguette de pain à 200 mètres.

Quand je conçois un site sur mesure dans mon agence web, je traque chaque milliseconde de temps de rendu. Le JavaScript moderne permet de coder propre, direct et rapide. Zéro intermédiaire. Le moteur V8 de Google ou SpiderMonkey sur Firefox exécutent le code natif à une vitesse que jQuery ne pourra jamais égaler.

Comparatif technique entre syntaxe native et syntaxe jQuery

Rien ne vaut des exemples concrets pour constater à quel point le code natif est devenu lisible. Regardons comment s’articulent les actions les plus fréquentes qu’on réalise sur une interface utilisateur.

Sélection d’éléments et manipulation de classes CSS

Avant, manipuler les classes CSS en JavaScript pur obligeait à découper des chaînes de caractères avec className. Aujourd’hui, l’API classList règle le problème de manière éclatante :

// Avec jQuery
$('#panier').addClass('ouvert');
$('#panier').removeClass('ferme');

// En JavaScript natif (Vanilla JS)
const panier = document.querySelector('#panier');
panier.classList.add('ouvert');
panier.classList.remove('ferme');

Est-ce que la version native est plus compliquée ? Pas du tout. Elle est explicite. Vous comprenez exactement ce qui se passe dans le document DOM, sans boîte noire.

Gestion des événements de clic

La gestion des événements était l’argument massue de jQuery avec sa méthode on(). Regardez comment nous écrivons la même logique aujourd’hui avec addEventListener :

// Avec jQuery
$('.btn-action').on('click', function(e) {
    e.preventDefault();
    console.log('Action déclenchée !');
});

// En JavaScript moderne
document.querySelectorAll('.btn-action').forEach(bouton => {
    bouton.addEventListener('click', (e) => {
        e.preventDefault();
        console.log('Action déclenchée !');
    });
});

C’est direct. C’est standard. Tout développeur qui ouvre votre fichier sait instantanément ce qui s’y déroule, sans avoir besoin d’apprendre la syntaxe spécifique d’un framework ou d’une librairie externe.

Requêtes asynchrones HTTP : adieu ajax(), bonjour fetch()

L’autre grand pilier historique de jQuery, c’était la méthode $.ajax(). Elle a rendu d’immenses services. Mais face à la syntaxe moderne async / await couplée à l’API fetch, elle prend un sérieux coup de vieux :

// En JavaScript moderne avec fetch et async/await
async function recupererArticles() {
    try {
        const reponse = await fetch('https://api.monsite.fr/articles');
        if (!reponse.ok) throw new Error('Erreur réseau');
        const donnees = await reponse.json();
        console.log(donnees);
    } catch (erreur) {
        console.error('Échec de la requête :', erreur);
    }
}

Aucun script supplémentaire à télécharger. Le navigateur comprend cette syntaxe de base, gère le flux en mémoire vive et libère les ressources instantanément dès que le traitement est terminé.

Performances pures et impact sur les Core Web Vitals

Pourquoi est-ce que je m’énerve autant contre l’usage abusif de jQuery sur mes hébergements o2switch ? Parce que la performance web n’est pas une simple lubie d’ingénieur obsédé par les chiffres. C’est le nerf de la guerre pour convertir vos visiteurs et plaire aux moteurs de recherche. Les robots de Google évaluent désormais l’interaction d’une page avec le score INP (Interaction to Next Paint).

jQuery pèse environ 30 Ko une fois compressé en gzip (et près de 85 Ko non compressé). Cela paraît ridicule sur une connexion fibre de bureau. Sur un réseau 4G instable au fond d’un village de l’Oise, c’est une autre histoire. Le smartphone de votre client doit faire trois choses coûteuses :

• Télécharger le fichier script via le réseau mobile, ce qui bloque le rendu visuel si la balise n’est pas différée.
• Analyser et compiler la bibliothèque (phase de parsing/compilation JavaScript), une étape qui bouffe des cycles CPU précieux sur les processeurs d’entrée de gamme.
• Exécuter les fonctions à travers plusieurs couches d’abstraction, ce qui rajoute de la latence à chaque clic utilisateur.

Chaque appel jQuery traverse une forêt de wrappers et de vérifications internes avant d’atteindre le moteur natif du navigateur. Le JavaScript pur, lui, tape directement dans l’API C++ interne du navigateur. Il n’y a aucun péage sur l’autoroute.

Quand vous travaillez sérieusement votre visibilité locale, notamment pour du référencement Compiègne ou sur n’importe quel marché concurrentiel, rogner 300 millisecondes sur le temps de blocage total du thread principal (Total Blocking Time) fait souvent la différence entre la première et la deuxième page de résultats.

Le cas particulier de WordPress : pourquoi jQuery y est encore scotché

Voici le paradoxe ultime que je gère chaque semaine. Si le JavaScript pur est tellement supérieur aujourd’hui, pourquoi jQuery est-il encore présent par défaut dans le cœur de WordPress ?

La réponse tient en un mot : rétrocompatibilité. L’équipe du projet WordPress a bâti son succès phénoménal sur le fait qu’un site codé il y a dix ans doit continuer de tourner après une mise à jour. Des dizaines de milliers d’extensions et de thèmes historiques utilisent encore des scripts jQuery pour faire fonctionner des accordéons, des formulaires ou des modales. Supprimer brutalement la bibliothèque du noyau casserait instantanément un tiers du web mondial.

Pourtant, dans les coulisses, les choses bougent. L’éditeur de blocs Gutenberg a été entièrement développé en JavaScript moderne (avec React). Le tableau de bord s’émancipe petit à petit de ses vieux scripts. Si vous montez un projet propre, votre stratégie WordPress ne doit pas consister à subir cette dette technique passivement. Il est tout à fait possible de désenregistrer le script jQuery sur la partie publique de votre site si votre thème et vos extensions n’en ont pas l’usage strict :

// À placer dans le fichier functions.php de votre thème enfant (si aucun plugin front ne l'exige !)
add_action('wp_enqueue_scripts', function() {
    if (!is_admin()) {
        wp_deregister_script('jquery');
    }
});

Attention tout de même : ne collez pas ce bout de code à l’aveugle sans tester. Si votre formulaire de contact ou le menu mobile de votre thème repose sur jQuery, vous allez tout casser. Une refonte de code exige d’auditer proprement chaque script actif.

Quand est-il encore acceptable de garder jQuery sur un projet ?

Je ne suis pas un intégriste du dogme technique. Mon métier consiste à livrer des sites rentables, sécurisés et fonctionnels pour mes clients, pas à réinventer la roue pour le plaisir de flatter mon ego de développeur. Choisir entre javascript ou jquery dépend aussi du contexte opérationnel et financier.

Garder jQuery reste parfaitement défendable dans deux situations bien précises :

• La maintenance d’une application existante volumineuse : si vous héritez d’un site e-commerce qui tourne depuis huit ans avec 15 000 lignes de code jQuery éprouvées, réécrire l’ensemble en JavaScript natif sans budget dédié serait stupide. Le risque de régression dépasse largement le gain de performance brut.
• L’utilisation d’un plugin jQuery ultra-spécifique sans équivalent : certains outils très pointus (comme des visualiseurs de plans de salles interactifs ou des tables de données complexes) disposent parfois d’un script jQuery parfaitement maintenu et irremplaçable à coût raisonnable.

En revanche, pour tout nouveau projet web, pour la création d’un thème sur mesure ou pour la refonte d’une vitrine professionnelle, lancer un projet avec jQuery relève de la faute professionnelle. Intégrez cette exigence dès la rédaction de votre cahier des charges pour éviter qu’un prestataire peu scrupuleux ne vous livre un site déjà obsolète le jour de sa mise en ligne.

Faut-il migrer votre code existant vers du JavaScript natif ?

Vous avez un site existant qui charge jQuery et vous vous demandez par où commencer ? Ne paniquez pas. On ne jette pas tout par la fenêtre du jour au lendemain. La bonne méthode consiste à opérer par étapes chirurgicales.

Commencez par ouvrir l’onglet Couverture (Coverage) dans les outils de développement de votre navigateur. Vous verrez immédiatement le pourcentage de code jQuery qui est réellement exécuté lors du chargement de votre page d’accueil. Souvent, moins de 10 % de la bibliothèque est sollicitée ! Tout le reste est du poids mort que vos visiteurs téléchargent pour rien.

Prenez ensuite vos scripts un par un. Le site communautaire You Might Not Need jQuery donne les équivalences natives directes pour chaque sélecteur ou animation. Remplacer un simple fondu fadeIn() par une transition CSS combinée à un basculement de classe native prend montre en main cinq minutes. Non seulement vous allégez vos pages, mais vous améliorez drastiquement la fluidité d’affichage sur les téléphones mobiles. Pour consolider vos bases SEO, c’est l’un des chantiers les plus rentables sur le plan technique.

Foire Aux Questions (FAQ)