Benchmarks WebKit JIT 2026 : quatre ans après le mode Verrouillage

Table des matières

• Primer JIT : comment fonctionne JavaScriptCore
• Pourquoi le JIT est un compromis de sécurité
• Mode Verrouillage 2022 : la référence
• Améliorations JIT WebKit 18.x 2024–2026
• Benchmarks frais 2026 : normal vs mode Verrouillage
• Comparaison : V8, SpiderMonkey, JavaScriptCore 2026
• Le cas pour une navigation sans JIT
• FAQ

Primer JIT : comment fonctionne JavaScriptCore

L'exécution de JavaScript dans WebKit ne suit pas un chemin unique. JavaScriptCore (JSC) — le moteur JavaScript d'Apple qui alimente Safari et tous les navigateurs sur iOS — utilise un pipeline d'exécution à quatre niveaux, chaque niveau échangeant le coût de démarrage contre un débit de pointe.

LLInt (Low-Level Interpreter) exécute le bytecode directement. Il démarre rapidement, ne nécessite aucune génération de code machine, et n'expose aucune surface d'attaque spécifique au JIT. Chaque fonction commence ici.

Baseline JIT compile le bytecode en code machine natif avec une optimisation minimale après qu'une fonction a été exécutée un certain nombre de fois (le "seuil de préchauffage"). Il produit rapidement du code machine non optimisé — généralement en quelques microsecondes — et élimine la surcharge de l'interpréteur pour les fonctions fréquemment appelées.

DFG (Data Flow Graph) JIT intervient après qu'une fonction a été exécutée beaucoup plus de fois. Il construit un graphe de flux de données du programme, infère les types et applique des optimisations classiques du compilateur : élimination de code mort, propagation de constantes, inline caching et allocation de registres. Le résultat est du code natif substantiellement plus rapide que ce que produit le Baseline JIT.

FTL (Faster Than Light) JIT est le niveau supérieur. Il utilise la compilation B3 (Bare Bones Backend) dérivée de LLVM pour les chemins de code les plus sollicités. Les sorties FTL approchent les performances du C compilé sur les workloads à forte intensité de calcul et constituent la principale raison pour laquelle Safari domine certains benchmarks de débit de pointe sur Apple Silicon.

Le processus de montée en niveaux est transparent pour le développeur. JSC surveille les compteurs d'exécution et promeut les fonctions vers des niveaux supérieurs selon les besoins. L'effet pratique : les applications JS de longue durée (SPA complexes, jeux, visualisation de données) bénéficient énormément de DFG et FTL, tandis que les scripts courts peuvent ne jamais quitter LLInt.

Le mode Verrouillage supprime tout cela au niveau Baseline. Lorsque le mode Verrouillage est actif, JSC revient à l'exécution par interpréteur uniquement. Les fonctions ne montent jamais en niveau. Le plafond de performance chute brutalement.

Pourquoi le JIT est un compromis de sécurité

La compilation JIT est le sous-système le plus complexe de tout moteur JavaScript et historiquement le plus exploité. Le problème fondamental : les compilateurs JIT génèrent du code machine natif exécutable à l'exécution à partir d'entrées contrôlées par l'attaquant (le JavaScript). Tout bug dans le pipeline JIT qui permet à un attaquant d'influencer le code machine généré est potentiellement une vulnérabilité d'exécution de code à distance.

Historique des CVE dans le JIT WebKit (2020–2026)

Le schéma est cohérent sur la fenêtre de six ans :

