Un site e-commerce qu’on auditait en 2015 utilisait encore jQuery Mobile 1.3.0. Le LCP mobile dépassait les 6 secondes. Pas à cause des images, pas à cause du serveur : à cause du framework, une surcouche de widgets qui balançait des centaines de nœuds dans le DOM avant le premier pixel utile. Dix ans plus tard, retrouver ce type d’architecture sur une page qui cherche à valider ses Core Web Vitals, c’est se tirer une balle dans le pied.
Quand la version 1.3.0 est sortie, on te vendait une solution unique pour tous les terminaux, un widget prêt à l’emploi pour chaque interaction tactile. La réalité, c’est qu’elle empilait du code d’initialisation qui retardait le First Contentful Paint dès qu’on dépassait trois pages.
jQuery Mobile 1.3.0, ou l’illusion d’un web mobile unifié
La promesse était belle : écrire une seule base HTML, laisser le framework transformer les listes en menus coulissants, les boutons en touches tactiles, les formulaires en composants adaptés. Avec la 1.3.0, jQuery Mobile introduisit un gestionnaire de navigation AJAX qui interceptait tous les clics pour éviter les rechargements complets. En apparence, l’expérience s’approchait du natif. En pratique, chaque page, même vide, embarquait un balisage enrichi à la volée qui produisait un DOM monstrueux avant que le navigateur ait le temps d’afficher quoi que ce soit.
À l’époque, on ne mesurait pas le LCP, et Google ne classait pas les sites mobiles en fonction du temps de chargement. Pourtant, la structure imposée par jQuery Mobile 1.3.0 rendait tout effort d’optimisation vain : le premier contenu utile apparaissait seulement après que le framework ait parsé le DOM, instancié les widgets, appliqué ses classes CSS et déclenché les events pagecreate. Sur un réseau 3G, la page restait blanche pendant plusieurs secondes. On nous vendait ça comme le prix à payer pour un rendu identique sur iOS, Android, Blackberry et Windows Phone.
Le piège du rendu 100 % JavaScript et son effet sur le LCP
Ouvre un DevTools aujourd’hui, lance un test de performance sur une SPA qui repose sur du rendu client exclusif, et tu verras immédiatement le goulet d’étranglement : tant que le bundle JavaScript n’est pas chargé, parsé et exécuté, le navigateur n’a rien à peindre. jQuery Mobile 1.3.0 suivait exactement ce modèle. Chaque page était une balise div avec un attribut data-role="page", complètement invisible jusqu’à ce que le runtime déclenche une série de mutations du DOM.
Ce qui était un défaut de conception en 2013 est devenu un handicap documenté avec l’arrivée des Core Web Vitals. Le LCP mesure le temps jusqu’au rendu du plus grand bloc de contenu visible dans la fenêtre d’affichage. Si le navigateur passe les 2 premières secondes à exécuter un script qui génère du balisage dynamique, le LCP explose, et aucune compression d’images ne le rattrapera. Les frameworks modernes ont intégré cette leçon en privilégiant le rendu côté serveur ou le rendu statique incrémental. jQuery Mobile, lui, restait figé sur une approche qui traitait le serveur comme un simple fournisseur de JSON et de HTML brut, sans jamais envisager l’idée d’un rendu progressif.
Sur l’audit de 2015, le passage en mode « page blanche » durait plusieurs secondes. Quand on a retiré la couche jQuery Mobile pour revenir à un rendu serveur classique avec un chargement progressif, le LCP a chuté de moitié. Pas grâce à un CDN plus rapide ni à un meilleur hébergement : juste en supprimant le code qui fabriquait la page dans le navigateur.
Widgets : le DOM qui enfle avant le premier pixel
Chaque widget ajoutait des wrappers, des span, des classes de thème. Un simple champ de saisie se retrouvait encapsulé dans une demi-douzaine de nœuds. Multiplié par 20 champs, le formulaire pesait plusieurs centaines de nœuds inutiles avant que l’utilisateur voie la moindre étiquette. Chaque reflow se paie deux fois.
Googlebot face à jQuery Mobile 1.3.0 : un désert indexable
En 2013, Googlebot exécutait peu de JavaScript, et certainement pas les couches complexes d’AJAX navigation que jQuery Mobile 1.3.0 utilisait pour charger dynamiquement les « pages » internes. Résultat : les URLs se résumaient souvent à une seule coquille vide, et tout le contenu affiché conditionnellement restait invisible pour les systèmes de classement. Les sites qui misaient sur ce framework perdaient l’essentiel de leur indexation, sans le savoir.
On a vu passer des migrations e-commerce assises sur cette version précise. robots.txt propre, canonical en place, et pourtant les pages produits cessaient de recevoir du crawl après la première passe. En cause : Googlebot voyait uniquement le squelette HTML initial, sans le contenu injecté par AJAX. Ceux qui défendaient encore le « tout JavaScript côté client » en 2015 se condamnaient à un déficit d’indexation invisible dans leurs courbes.
Aujourd’hui, Googlebot exécute JavaScript de façon bien plus robuste, mais le principe reste valable : si le contenu principal dépend d’une cascade d’appels AJAX déclenchés après le chargement de la page, le budget de crawl se dilue et le rendu indexé arrive trop tard. jQuery Mobile 1.3.0 a été l’un des exemples les plus frappants de cette impasse.
L’INP et le fantôme des event handlers tactiles
jQuery Mobile a toujours voulu résoudre le problème des délais de 300 ms sur les événements tactiles, que les navigateurs mobiles imposaient pour distinguer un tap d’un double-tap. La solution de la version 1.3.0 consistait à intercepter les événements touchstart et touchend pour simuler des clics instantanés. Ce hack, pertinent en 2012, crée aujourd’hui une couche de délégation d’événements qui freine l’Interaction to Next Paint.
Dès que vous touchez un élément d’interface, le navigateur doit traverser la pile d’event listeners, comparer les cibles, et attendre que le gestionnaire appelle event.preventDefault() si nécessaire. Sur un site qui a gardé cette logique (par exemple via un fork ou un plugin jQuery Mobile maintenu en interne), chaque interaction ajoute un délai de traitement perceptible. L’INP de ce type de page dépasse souvent 200 ms, même sur un appareil récent, simplement parce que la couche événementielle héritée n’est plus adaptée aux moteurs modernes.
Quand on migre ces vieux projets vers React ou Vue, la première chose qui disparaît, c’est ce mécanisme de simulation tactile. La gestion des événements est alors déléguée au navigateur, bien plus rapide. Tout le défi consiste à ne pas réintroduire le même défaut avec une surcouche de state management qui bloquerait l’hydratation. L’approche de Zustand, par exemple, évite les réconciliations inutiles et n’ajoute pas de listeners globaux qui ralentissent l’interaction.
Ce que la chute de jQuery Mobile nous apprend sur les frameworks modernes
Personne ne choisit aujourd’hui jQuery Mobile pour un nouveau projet. Pour autant, les réflexes qui ont mené à son adoption survivent : prendre un framework qui promet de tout gérer côté client, ignorer le coût du rendu initial, et découvrir trop tard que les Core Web Vitals sont hors seuil.
Les équipes qui utilisent Next.js, Remix ou Astro savent désormais qu’un rendu hybride est indispensable. Envoyer du HTML pré-rendu au navigateur, c’est la base. jQuery Mobile 1.3.0 ne proposait rien de tel : le rendu serveur pour un framework mobile n’était même pas sur le radar.
En parallèle, l’environnement de développement a radicalement changé. Là où on éditait du JavaScript dans un simple éditeur de texte, des outils comme Claude Code ou Cursor IDE intègrent aujourd’hui l’analyse de performance et la génération de code optimisé pour le LCP et l’INP. On mesure l’impact d’un composant directement dans le pipeline de CI, ce qui aurait évité bien des dérives à l’époque où on déployait un widget jQuery Mobile sans audit de performance.
L’héritage de jQuery Mobile 1.3.0, c’est l’exemple parfait d’un couplage fort entre logique de présentation et logique d’interaction, exécuté intégralement sur le thread principal du navigateur. Quand on conçoit une application mobile aujourd’hui, la question n’est plus « quel framework UI ? », mais « qu’est-ce qui est calculé côté serveur, qu’est-ce qui est hydraté progressivement, et combien de millisecondes séparent le premier octet du premier pixel interactif ? ».
Questions fréquentes
Faut-il encore utiliser jQuery Mobile 1.3.0 en 2026 ?
Non. jQuery Mobile n’est plus maintenu depuis plusieurs années et ne respecte pas les contraintes modernes de performance mobile. L’utiliser aujourd’hui expose à des problèmes de compatibilité avec les navigateurs récents et à des Core Web Vitals systématiquement hors seuil. Tout projet qui l’inclut devrait planifier une migration vers un framework orienté rendu hybride ou statique.
Par quoi remplacer jQuery Mobile pour une interface mobile accessible ?
Il n’existe pas de remplacement direct parce que le paradigme a changé. Aujourd’hui, on construit une interface mobile réactive avec React, Vue ou Svelte, couplée à du rendu côté serveur (Next.js, Nuxt, SvelteKit). Pour les formulaires et la navigation, les standards ARIA suffisent à garantir l’accessibilité sans surcouche widget.
jQuery Mobile 1.3.0 était-il compatible avec les normes d’accessibilité ?
La version 1.3.0 ajoutait des attributs ARIA de façon automatique, ce qui était louable pour l’époque. Cependant, elle générait un markup si complexe que les lecteurs d’écran perdaient la hiérarchie du contenu. Aujourd’hui, on privilégie une accessibilité pensée dès la conception, avec un DOM minimal et des rôles explicites, plutôt qu’un habillage automatique.
