Re: [WikimediaMobile] Wikipedia Zero Landing Page Speed and Search

Hi all, We've been looking for ways to speed up m.wikipedia.org and zero.wikipedia.org landing page experiences on Wikipedia Zero. Currently, when users hit m.wikipedia.org/ or zero.wikipedia.org/ on a Wikipedia Zero partner network connection, there are two types of experiences. 1) If there's one popular language for the Wikipedia Zero partner network, the user is redirected to the Main Page for that popular language. https://drive.google.com/file/d/0BxJX28FKLm78SDBBSUJIbkNxRkE/edit?usp=shari… or 2) If there are multiple popular languages for the partner network, the user is sent to a page in the most popular language on the partner network and presented with a community-generated quote or generic lead-in text plus hyperlinks to the Main Page for each popular language and an HTML-heavy dropdown list for all languages. https://drive.google.com/file/d/0BxJX28FKLm78OGZNc3FiZmo3bmc/edit?usp=shari… We've observed that these pages can take a while to load on slow connections like 2G. Naturally, part of the slowness is due to the connection itself. Additionally, part of it seems to be related to additional (sometimes, network, sometimes DOM compositing blocking) page resources, despite ubiquitous HTTP 1.1 connections. Although some of the resources loaded from these pages are nice to get into the device cache, for a landing page there's a higher risk that the user will give up before actually seeing anything, and unfortunately many of the devices on the Wikipedia Zero networks may not be able to take full advantage of some of the features such as the core JavaScript (and by implication, extended JavaScript, which in fairness won't be pulled) and even the CSS - much of it is out of scope or unsupported. For the Wikipedia Zero users unfamiliar with Wikipedia, the Main Page content sometimes also is targeted at one geo, but not so much at the user's geo despite a shared language. It's worth thinking through ways to encourage local content curation in partnership with community members, and so that's an area for additional exploration down the road perhaps. Anyhow, I wrote a small patch to make the Wikipedia Zero landing page experience relatively faster plus give the Wikipedia Zero user clear access to fulltext search while also giving the user a means of hitting the Main Page in the most popular languages. https://gerrit.wikimedia.org/r/#/c/147138/ https://drive.google.com/file/d/0BxJX28FKLm78VnR5SHJWQ1JCXzQ/edit?usp=shari… We were wondering if this sort of thing might be of interest for the mobile web in general, as well as if there was a way to sort of bake in the strictly essential CSS and JS for this landing experience to achieve this small footprint and faster page loading and search emphasis while relying upon existing components. I'd like to get this thing running for users on "zerodot" ( zero.wikipedia.org) for the #2 experience, followed by mdot on the #2 experience. And if that goes well, I think it be worth trying this strategy on #1 as well (zerodot, then mdot). A few notes: * The patch has code for the license and ToS in the footer, it's just that the devwiki screenshot is with fewer messages filled. * It would be possible to add a little extra <style>ing into the patch's output HTML (including a CSS sprite for the Wikipedia wordmark, if it's required, although it adds overhead and isn't guaranteed to be perfectly supported), as well as link to the info screen from the "banner text" at the top for the operator like with the existing landing page, but I wanted to cut this code first before untangling some of the other code. Sometimes, less is also more. * Whether the user taps on a link for the Main Page from a list of languages or is sent directly to the Main Page, it's sort of hard to avoid some of the latency on slow connections. The theory with this patch is that if we can get the user started quickly, the user may be more likely to stick around and the in the case of fulltext search, even though the search results page will pull down some additional resources, the user may be more incentivized to wait because it's something she was specifically seeking out. Although it's nice to cache things, in this case it seems that deferring is worth it. * Eventually, it would be cool to wire up interwiki CirrusSearch for Wikipedias from the mobile fulltext search. In the interim, I've been thinking about getting "Did you mean" in place for mistyped searches (e.g., purrng suggests Purna), as well as a little additional styling on the search results (e.g., make title bigger, remove block bullet points). Thanks. -Adam