• 2020 : Le JIT WebKit était impliqué dans plusieurs CVE dans des zero-days iOS signalés dans la nature. Le tarif Zerodium pour les exploits full-chain WebKit iOS atteignait 500 000 $ — un indicateur de la valeur de la surface d'attaque.
• 2021 : Project Zero a publié des recherches sur les bugs de confusion de type JSC déclenchés via le tier DFG — spécifiquement autour du chemin de spéculation NumberToString. Deux d'entre eux ont été weaponisés dans des chaînes d'exploits iOS.
• 2022 : iOS 16 a livré le mode Verrouillage. Les notes de sécurité d'Apple pour cette année listaient 14 vulnérabilités WebKit, plusieurs impliquant le JIT. Le mode Verrouillage a été explicitement conçu pour neutraliser la surface d'attaque JIT.
• 2023 : CVE-2023-23529 (exploité dans la nature, signalé par Clément Lecigne de Google TAG). Confusion de type WebKit, adjacent au JIT. Corrigé dans Safari 16.3.1, iOS 16.3.1.
• 2024 : CVE-2024-23222 — confusion de type JSC, exploité dans la nature avant le patch. Un schéma qui s'est reproduit trois autres fois dans l'année civile.
• 2025–2026 : Les listes de brokers d'exploits pour les exploits iOS full-chain WebKit se sont stabilisées à 2–3 M$ sur les marchés majeurs (Zerodium, brokers privés), reflétant que si le durcissement a augmenté les coûts, le JIT reste économiquement attractif pour les outils étatiques.

Mécanique du JIT spray

Le JIT spray est une technique d'injection de code qui intègre des séquences d'octets choisies par l'attaquant dans le code compilé JIT. En élaborant du JavaScript utilisant des constantes en virgule flottante ou des valeurs immédiates spécifiques, un attaquant peut faire en sorte que le compilateur JIT émette des séquences d'octets qui, interprétées à un décalage, constituent du shellcode valide.

Les atténuations modernes appliquées par WebKit comprennent :

• Gigacage : un système de région de garde qui isole la mémoire JIT de la mémoire tas, rompant les hypothèses de l'attaquant sur la disposition de la mémoire.
• Durcissement JIT probabiliste : insertion aléatoire d'instructions de trap entre les blocs de code.
• Gating des droits JIT : sur iOS, le droit dynamic-codesigning est requis pour créer des pages mémoire accessibles en écriture et exécutables. Seuls les processus disposant des droits JIT peuvent le faire — limitant le rayon de souffle si le JIT est exploité dans un processus navigateur sandboxé.
• Execute-only (XOM) : sur le matériel A15+, les pages mémoire JIT sont marquées execute-only, empêchant l'attaquant de lire la sortie JIT pour localiser le shellcode.

Malgré ces atténuations, le JIT reste la cible la plus précieuse dans l'exploitation des navigateurs mobiles. Le désactiver entièrement — comme le fait le mode Verrouillage — supprime la surface d'attaque plutôt que de tenter de la durcir.

Mode Verrouillage 2022 : la référence

Lorsqu'Apple a introduit le mode Verrouillage dans iOS 16 (septembre 2022), le compromis JIT était immédiat et mesurable. Les tests sur un iPhone 13 au lancement ont produit les résultats suivants sur les benchmarks standards de l'époque :

L'effondrement d'Octane était le plus spectaculaire : Octane est presque entièrement un test de débit JIT, donc la réversion à l'exécution par interpréteur uniquement a détruit le score. Speedometer 2.0, qui exercice les interactions DOM et le rendu de frameworks en plus du débit JS, a montré une baisse plus modérée mais encore sévère.

MotionMark — qui teste les animations CSS, le rendu SVG et le canvas — a relativement bien résisté car il dépend moins de la vitesse d'exécution JS et davantage des chemins de composition GPU, que le mode Verrouillage ne désactive pas.

Cette référence 2022 était importante : elle a fixé un plancher de performance concret pour WebKit sans JIT sur du matériel réel, et elle est devenue le point de référence contre lequel toutes les améliorations JIT WebKit ultérieures seraient mesurées.

Améliorations JIT WebKit 18.x 2024–2026

Quatre ans de développement séparent le lancement du mode Verrouillage iOS 16 d'aujourd'hui. L'équipe WebKit a livré des améliorations significatives à la fois aux performances JIT et à la sécurité JIT, affectant les deux modes d'opération.

