Android plus rapide de 50% sur le web qu'iOS ? Pas si vite

Il y a deux jours, nous avons publié une actualité indiquant que les performances d’iOS 4.3 semblaient différentes selon qu’on chargeait des pages web depuis Safari, ou depuis une application web épinglée sur la grille des icônes. Parallèlement à ce souci soulevé par The Register, une batterie de tests a été réalisée par Blaze Software, qui en a sorti des différences énormes de performances entre iOS 4.3 et Android 2.3. Explications.

android ios javascript

L'absence de Nitro et les performances d'Android

The Register s’était fait l’écho d’une différence importante de performances entre les pages web chargées dans Safari, et les applications web épinglées. La différence de performances ressemblait fort à la hausse de 50 % sur les performances JavaScript clamée par Apple, qui introduisait pour la première fois sa machine virtuelle Nitro dans Safari mobile. Cet écart a rapidement fait parler de lui, et encore davantage depuis les tests de Blaze.

Chez cette société canadienne, on s’est intéressé aux écarts de performances entre les navigateurs d’iOS 4.3 et d’Android 2.3. Sur les 45 000 tests effectués, Android était plus rapide pour charger les pages dans 84 % des cas. Moyenne enregistrée : 52 % de performances en plus pour Android, un écart plus que conséquent. Ce chiffre diminuait par contre avec les versions mobiles des sites, et l’écart n’était plus que de 3 %.

Nitro n'est que dans Safari

Ces deux histoires cumulées ont provoqué une réaction finalement assez rare : celle d’Apple. Et c’est à The Register que Trudy Muller, porte-parole de la société, s’est adressée. Elle a confirmé ce que les développeurs qui avaient communiqué avec The Register avaient pressenti : les pages web épinglées sur l’écran de l’iPhone ne profitent pas de Nitro. Les optimisations de la version 4.3 d’iOS intègrent Nitro, la gestion de certains caches ainsi que le mode de rendu asynchrone. Or, ces optimisations ne sont présentes que dans Safari, pas dans les web views.

Les web views permettent d’afficher un contenu web en utilisant une API de Safari (UIWebView), mais sans passer par le navigateur complet. La question qui se pose est évidemment : pourquoi une telle différence de traitement ? C’est le célèbre John Gruber qui fournit un élément de réponse. Il indique que le principal attrait et vecteur de performances dans Nitro vient du compilateur JIT (Just-In-Time) intégré. Pour que ce compilateur fonctionne, il faut que certains espaces dans la mémoire vive puissent être désignés comme exécutables. Et c’est là toute la différence : la chose est possible depuis Safari, mais pas depuis les web views.

Sécurité et performance : soit l'une, soit l'autre ?

D’après Gruber, ce serait une question de sécurité. La création de zones mémoire exécutables n’est normalement pas autorisée dans iOS, et la seule exception vient de Safari mobile dans iOS 4.3. Ces zones mémoires permettraient l’exécution de code natif non signé, « brisant ainsi la chaîne de confiance ». Bien entendu, la situation est techniquement beaucoup plus complexe, mais le choix d’Apple se base sur la sécurité et non sur les performances. Si Apple activait ce type de zones mémoires pour tous, il serait possible d’utiliser n’importe quelle faille pour créer une escalade de privilèges et ainsi ouvrir la porte à des dégâts plus importants.

Du coup, Apple juge la méthodologie de Blaze faussée, pour la simple et bonne raison que les 45 000 tests n’ont pas été réalisés dans Safari. L’éditeur canadien a en effet utilisé sa propre solution maison qui se base... Sur des web views. De fait, les améliorations d’iOS 4.3 ne sont pas présentes, et le titre du résultat aurait plutôt dû faire mention d’iOS 4.2, puisque c’est quasiment à ceci que revient la conclusion.

Gruber indique que plusieurs pistes seraient possibles pour Apple concernant l’utilisation de Nitro pour les web views. Car ces dernières sont importantes, puisqu’elles permettent d’appeler une page web depuis une application. Sur le client Twitterrific par exemple, cliquer sur un lien dans un tweet ouvre la page dans l’application, et pas dans Safari, ce qui évite les allers retours. Deux idées sont fournies :
  • Rendre Nitro disponible pour toutes les applications, en l’isolant dans un processus spécifique, à la manière du lecteur Flash dans Snow Leopard
  • Un processus Nitro dédié aux applications tierces, et qui exécute le JavaScript « pour » les applications, et non « dans » les applications
Dans tous les cas, l’éditeur Blaze a reconnu que la question de Nitro sur les web views changeait la donne, et qu’il enquêtait sur le problème. Cela étant, Guy Podjamy, directeur technique, estime que Nitro ne pourrait accélérer le rendu des pages testées que d’environ 15 %. Une affirmation qui demande évidemment confirmation, surtout à la lueur des dernières informations publiées. 

Vous n'avez pas encore de notification

Page d'accueil
Options d'affichage
Abonné
Actualités
Abonné
Des thèmes sont disponibles :
Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !