3 ms·

They didn't use Safari, they used a custom-written app with an instance of UIWebView. For a variety of (purportedly security-related) reasons, UIWebView has al

They didn't use Safari, they used a custom-written app with an instance of UIWebView. For a variety of (purportedly security-related) reasons, UIWebView has always been slower than Safari, but it's especially pronounced in iOS 4.3, where UIWebView didn't receive any of the Nitro upgrades that Safari did. An argument can certainly be made that UIWebView being crippled is very much a platform negative (I would agree), but the "study" is purporting to represent the speed of browsing in Safari, which is plainly false.

recoiledsnake 16y ago
Isn't Nitro a Javascript engine? Why will it affect page load times?
- pohl 16y ago
  That depends upon how they measured. From reading their methodology, it sounds like they may have ended their measurement when they got a "document complete" callback (in their nomenclature). That sounds as if they were listening for the UIWebViewDelegate's webViewDidFinishLoad: method. If the initial page load triggers some javascript at page load time to dynamically create elements in the DOM or do any other setup work, that could easily been within the scope of their measurement. Depending on what the Fortune 1000 websites look like, of course. I wouldn't expect the absence of Nitro to dominate the measurement, however. (Edit: Blaze says that 15% of the time taken, on average, was inside of JavaScript execution, so apparently it's both true that it does not dominate and that faster execution would have made a meaningful change.) I still think their methodology is flawed, though, because the webViewDidFinishLoad: callback can be called multiple times in the loading of a single document. It's not clear which one they listened for: the first one? the last one? http://stackoverflow.com/questions/908367/uiwebview-how-to-identify-the-last-webviewdidfinishload-message http://stackoverflow.com/questions/908367/uiwebview-how-to-i... Contrast this with the WebView in Android. It's not obvious what callback they would have used in that case, but looking at the documentation they probably would have listened for onPageFinished(), which appears to get called much earlier, because it is only called when the loading of the main frame is completed. (Again, according to the docs I found). http://developer.android.com/reference/android/webkit/WebViewClient.html#onPageFinished(android.webkit.WebView http://developer.android.com/reference/android/webkit/WebVie..., java.lang.String) In order for their methodology to make any sense, one would have to conduct the measurements based on callbacks that have the same semantics. Do they? It doesn't look like it to me.

recoiledsnake 16y ago

Isn't Nitro a Javascript engine? Why will it affect page load times?

pohl 16y ago
That depends upon how they measured. From reading their methodology, it sounds like they may have ended their measurement when they got a "document complete" callback (in their nomenclature). That sounds as if they were listening for the UIWebViewDelegate's webViewDidFinishLoad: method. If the initial page load triggers some javascript at page load time to dynamically create elements in the DOM or do any other setup work, that could easily been within the scope of their measurement. Depending on what the Fortune 1000 websites look like, of course. I wouldn't expect the absence of Nitro to dominate the measurement, however. (Edit: Blaze says that 15% of the time taken, on average, was inside of JavaScript execution, so apparently it's both true that it does not dominate and that faster execution would have made a meaningful change.) I still think their methodology is flawed, though, because the webViewDidFinishLoad: callback can be called multiple times in the loading of a single document. It's not clear which one they listened for: the first one? the last one? http://stackoverflow.com/questions/908367/uiwebview-how-to-identify-the-last-webviewdidfinishload-message http://stackoverflow.com/questions/908367/uiwebview-how-to-i... Contrast this with the WebView in Android. It's not obvious what callback they would have used in that case, but looking at the documentation they probably would have listened for onPageFinished(), which appears to get called much earlier, because it is only called when the loading of the main frame is completed. (Again, according to the docs I found). http://developer.android.com/reference/android/webkit/WebViewClient.html#onPageFinished(android.webkit.WebView http://developer.android.com/reference/android/webkit/WebVie..., java.lang.String) In order for their methodology to make any sense, one would have to conduct the measurements based on callbacks that have the same semantics. Do they? It doesn't look like it to me.