Démarrage plus rapide et montée en niveaux dans iOS 17–18

iOS 17 a introduit un Baseline JIT mis à jour avec une surcharge de compilation réduite. Le seuil de préchauffage a été ajusté pour faire monter les fonctions en niveaux plus rapidement pour les workloads web courants. En pratique, les applications single-page qui nécessitaient auparavant de nombreuses itérations de fonctions pour atteindre DFG le font maintenant plus tôt, réduisant l'écart de performance "cold start" entre Safari et les applications natives.

iOS 18 a étendu cela avec des hints de préchauffage guidés par profil stockés dans le cache partagé dyld de WebKit. Les patterns courants de frameworks JavaScript (chemins du réconciliateur React, réactivité interne de Vue) sont pré-préchauffés, réduisant la rampe JIT au premier chargement pour les frameworks web populaires.

Durcissement DFG et FTL

Le JIT DFG a reçu des changements significatifs à son système d'inférence de types spéculatifs. Les conclusions de Project Zero de 2021 ont conduit à une refonte de la gestion des spéculations de type aux frontières de niveau par JSC. Le système AbstractValue — qui suit quels types une valeur peut contenir au moment de la compilation — a été durci pour rejeter les chemins spéculatifs qui pourraient mener à une confusion de type, même au prix d'occasionnelles désoptimisations.

FTL a reçu des mises à jour de l'allocation de registres et de la sélection d'instructions de B3, offrant des gains de débit modestes (estimés à 5–8 % sur les workloads JS purs JetStream 2 sur A17 Pro vs A15 sous iOS 16) indépendamment des changements d'architecture.

Améliorations de l'interpréteur affectant le mode Verrouillage

Cela est directement pertinent pour les utilisateurs du mode Verrouillage. L'interpréteur de bytecode LLInt — le seul niveau de moteur disponible en mode Verrouillage — a reçu plusieurs séries d'optimisations :

• Fusion de superinstructions : les séquences de bytecode courantes (chargement + comparaison + branchement) sont fusionnées en opcodes LLInt uniques, réduisant la surcharge de dispatch.
• Intégration du cache inline au niveau de l'interpréteur : le système IC de JSC a été partiellement étendu dans LLInt pour les accès aux propriétés, réduisant la pénalité pour les lectures de propriétés d'objets en mode interpréteur.
• Restriction WASM en mode Verrouillage : WebAssembly reste désactivé, mais le chemin de validation et de compilation WASM qui s'exécutait auparavant de manière eager a été restructuré de sorte que l'absence de WASM en mode Verrouillage n'introduise plus de délais de démarrage.

L'effet net : les performances du mode Verrouillage sur Speedometer 3.0 sont significativement meilleures en 2026 que ce que les chiffres Speedometer 2.0 suggéraient en 2022, même en tenant compte des différences de méthodologie des benchmarks.

Benchmarks frais 2026 : normal vs mode Verrouillage

Les tests ont été effectués sur iPhone 15 (A16 Bionic, 6 Go de RAM) et iPhone 16 (A18, 8 Go de RAM) sous iOS 18.4, avec Safari 18.4. Chaque benchmark a été exécuté cinq fois par configuration, l'appareil en mode avion et le mode économie d'énergie désactivé. Les scores médians sont rapportés.

Scores des benchmarks : JIT activé vs JIT désactivé (mode Verrouillage) sur le matériel Apple actuel.

Speedometer 3.0

Speedometer 3.0 a remplacé Speedometer 2.0 comme benchmark de performance cross-browser principal. Il teste un plus large éventail d'interactions avec des frameworks JavaScript (React, Vue, Ember, Svelte, DOM pur) et est un proxy plus réaliste des performances des applications web réelles que les tests de débit pur.

L'écart est réel et cohérent — environ un tiers des performances. Mais comparez cela à l'écart Speedometer 2.0 de 2022 de ~65 % : les améliorations de l'interpréteur, les extensions du cache inline et la fusion de superinstructions ont matériellement réduit le déficit.

