Apple s'exprime sur la lenteur des web apps

Christophe Laporte |

La polémique enfle concernant Nitro, le moteur JavaScript que l'on retrouve dans Safari Mobile depuis iOS 4.3. En début de semaine, on s'apercevait que les les web app étaient 2 à 2,5 fois moins rapides que le même site affiché dans Safari (lire: Apple ne favorise pas les web apps).

Peu de temps après une étude menée par Blaze Software affirmait haut et fort qu'un Nexus S était en moyenne 52 % plus rapide qu'un iPhone 4 pour surfer sur le web. Or, cette étude n'a pas été menée directement via Safari, mais dans une WebView.

Ces différentes informations n'ont pas manqué de créer une petite polémique, qui une fois n'est pas coutume, a poussé Apple à sortir du silence. L'un de ses porte-parole, Trudy Miller, a confirmé que les vues web ne comprenaient pas toutes les optimisations de Safari. Par conséquent, l'étude de Blaze Software est en partie inexacte. Il est faux de dire que le navigateur de l'iPhone est plus lent que celui d'Android. Par contre, l'exécution de web app (sans passer donc par le navigateur) est effectivement nettement plus rapide sur Android.

Alors pourquoi les web apps sont-elles privées de Nitro et de l'absence de prise en charge du cache HTML5 ? Pour John Gruber, il ne faut pas voir le mal partout et imaginer que de la sorte la société californienne privilégie les applications natives aux applications web.

Le vrai problème pour Apple, c'est la sécurité. Contrairement à ses prédécesseurs, Nitro est un moteur JavaScript qui inclut la compilation à la volée (JIT). Or, une JT nécessite d'avoir la capacité de marquer des pages mémoire en RAM comme étant exécutables. Or, contrairement à Mac OS X, Apple l'interdit sur iOS pour des raisons de sécurité. Un tel mécanisme détourné pourrait aboutir à de l'exécution de code non signé.

Autrement dit, si Safari sous iOS 4.3 est nettement plus rapide, il y a une contre-partie non négligeable : si quelqu'un parvient à exploiter une vulnérabilité de son navigateur, alors elle peut faire bien plus de dégâts que par le passé. On imagine qu'Apple a suffisamment confiance dans son navigateur pour intégrer une telle possibilité.

Pour Gruber, il est plus que probable qu'Apple ne va pas en rester là. Il estime que pour généraliser Nitro aux applications web, il faudrait qu'une application web puisse exécuter JavaScript dans un processus séparé et indépendant, un peu à l'image de Safari sur Mac et PC qui crée un processus séparé pour Flash. En théorie, c'est ce qu'Apple prépare pour Webkit 2, dont le projet avait été annoncé en avril dernier : "WebKit2 est conçu à la base pour supporter les processus séparés, où le contenu Web (JavaScript, HTML, etc.) fait sa vie dans un processus séparé […] ce modèle est similaire à celui de Google Chrome, à la différence majeure que nous l'avons construit directement dans le framework, et qu'il est accessible aux autres navigateurs".

