Apple bride-t-il la vitesse des sites mis en favoris sur l’écran de l’iPhone ?

Voilà une drôle de révélation qui pourrait bien alimenter le débat sur le meilleur choix entre applications à installer et web mobile. Selon une étude menée par The Register et plusieurs développeurs, un site web épinglé en favoris via une icône sur l’écran d’accueil de l’iPhone s’afficherait plus lentement que quand on l’appelle directement à partir de Safari Mobile.

Voilà une drôle de révélation qui pourrait bien alimenter le débat sur le meilleur choix entre applications à installer et web mobile. Selon une étude menée par The Register et plusieurs développeurs, un site web épinglé en favoris via une icône sur l’écran d’accueil de l’iPhone s’afficherait plus lentement que quand on l’appelle directement à partir de Safari Mobile.

D’après les observations et comparaisons effectuées par The Register, les applications web tournent à une « vitesse significativement plus lente » quand elles sont lancées depuis l’écran d’accueil d’un iPhone ou iPad sous iOS 4.3, jusqu’à deux fois plus lentement que lorsqu’elles sont lancées directement depuis le navigateur, alors qu’elles devraient au contraire tirer avantage du nouveau moteur JavaScript Nitro pour s’afficher plus vite.

Un développeur d’applications mobiles qui tient à rester anonyme va même jusqu’à accuser Apple de dégrader volontairement l’impression de qualité des web apps afin de protéger le modèle économique de l’App Store. Un autre note que les web apps de l’écran d’accueil n’utilisent pas les différents systèmes de cache disponibles, et notamment HTML5 Application Cache, qui permettrait de charger plus vite les pages.

Les tests menés par The Register font effectivement apparaître une différence qui va du simple au double, comme le montrent les deux images ci-dessous. L’image de gauche montre les performances d’un site web ouvert depuis le navigateur et la droite le même site lancé depuis son icône de favori sur l’écran d’accueil.

4047ms / 10747.3ms

Ce que j’en pense : même si je ne mets pas en doute le sérieux et la bonne foi de The Register, j’ai un peu de mal à cautionner cette hypothèse. Tout d’abord pour des raisons techniques : qui nous dit que cette différence de traitement n’est pas simplement due à des contraintes qui rendent impossible un traitement équivalent des pages selon la façon dont elles sont appelées ? Ensuite, selon toute logique il n’apparait pas anormal qu’une page web soit un peu plus longue à charger quand on l’appelle d’un clic hors du navigateur (il faut compter le temps d’ouverture du navigateur). Enfin j’ai fait moi-même quelques essais (ne parlons pas de tests) et je n’ai pas vu de différence notable à l’œil nu.

D’un point de vue marketing, je vois mal Apple se livrer à ce genre de petit jeu, de surcroît vite repéré par les utilisateurs, car j’aurais quelques difficultés à en saisir la logique : dans ce cas Apple aurait meilleur compte de ne pas promouvoir la qualité de son navigateur mobile, et devrait plutôt supprimer la fonction de favori sur le bureau. Enfin si je prends l’exemple de ce Presse-citron, le temps d’ouverture de la version mobile du site (en favori écran ou pas) et de l’application iPhone sont équivalents, à savoir environ 7 secondes.

Alors, étude pour rien et soupçon infondé ou vraie ruse de la Pomme ?


Nos dernières vidéos

11 commentaires

  1. Il est aussi possible que ce soit un decalage dans le deploiement de la technologie.

    Je veux dire par la, que les ingenieurs d’Apple on tres bien pu mettre en place le nouveau moteur pour Safari, mais que cela n’est pas encore le cas pour les WebView utilisé dans les applications et potentiellement utilisé aussi pour les webapps bookmarké sur le springboard de l’iphone.

  2. D’un point de vue purement technique, une Webapp n’est rien d’autre qu’une URL avec une icône.

    La différence entre une webapp et Safari est que dans le premier cas, Safari passe automatiquement en plein écran, et donc, que certaines fonctions deviennent innaccessibles (gestion des favoris, multi-tab…)

    C’est d’ailleurs le même principe pour les « Application shortcuts » de Chrome, et aussi basé sur le moteur de rendu Webkit.

    De là à penser que Apple ait ralenti les WebApps de iOS 4.3 volontairement…

  3. Tu peux faire un autre test aussi, le multitache est très mal géré en mode webapp, à chaque fois qu’on revient sur la webapp (en switchant sur une autre application par exemple) la page est entierement chargée ce qui est assez déplaisant, ce qui n’est pas le cas si la page est affichée dans Safari.

    PS : Je parle bien du mode « webapp » il faut la meta
    « apple-mobile-web-app-capable » dans le header HTML

  4. Pour le moment, la raison lancée sur les forums des développeurs est que Nitro a besoin de télécharger et générer du code sur l’iphone ou iPad pour accélérer le JS. Ceci ouvre donc de potentielles failles de sécurité qui peuvent être isolées par Safari et pas encore par le WebView.

    Du coups, Nitro ne s’active pas dans cette situation.

  5. Moi je ne serai pas étonné de telle pratique chez Apple. Il est clair que leur modèle économique est basé sur l’Apple Store et ils ont par ce biais la possibilité de l’avantager facilement dans un moment où la concurrence est dure. Après le fait que ça ne soit pas « très malin » : ça ne serait pas la première fois qu’une entreprise de cette taille fait une gaffe dans ce style (récemment : Microsoft avec la promo de Bing sur Twitter comme un acte de solidarité pour les japonais…)

  6. Pingback: Tools Iphone » Blog Archive » Étude: naviguer sous Android serait 52% plus rapide que sur l’iPhone – Métro Montréal

  7. Je n’ai strictement rien compris à l’explication d’Apple ?
    Pourquoi n’utilise-t-on pas Safari que ce dernier soit lancé sans paramètre ou avec paramètres (webui) ?
    Lorsqu’on lance chrome en tant que chrome ou en tant qu’application c’est le même Chrome, le même V8, etc.
    C’est simplement une instance différente, une nouvelle.
    Pourquoi n’est-ce pas la même chose avec Safari ?
    Ne faut-il tjs qu’une seule instance de Safari pour des raisons de mémoire ?
    Pourtant lorsqu’on lance une webui on ne retrouve pas la page dans celles de Safari.
    Il y a donc bien plusieurs instances à ce moment.

    Pour moi, en l’absence d’autresinfos, il y a un pb de conception : c’est Safari qui doit s’exécuter dans tous la cas sous autant d’instances.

    Db

  8. Cela va même plus loin, certaines fonctionnalités du CSS3 qui fonctionnent très bien dans le navigateur Safari ne marchent tout bonnement pas en webapp (testé sur iphone 4: background-image: -webkit-gradient(linear, left top, left bottom, from(#C061A0), to(#610241));).
    Venant d’Apple, ce n’est pas forcément étonnant.

Répondre