JetStream 2

JetStream 2 est explicitement un benchmark de débit JS de pointe. Il inclut des workloads asm.js, des tests de latence et des tests de débit de pointe, qui bénéficient tous massivement de la compilation DFG et FTL. Ce benchmark montre la division la plus marquée.

L'écart JetStream a à peine bougé depuis 2022. C'est attendu : JetStream est conçu pour stresser précisément les niveaux d'optimisation que le mode Verrouillage supprime. Les améliorations de l'interpréteur aident la navigation ordinaire mais ne peuvent pas compenser l'absence de DFG/FTL dans les workloads à forte intensité de calcul.

MotionMark 1.3

MotionMark teste le débit de rendu : transformations CSS, animation SVG, composition canvas et effets de filtre. La majeure partie de ce workload s'exécute sur le pipeline de composition GPU, pas sur le moteur JS.

L'écart de ~16 % est plus faible qu'en 2022 (qui était ~20 %), suggérant que les améliorations du pipeline GPU bénéficient également aux deux modes. Pour les utilisateurs dont la navigation principale implique des pages riches en médias mais légères en JS, le mode Verrouillage représente un coût de rendu tolérable.

Chargement de pages réel (moyenne géométrique, 50 sites Alexa)

Les scores de benchmark purs ne se traduisent pas toujours directement par une vitesse perçue par l'utilisateur. Un test de chargement de pages supplémentaire en utilisant une méthodologie équivalente à WebPageTest sur les 50 sites les plus fréquentés par trafic a montré :

Dans la navigation réelle, l'écart se traduit par un délai perceptible mais pas débilitant — environ une demi-seconde sur le Time to Interactive. Pour les utilisateurs soucieux de leur confidentialité, c'est probablement un coût acceptable. Pour un usage quotidien, c'est une friction constante.

Comparaison : V8, SpiderMonkey, JavaScriptCore 2026

WebKit ne fonctionne pas en isolation. Deux autres moteurs JavaScript majeurs rivalisent sur les mêmes suites de benchmarks et ciblent des matériels qui se recoupent.

Comparaison d'architecture de moteurs JavaScript : JSC, V8 et SpiderMonkey font chacun des compromis différents entre vitesse de démarrage, débit de pointe et durcissement de sécurité.

V8 (Chrome, Edge)

V8 utilise une architecture JIT à deux niveaux : Sparkplug (Baseline, démarrage rapide) et TurboFan (optimisation, haut débit), avec Maglev comme niveau intermédiaire ajouté en 2023. Sur le matériel Android (Snapdragon 8 Gen 3), V8 avec Maglev affiche des scores Speedometer 3.0 compétitifs avec JSC sur Apple Silicon, mais le débit de pointe JetStream 2 favorise JSC sur le matériel A18 d'environ 10 à 15 %.

La posture de sécurité de V8 a également évolué : le bac à sable V8 (finalisé en 2024) isole le tas JIT du tas du processus navigateur, créant une couche de confinement analogue au Gigacage de JSC. V8 n'offre pas de mode "JIT désactivé" pour les utilisateurs finaux comparable au mode Verrouillage iOS.

SpiderMonkey (Firefox)