Tags
#webapps #nitro
avatar Lou117 | 
Il faudra qu'on m'explique en quoi le temps d'exécution du JavaScript entre en compte dans le temps de chargement/interprétation d'une page HTML... Ou dit autrement, même si le JS est plus rapide, si il se charge lentement ça ne sert à rien ! Mon article l'explique clairement : http://www.bheller.com/2011/03/17/performances-web-mobile-ce-qui-importe-reellement/ Ne confondez pas l'exécution JavaScript et le temps de CHARGEMENT d'une page.
avatar aldayo | 
Je me suis arrêté au 1er paragraphe que ne veux rien dire: "Tout utilisateur de l’internet mobile le sait, la vitesse du navigateur de votre appareil mobile est importante. Car quand la connexion est limitée, avoir un rendu rapide permet d’aller vite et d’avoir besoin de moins d’échanges avec les serveurs." C'est n'importe quoi ! un "rendu rapide" ne permet en aucun cas d'avoir moins d'échange avec le serveur...
avatar Lou117 | 
Justement, si le navigateur peut afficher éléments avant la fin du chargement, tu gagnes du temps et tu n'as pas besoin de tout charger. Effectivement je m'exprime un peu mal, je corrigerais demain.
avatar iguan | 
C'est pourtant étroitement lié sur les sites Web modernes. Indice: onLoad (ou pour les adeptes de JQuery: $(document).ready();)
avatar Lou117 | 
Non pas forcément. Sauf si l'application web a besoin d'éléments supplémentaires chargés depuis le javascript, ce qui arrive mais rarement sur les sites "classiques".
avatar Thalantas | 
"Il faudra qu'on m'explique en quoi le temps d'exécution du JavaScript entre en compte dans le temps de chargement/interprétation d'une page HTML..." -> Parce que le rendu et la mise en page peut etre modifie par JavaScript :). Et avant de le parser bah tu peux pas le savoir :).
avatar Lou117 | 
C'est effectivement possible mais dans les faits rarement utilisés sur les sites testés ici.
avatar denisbook | 
@Lemmings [18.03.2011 - 01:20] je ne comprends pas votre question. - le code js est exécuté. Nitro fait de la compilation "just in time" (il compile le code pour le rendre natif le plus vite possible et l'exécuter tel quel) - le cache sert à ne pas recharger à nouveau le code javascript. ce qui est très appréciable avec des "applications web" basés Jquery par exemple (jquery, bibliothèque javascript fort sympathique fait 80ko dans sa version complète et compressée) -- donc bien sur que cela sert un javascript "plus rapide" : L'application web , une fois chargée, va faire du travail. Par exemple permettre de dessiner (deviantart), permettre de trier des images, éditer localement un document, etc. que sais je ? ce travail, il est intéressant que la machine l'exécute vite et bien.
avatar Lou117 | 
Lis mon article, je suis d'accord avec toi sur l'intérêt d'un moteur javascript rapide. Mais il est plus important d'avoir un chargement rapide.
avatar solea | 
C’est cool de faire de la pub pour son site. Bon, sinon, dans un registre beaucoup moins poussé, il me semblait que les web apps étaient tout simplement des applications accessibles via le navigateur, donc pourquoi pas via Safari, sans passer du tout par le WebView d’une application « SDK »… à moins que dans la news cela ne concerne donc que les web apps appelées par une application, comme les services de Google, par exemple, et non les web apps en général ^^
avatar Lou117 | 
Ce qu'on appelle webapp, en réalité ce sont soit les sites Web que tu épingles comme application avec une icône sur le dashboard d'ios, et qui s'ouvrent en plein écran. Soit les vues web chargées depuis une application comme celle de google par exemple.
avatar solea | 
@Lemmings Alors y’a un truc que je pige pas. Si j’ajoute Gmail ou Google Latitude à mon écran d’accueil, je me retrouve dans Safari. Mais si j’ajoute MacPlus, je n’ai pas la barre de Safari, et le multi-tâche me met bien l’icône de MP. Pourtant, Gmail et Latitude sont des webapp, et je ne vois pas en quoi cela changerait quelque chose s’ils décidaient d’ajouter des éléments sur la page, mon lien s’ouvrirait toujours dans Safari, et donc je profiterais toujours de Nitro… Ça m’a l’air bien compliqué, tout ça ^^
avatar Lou117 | 
Bon, alors on rentre un peu plus dans les détails :) Quand tu ajoutes un site à l'écran d'accueil, par défaut ça agit comme un simple favoris. Mais le site peut ajouter certaines informations (spécifiées dans les docs Apple), comme une image de lancement, une icone évoluée (gestion du retina) et demande de lancement en plein écran. Dans ce cas, ce n'est plus Safari qui s'ouvre mais une version spécifique adaptée au site qui n'a plus le moteur Nitro activé... Tu peux avoir un listing des webapp sur http://www.apple.com/webapps/ Exemple avec http://www.explorimmopro.com/
avatar SeanC | 
Abracadabrantesque ...
avatar winstonsmith | 
Apple : le web en s'amusant.
avatar macsilvio | 
Ça s'appelle de l'enfumage. Apple nous prend pour des cons.
avatar xblade42 | 
Oui, c'est un conspiration, j'en suis sûr. Etape 1: Ils nous abrutissent l'esprit Etape 2: ils nous mettent tous en faillite personnelle Etape 3: on doit leur vendre notre âme pour payer nos dettes Etape 4: Appel prend enfin sa revanche sur Microsoft Etape 5: L'apocalpyse selon Saint Jobs Parfois, l'explication simple proposée est la bonne, non? C'est tellement facile d'accuser dès que quelque chose ne plaît pas. A croire qu'on aime ce sentiment d'être pris pour un con ;)
avatar drkiriko | 
Je comprends pas les réactions, c'est pourtant simple : 1. La dernière étude de Blaze est bidon puisqu'ils compare IOS à android mais en n'utilisant pas les outils officiels fournis par Apple. 2. Oui, le temps d'exécution de java joue sur l'affichage des pages 3. Oui, le temps d'exécution de java ne joue pas sur le temps de téléchargement, lié au transfert wifi, 3G... 4. Oui, Apple utilise une API optimisée pour safari et ne l'a pas fournie aux développeurs IOS.
avatar Titov | 
Tout à fait, si on voulait faire le procès à Apple de favoriser sa boutique en ligne au détriment des webapps, c'est raté, UIWebView ne permet pas de tirer partie de Nitro. Donc, Apple travaille évidemment en connaissance de cause, oui Nitro n'est disponible que pour Safari, non ce n'est pas pour favoriser son navigateur face aux webapps et applications natives.
avatar Lou117 | 
1) Les UIWebView sont des composants standard du SDK iOS. C'est Apple qui fourni la chose aux développeurs. Dire que Blaze n'utilise pas les outils officiels est donc faux. 2) Java ? Aucun support de Java sur iPhone (ni Android en l'état d'ailleurs). Le JavaScript lui influe que très peu sur le chargement de sites institutionnels comme ceux testés. 3) Exact, sauf si le JavaScript fait des appels externes. 4) C'est donc bien un problème. Cela dit l'API optimisée ne concerne que le JavaScript. Pas le temps de chargement.
avatar Rimtape | 
Quel est l'interêt de Nitro/JS dans UIWebView ? Les explications sur la sécurité sont moyennes, ils auraient pu faire une base commune pour les deux Safari.app et WebView.app et désactiver les éléments natifs problématiques du moteur Nitro dans WebView.
avatar Lou117 | 
Un développeur qui veut faire une application multiplate-forme a besoin d'un moteur JavaScript puissant. Les applications crées via des outils tels que PhoneGap en sont de bons exemples.
avatar RaZieL54 | 
Apple utilise Webkit dans Safari, mais Webkit=Safari est faux. Apple construit son navigateur avec des versions plus ou moins modifiées, adapte safari aux performances et specificités, compense certaines choses et utilise certaines nouveautés non totalement déployées dans la version publique de Webkit.... D'ailleurs c'est l'approche de tous les navigateurs utilisant Webkit, soit presque tous hormis Firefox et bien sur MS Internet Explorer. Pour les curieux qui veulent voir l'importance de Webkit: liste des applications utilisant Webkit Dans le cas présent, Apple veut cloisonner au maximum l'environnement d'exécution de Safari, histoire d'éviter ce qui vient de se passer lors de la pwn2own justement. Car l'impact des exploitation de failles est fortement potentialisé avec l'utilisation du cache et du compilateur Nitro... Comme le precise oomu, une fois qu'une grosse lib Javascript est compilée et placée en cache, ca va bien plus vite, mais ca permet aussi pas mal d'exploitations si c'est pas parfaitement cloisonné. Une escalade de droits faites par débordement de buffer dans l'espace memoire de Nitro qui n'est pas isolé et c'est le système qui est vulnérable.... Apple maitrise totalement l'execution de Safari, et les ingé peuvent trouver les problémes plus facilement de ce fait. Les WebView, elles sont utilisées dans un programme écrit par n'importe qui, avec des compétences allant de l'approximation la plus totale au vrai pro. Dans ces conditions, le risque d'exploitation est bien plus important et surtout difficile a déceler. Donc Apple fait avancer Safari bien plus vite que pour les Webview, c'est logique et ça a été toujours le cas. Ce qui est marquant ici, c'est le facteur d'amélioration apporté dans Safari qui creuse sérieusement l'écart, mais c'est temporaire. En parlant de WebApp les polémistes continus de jouer sur les termes, ce qui perd les gens, mais faut bien attirer le chaland pour vivre de la pub, hein. La webApp est normalement un site internet utilisant énormément Javascript et maintenant HTML5 pour proposer une interface qui se rapproche d'une application native, ce que l'on appelle aussi une RIA. Et elles sont utilisées avec Safari (ou un autre), en bénéficiant de la pleine puissance du navigateur. Les applications utilisant les WebView sont soit des des applications faisant office de navigateur Web specialisé, soit des clichés (des ) faites à partir de sites web (style dasboard), mais qui ne sont pas gérées par Safari. Il est vrai que sur ce point Apple devrait remettre les pendules à l'heure...
avatar Lou117 | 
Tu as parfaitement raison, sauf sur la partie sécurité des WebView. Les développeurs ont que bien peu d'éléments d'accès aux WebView, il n'y a pas foncièrement plus de failles par ce biais que par Safari. C'est même le contraire, si une faille est trouvée dans Nitro, le risque est maintenant accru comme l'a signalé l'article !
avatar Rimtape | 
Une webapp en mode non fullscreen utilise Nitro.

CONNEXION UTILISATEUR