Enfin, dans la pratique, car comme il en est ressorti, Blaze Software a mené son étude (45 000 tests auraient été effectués en tout et pour tout) en utilisant non pas la version iOS de Safari, mais une application propriétaire embarquant le module d’Apple UIWebView (du côté d’Android, la même application, utilisant le même procédé, tirait parti de WebView). Problème : le module ne tire pas parti du Nitro JavaScript implanté au sein d’iOS 4.3, et permettant une navigation bien plus rapide. Forcément, Apple n’a pas tardé à monter au créneau. Depuis, Blaze Software a admis le manque de crédit de son étude…
via loopinsight
🟣 Pour ne manquer aucune news sur le Journal du Geek, abonnez-vous sur Google Actualités. Et si vous nous adorez, on a une newsletter tous les matins.
la mention « En fait, non… » elle aussi est erronée, il aurai mieux fallut écrire « Pas si sûre… ». Pour ma part j’attend de voir de vrai test comparatifs. 😉
et toc… le Nitro JavaScript est vraiment rapide rien a voir avec du android.
avec un peu de recherche on pouvait le savoir… pas besoin que Blaze Software fasse une étude fausse en plus
Par contre Apple n’explique pas pk Nitro n’est pas utilisé ds le Web View… (sécurité parait-il….. certains parlent de pousser les devs a faire des applis natives…)
Si tu le dit jrm
Le navigateur android est très rapide autant que celui de iOs.
Mais le problème n’est pas là faut arrêter de dire “ouai j’ai la plus grosse mon navigateur est plus rapide” on gagne le plus souvent quelques milliseconde sur certains sites … Bref sa ne change rien.
Moi se qui me gêne le plus c’est la vitesse des réseaux qui je trouve à diminué depuis les début de la 3g. Je suis plus souvent ralentit par le réseau que par le navigateur lui-même.
Comment peut on arriver a faire une erreur pareil??
Apple n’a, comme d’habitude, pas communiqué sur le sujet du moteur utilisé dans iOS 4.3 par les applis utilisant le composant UIWebView.
Forcément, Blaze Software ne pouvait pas le savoir, et encore moins corriger le problème, vu qu’il a été introduit volontairement par Apple.
Quelque part c’est un peu la faute d’Apple, et l’étude est toujours valable : les web-apps qui utilisent UIWebView seront bien plus lentes que l’équivalent Android.
Pour avoir développé une web app pour mobiles, je puis affirmer avec certitude que chrome android est vraiment pas du tout optimisé pour les effets visuels. Il est lent et il freeze. Je ne parle pas de la console bien cachée, pourtant indispensable pour tout développement (Sans, aucun message d’erreur n’est affiché !)
Pour ceux qui veulent comparer android et iphone/ipad :
http://dev.sencha.com/deploy/touch/examples/kitchensink/
@grogeek :
http://www.theregister.co.uk/2011/03/15/apple_ios_throttles_web_apps_on_home_screen/
@jrm source ? (pour ta première phrase)
@Jrm : tu as des études qui montrent ca? Parce que bon il suffit pas que la pomme dise que son monteur JS soit plus rapide pour que ce soit vrai…
Donc la faute du testeur vient du fait que l’implémentation javascript dans les applications embed n’est pas celle utilisée dans le navigateur ? Donc si je comprends bien, elles sont bel et bien plus lentes ? J’ai bon ? 🙂
Je cite présence-pc : “Le temps de chargement mesuré par Blaze était en effet le temps mis par le navigateur à envoyer la commande DocumentComplete. Or cet événement a lieu normalement avant toute exécution du Javascript.”
Donc les résultats obtenus sont corrects. 😈
Bon, vu que mon commentaire n’a pas été enregistré, je recommence :
J’ai développé des web apps, je peux donc affirmer avec certitude que safari est bien mieux foutu que chrome.
Il est plus rapide, plus stable et surtout, il est très efficace sur les effets visuels et autres transition CSS3.
Android, de son côté, est lent et freeze fréquemment. Sans parler du fait que la console javascript est bien cachée au fin fond du navigateur.
Pour ceux qui veulent comparer :
http://dev.sencha.com/deploy/touch/examples/kitchensink/
@grogeek :
http://www.theregister.co.uk/2011/03/15/apple_ios_throttles_web_apps_on_home_screen/
@Jrm You have been spotted ! http://www.fanboyfacts.com/quote-195
MDR!
Koladz> Très bon site, j’aime beaucoup ^^
@dreadcast: Safari est peut être plus ergonomique, mais au niveau sécurité, et respect du HTML5, il a des années de retard. Un comble pour un navigateur qui veut se passer du flash. A tel point que sur même sur mac, la majorité des gens changent de navigateur!
Et pour le développement, une autre différence de taille: pour développer et déployer une apk android, le développeur paye… 0€ De l’IDE aux librairies, tout est gratuit, voire même en, partie open source! Pas étonnant que l’écart du nombre d’application se réduise aussi vite!
@theMutthon : safari et chrome utilisent tous les deux webkit donc respectent tous les deux aussi bien le HTML5. Pour la sécurité, par contre, c’est vrai.
Pour etre repassé sur iphone apres un detour HTC Desir android ; Safari ce n’est pas le point fort de l’iphone. La preuve j’utilise comme beaucoup de gens qui naviguent qlq heures par jour sur leur precieux, ICABmobile : un vrai browser web de smartphone. Après le debat iphone mieux ou pas qu’android, on s’en fou, chacun a des avantages que l’autre n’a pas
Dans le cul les anti apple 😀 (je sens le -50 et j en jouis d avance
)
Fait 1 : je suis pas fan d’Apple, je préfère Android.
Fait 2 : je trouve quand même que iOS est bien souvent plus rapide qu’Android.
@Emmanuel: Il n’est pas plus rapide, mais il affichera un FPS plus conséquent ce qui permet d’avoir l’impression qu’il est doux, et ce grâce à une interface qui prends en charge le GPU de l’iPhone. L’accélération GPU pour android est prévue pour Ice Cream selon la team Android for Phones, qui stipule : “nous reprendrons les éléments les plus importants de Honeycomb(qui contient déjà l’accélération graphique) pour Ice Cream.”
Mais Android prendra moins de temps pour aller dans les préférences par exemple, et avec une meilleure gestion du multitâche les applications se relanceront plus rapidement. Donc en bref: il affiche moins bien les transitions, mais passe beaucoup plus vite au contenu prévu.
@Koladz : J’adore !
J’adore voir les fans d’Apple prendre plaisir à voir le browser mobile plus rapide que sur Android. Ils avaient juste un an de retard sur Froyo en fait, et là, ils ne la ramenaient pas. Maintenant, ils sont content de voir leur page web chargé 1/1000e de seconde plus vite que sur Android. Youpi ! Et deezer, il se charge en combien de temps ? Ah merde non, y’a du flash, ça marche pas !
Pitoyable …………….
Du moment que chaque personne y trouve son compte, que ce soit sur Ios, Android, Win7 ou autre ! Où est le problème ? Les améliorations des uns profitent aux autres. Et au final, c’est le consommateur qui est gagnant non ?
Bonjour tout le monde !
Le temps de chargement mesuré par Blaze était en effet le temps mis par le navigateur à envoyer la commande DocumentComplete. Or cet événement a lieu normalement avant toute exécution du Javascript. Il nous semble que Blaze aurait effectué une mesure plus proche du ressenti d’un utilisateur en attendant un évènement qui signale le rendu complet de la page.
http://www.presence-pc.com/actualite/safari-uiwebview-42975/
Donc oui , Chrome lite charge les pages plus rapidement que ce que fait safari mobile 🙂
Dire qu’on a du attendre le 4.3 pour avoir un moteur javascript rapide…
Snakeponge> Fail, lis les autres commentaires et renseigne toi avant de balancer ce genre d’âneries ^^
Franchement, on s’en fou de savoir si l’ios est plus rapide ou pas qu’Android… C’est de l’Apple donc réservé à aux fans qui aiment jouer à qui a la plus grosse… Pour les Geeks comme moi, c’est tout sauf cette marque à pigeons 🙄 Je sais me servir de plus d’un bouton moi
➡
Le journal du geek est tombé dans le panneau et l’information relayée est incorrecte.
On compare le temps de chargement des pages web, pas la performance des moteurs javascript. C’est peut être un peu “technique” pour certains donc en clair :
Le navigateur par défaut d’android 2.3 charge t’il plus vite les pages que safari mobile?
– quand inclus dans une application : oui
– Le navigateur seul : impossible à dire avec certitude mais probable (vu que le moteur javascript a une influence négligeable sur le chargement d’une page)