SpiderMonkey utilise une approche à trois niveaux : un interpréteur de base, un Baseline JIT et IonMonkey (optimisation). Mozilla a investi massivement dans le durcissement de sécurité — Warp (le système d'inférence de type actuel remplaçant IonIR) a été conçu avec la sécurité comme objectif co-égal à la performance après une série de CVE JIT en 2019–2021.

Firefox sur bureau n'expose pas de bascule de désactivation JIT aux utilisateurs. javascript.options.jit.content peut être mis à false dans about:config, et SpiderMonkey reviendra à l'interpréteur de base — analogue à l'effet du mode Verrouillage sur JSC. La dégradation des performances sur ce chemin reflète le tableau JSC : sévère sur JetStream, modérée sur Speedometer.

Résumé Speedometer 3.0 cross-moteur (bureau, matériel comparable)

JSC sur Apple Silicon mène sur Speedometer 3.0, probablement parce que les workloads du benchmark se recoupent avec les patterns qu'Apple a spécifiquement optimisés dans FTL et dans le moteur de mise en page WebKit. SpiderMonkey de Firefox est en retrait d'une plus grande marge, en partie en raison de différences de moteur de mise en page au-delà du seul débit JS pur.

Sur iOS spécifiquement, seuls les scores JSC sont pertinents — Chrome et Firefox sur iOS 18 utilisent toujours WebKit sous le capot, donc leurs performances JS égalent celles de Safari en pratique.

Le cas pour une navigation sans JIT

Quatre ans plus tard, la question de savoir qui devrait utiliser le mode Verrouillage est devenue plus nuancée — pas moins.

L'argument de sécurité reste solide. Des CVE JIT WebKit continuent d'apparaître en 2025–2026. Le marché commercial des exploits valorise les exploits iOS full-chain WebKit à sept chiffres, indiquant un investissement attaquant soutenu. Désactiver le JIT supprime la surface d'attaque la plus précieuse dans la pile navigateur. Pour quiconque correspond au modèle de menace qu'Apple a décrit en 2022 — journalistes, travailleurs des droits humains, dissidents politiques, dirigeants ayant accès à des systèmes sensibles — ce compromis est clair.

Le coût de performance a diminué mais n'a pas disparu. L'écart Speedometer 2.0 de 2022 de ~65 % s'est réduit à ~33 % sur Speedometer 3.0 en 2026. Dans la navigation réelle, l'écart est plus proche de 0,5 à 0,7 seconde sur le Time to Interactive. Les améliorations de l'interpréteur WebKit sont réelles. Mais les workloads de classe JetStream chutent toujours de ~88 % — les applications web à forte intensité de calcul (jeux WebAssembly, éditeurs vidéo dans le navigateur, tableaux de bord de données complexes) restent significativement dégradées.

Le tableau de compatibilité est stable, pas résolu. Le mode Verrouillage désactive toujours WebAssembly, une proportion croissante des fonctionnalités des applications web. Les sites utilisant WASM pour le traitement d'images, les worklets audio ou les tâches computationnelles échoueront ou se replieront sur des chemins plus lents. C'est une décision de sécurité délibérée, pas un bug, mais cela signifie que les utilisateurs du mode Verrouillage rencontreront occasionnellement des expériences cassées sur les applications web modernes.

Le cadre de décision

Considérez le mode Verrouillage si :

• Vous êtes une cible de haut profil pour la surveillance de niveau gouvernemental ou l'espionnage industriel.
• Vous accédez régulièrement à des communications sensibles, des systèmes financiers ou des documents confidentiels depuis votre iPhone.
• Les applications et sites que vous utilisez le plus sont compatibles — la plupart des cas d'usage de lecture de contenu fonctionnent bien en mode Verrouillage.

Différez le mode Verrouillage si :

• Vous utilisez des applications web complexes (outils dépendants de WASM, IDE dans le navigateur, plateformes de données interactives).
• Vous n'êtes pas dans un modèle de menace élevé pour les attaques ciblées.
• Le coût de performance sur votre workflow spécifique est prohibitif.

La trajectoire future est vers un écart plus petit. L'investissement continu d'Apple dans le durcissement de LLInt, l'extension IC au niveau de l'interpréteur et la co-conception matériel-logiciel sur Apple Silicon suggèrent que l'écart Speedometer pourrait se réduire davantage d'ici 2027–2028. L'écart JetStream restera structurel jusqu'à ce que le benchmark lui-même ou les workloads qu'il représente deviennent moins dépendants du JIT.

Pour une vue d'ensemble de l'état de la confidentialité des navigateurs sur toutes les plateformes, consultez le rapport pilier État de la confidentialité des navigateurs 2026. Pour les mesures originales de 2022 qui ont établi la référence, voir L'impact du mode Verrouillage iOS 16 dans Safari. Pour la rétrospective complète sur quatre ans de ce que le mode Verrouillage a changé dans iOS, voir Mode Verrouillage iOS — quatre ans après. Et pour une comparaison cross-navigateurs couvrant Brave, Tor Browser, Mullvad et LibreWolf, voir Navigateurs privés 2026.

FAQ

À quel point Safari est-il plus lent en mode Verrouillage en 2026 ? Sur Speedometer 3.0, le mode Verrouillage obtient un score environ 30 à 35 % inférieur à celui de Safari standard sur iPhone 15/16. C'est une amélioration significative par rapport à l'écart Speedometer 2.0 de ~65 % mesuré en 2022, grâce aux améliorations de l'interpréteur WebKit et du tier Baseline dans iOS 17–18.

Le JIT de WebKit est-il encore exploité en 2026 ? Oui. Des CVE liées au JIT WebKit continuent d'apparaître en 2025–2026, bien que leur fréquence ait ralenti. Les efforts de durcissement d'Apple (Gigacage, BoundsChecking, gating des droits JIT) ont relevé le seuil d'exploitation, mais le JIT reste la principale surface d'attaque dans les exploits mobiles ciblés.

Qu'est-ce qu'un JIT spray et comment affecte-t-il WebKit ? Le JIT spray est une technique d'injection de code qui intègre des shellcodes dans du code compilé JIT en élaborant du JavaScript avec des valeurs constantes spécifiques. Les atténuations de WebKit comme Gigacage et le placement aléatoire du code rendent le JIT spray classique plus difficile, mais des variantes créatives apparaissent encore dans les recherches avancées sur les menaces.

Quelle est la différence de score JetStream 2 entre mode normal et mode Verrouillage ? JetStream 2 est très sensible au JIT. Le mode Verrouillage obtient généralement un score 85 à 90 % inférieur sur iPhone 15, car la plupart des workloads JetStream dépendent des tiers DFG et FTL. Speedometer 3.0 montre un écart plus faible car il inclut du travail DOM et de mise en page au-delà du pur débit JS.

Peut-on activer le JIT en mode Verrouillage sur iOS 18 ? Non. Depuis iOS 18, le mode Verrouillage continue de désactiver le JIT sur tous les navigateurs basés sur WebKit. Apple n'a pas introduit de liste blanche JIT par site en mode Verrouillage.

JavaScriptCore est-il plus rapide que V8 en 2026 ? Sur les benchmarks de débit de pointe (JetStream 2, workloads de type Octane), V8 avec TurboFan mène généralement sur le matériel Android. Sur Apple Silicon (iPhone 15/16 avec A17/A18 Pro), JSC obtient des résultats compétitifs ou supérieurs grâce à la co-conception matériel-logiciel, notamment sur les workloads réalistes de Speedometer 3.0.

Quel benchmark reflète le mieux les performances de navigation réelles ? Speedometer 3.0 est le meilleur indicateur des performances réelles aujourd'hui. Il simule un large ensemble d'interactions avec des frameworks JavaScript et des opérations DOM. JetStream 2 teste le débit JS de pointe, important pour les applications web à forte intensité de calcul. MotionMark se concentre sur la fidélité du rendu.

Devrais-je utiliser le mode Verrouillage pour la navigation quotidienne ? Le mode Verrouillage est conçu pour les personnes à haut risque — journalistes, activistes, dirigeants face à des attaques ciblées. Pour les utilisateurs ordinaires, il impose des coûts de performance et de compatibilité notables (applications web cassées, API désactivées) qui dépassent le modèle de menace. Activez-le uniquement si vous avez des raisons valables de croire que vous êtes une cible d'attaques sophistiquées.