For the upcoming unstructured sprint on iOS or perhaps later on, would it make sense to explore reinstating the loading of the first section of an article in one request, followed by loading of the others?
I've heard that the payload for the upcoming mobile app content service is pretty dramatically reduced, although that's down the road for full productionization.
I'm wondering if on this single payload for the new content service for relatively larger articles the time to interact for the iOS user would approach the incredibly fast time-to-interact that's present on Android as a consequence of its two-step loading mechanism.
For some historical context, there was two-step loading on iOS, but eventually things became crashy, so it was revised to be a one-step action=mobileview call.
-Adam
Two-step loading could be one viable approach. However, as with any optimizations, I would prefer to conduct an investigation (or see data from a previous one) about what page loading stages are taking the longest. This can be a combination of loading a few sample articles with the Safari inspector & Instruments attached (as well as loading the page in chrome w/ the chrome dev tools). I'm guessing there would be some high-yield opportunities to collaborate with mobile-web to optimize page load times before (or even in parallel to) any optimizations on the native end.
Of course, any page loading optimizations we make need to keep offline use in mind—at least for native apps.
On Fri, Mar 20, 2015 at 9:57 AM, Adam Baso abaso@wikimedia.org wrote:
For the upcoming unstructured sprint on iOS or perhaps later on, would it make sense to explore reinstating the loading of the first section of an article in one request, followed by loading of the others?
I've heard that the payload for the upcoming mobile app content service is pretty dramatically reduced, although that's down the road for full productionization.
I'm wondering if on this single payload for the new content service for relatively larger articles the time to interact for the iOS user would approach the incredibly fast time-to-interact that's present on Android as a consequence of its two-step loading mechanism.
For some historical context, there was two-step loading on iOS, but eventually things became crashy, so it was revised to be a one-step action=mobileview call.
-Adam
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Great ideas!
Dmitry or Bernd, do you know of any quick way to cap Android internet connection speeds on a physical device without rooting the device for doing side by side comparisons on medium to low speed connections? I can think of some less quick ways and also about how an emulator may sort of achieve the same, but was curious about simple ways to test on physical devices.
-Adam
On Fri, Mar 20, 2015 at 7:27 AM, Brian Gerstle bgerstle@wikimedia.org wrote:
Two-step loading could be one viable approach. However, as with any optimizations, I would prefer to conduct an investigation (or see data from a previous one) about what page loading stages are taking the longest. This can be a combination of loading a few sample articles with the Safari inspector & Instruments attached (as well as loading the page in chrome w/ the chrome dev tools). I'm guessing there would be some high-yield opportunities to collaborate with mobile-web to optimize page load times before (or even in parallel to) any optimizations on the native end.
Of course, any page loading optimizations we make need to keep offline use in mind—at least for native apps.
On Fri, Mar 20, 2015 at 9:57 AM, Adam Baso abaso@wikimedia.org wrote:
For the upcoming unstructured sprint on iOS or perhaps later on, would it make sense to explore reinstating the loading of the first section of an article in one request, followed by loading of the others?
I've heard that the payload for the upcoming mobile app content service is pretty dramatically reduced, although that's down the road for full productionization.
I'm wondering if on this single payload for the new content service for relatively larger articles the time to interact for the iOS user would approach the incredibly fast time-to-interact that's present on Android as a consequence of its two-step loading mechanism.
For some historical context, there was two-step loading on iOS, but eventually things became crashy, so it was revised to be a one-step action=mobileview call.
-Adam
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle
You can always do it manually:
1. Use network link conditioner on your mac to throttle the emulator
or
1. Plug your Mac into the internet via ethernet 2. Share your internet via your Mac's wifi 3. Join the WiFi on any test devices 4. Enable network link conditioner on the Mac sharing WiFi
While I think being able to handle both high latency and/or low bandwidth is important, I'm pretty confident that networking efficiency is not the main culprit in our case to solve page load time issues.
On Fri, Mar 20, 2015 at 10:51 AM, Adam Baso abaso@wikimedia.org wrote:
Great ideas!
Dmitry or Bernd, do you know of any quick way to cap Android internet connection speeds on a physical device without rooting the device for doing side by side comparisons on medium to low speed connections? I can think of some less quick ways and also about how an emulator may sort of achieve the same, but was curious about simple ways to test on physical devices.
-Adam
On Fri, Mar 20, 2015 at 7:27 AM, Brian Gerstle bgerstle@wikimedia.org wrote:
Two-step loading could be one viable approach. However, as with any optimizations, I would prefer to conduct an investigation (or see data from a previous one) about what page loading stages are taking the longest. This can be a combination of loading a few sample articles with the Safari inspector & Instruments attached (as well as loading the page in chrome w/ the chrome dev tools). I'm guessing there would be some high-yield opportunities to collaborate with mobile-web to optimize page load times before (or even in parallel to) any optimizations on the native end.
Of course, any page loading optimizations we make need to keep offline use in mind—at least for native apps.
On Fri, Mar 20, 2015 at 9:57 AM, Adam Baso abaso@wikimedia.org wrote:
For the upcoming unstructured sprint on iOS or perhaps later on, would it make sense to explore reinstating the loading of the first section of an article in one request, followed by loading of the others?
I've heard that the payload for the upcoming mobile app content service is pretty dramatically reduced, although that's down the road for full productionization.
I'm wondering if on this single payload for the new content service for relatively larger articles the time to interact for the iOS user would approach the incredibly fast time-to-interact that's present on Android as a consequence of its two-step loading mechanism.
For some historical context, there was two-step loading on iOS, but eventually things became crashy, so it was revised to be a one-step action=mobileview call.
-Adam
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle
I'll note that we have SPDY on the cluster now (mostly on all machines, if not complete in the next few days), and so two requests don't have as much of a connection overhead as they used to.
Yeah, that's encouraging. Be interesting to test browser overhead and bandwidth overhead. Lots of things to look at.
On Fri, Mar 20, 2015 at 8:53 AM, Yuvi Panda yuvipanda@gmail.com wrote:
I'll note that we have SPDY on the cluster now (mostly on all machines, if not complete in the next few days), and so two requests don't have as much of a connection overhead as they used to.
+1
Monte and Bernd have already been working hard to improve performance. It will be awesome to keep improving the performance.
Users tend to jump through a lot of links while reading. Right now it takes an average of 1 - 2.5 seconds to load an article. Fast loading will encourage more exploration and jumping to this app than using google.
Thanks Vibha
---- Vibha Bamba Senior Designer | WMF Design
On Fri, Mar 20, 2015 at 6:57 AM, Adam Baso abaso@wikimedia.org wrote:
For the upcoming unstructured sprint on iOS or perhaps later on, would it make sense to explore reinstating the loading of the first section of an article in one request, followed by loading of the others?
I've heard that the payload for the upcoming mobile app content service is pretty dramatically reduced, although that's down the road for full productionization.
I'm wondering if on this single payload for the new content service for relatively larger articles the time to interact for the iOS user would approach the incredibly fast time-to-interact that's present on Android as a consequence of its two-step loading mechanism.
For some historical context, there was two-step loading on iOS, but eventually things became crashy, so it was revised to be a one-step action=mobileview call.
-Adam
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l