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 <ab...@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
_______________________________________________ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
