Page MenuHomePhabricator
Create Task
Maniphest T33011

MobileFrontend should load sections dynamically as much as possible to avoid downloading never-viewed text and images
Closed, ResolvedPublic
Actions

Description

At least on the views given to regular web browsers and a web browser masquerading as an iPhone, the text of pre-folded/hidden sections seems to still all be transferred with the rest of the page.

For instance the 'Obama' page transfers a whopping 720 KB of HTML (thankfully compressed down to 128 KB) although all that's shown is an infobox, four paragraphs, and a few section titles.

At least on the desktop version of Safari with tweaked User-Agent for iPhone, a large number of thumbnail images were also loaded despite being in hidden sections.

Version: unspecified
Severity: enhancement
URL: http://en.wikipedia.org/wiki/Obama?useformat=mobile

Details

Reference
bz31011

Event Timeline

• bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:52 PM
• bzimport added a project: MobileFrontend-Feature-requests.
• bzimport set Reference to bz31011.
• bzimport added a subscriber: Unknown Object (MLST).
• brion created this task.Sep 19 2011, 8:58 PM
MarkAHershberger added a comment.Sep 20 2011, 9:16 PM

lowering priority till we have some actual field reports complaining about size or speed.

• brion added a comment.Sep 20 2011, 11:31 PM

I do recall a few anecdotes of people preferring the old en.mobile.wikipedia.org over en.m.wikipedia.org because the (very short) pages loaded so much faster.

I recommend doing a few test comparisons between long-form and cut-down versions of some articles on real 2g/3g data connections (not wifi!) to establish what the difference looks like in practice.

Krinkle added a comment.Sep 20 2011, 11:38 PM

I guess the css-hide is done with javascript on-load, after the browser has already parsed a bit of HTML and started downloading the <img>'s it has encountered so far.

A possible solution would be to (as far as this isn't the way it is already) wrap sections in <div>'s server side, give them a class, and in plain css (not javascript dependent) hide them with "html.js .section { display: none; }" and in the <head> add that class to the document.

That way they're hidden before parsed and still readable without JS. Testing that locally in a plain HTML file showed a significant difference in number of images being downloaded. (ie. none of the in section were downloaded on or after load until I expanded it)

• brion added a comment.Dec 20 2011, 10:30 PM
  • Bug 33266 has been marked as a duplicate of this bug. ***
Jdlrobson added a comment.Mar 6 2012, 4:36 PM

Images will be loaded as encountered in the html regardless of whether they are hidden by css.

To avoid this clicking toggle section would need to request the section from the server via an ajax call to the api and render on the callback rather than just adding a class to the document as it currently does.

An alternative would be for the api to set data-src on any images encountered and remove the src attribute and for javascript to set src attribute to data-src on the images on a toggle.

MaxSem added a comment.Mar 6 2012, 7:06 PM

The only real way to drastically decrease traffic would be to load sections dynamically from API. The problem with it is that either people have JS, and JS support is sufficient for our needs, or they will not be able to view pages. Same thing with Jon's proposal - images will be invisible unless JS is supported. Make it opt-in only?

Jdlrobson added a comment.Mar 7 2012, 2:57 PM

Not necessarily. The first page could load as per normal and javascript could be used for future page loads that are done via search. This way the site works for everyone but users of javascript can get a faster mobile experience.

MaxSem added a comment.Mar 7 2012, 3:01 PM

Nice idea, but how do you propose to pass the information about working JS? URL parameter - extra PITA to purge in squids. Cookie - user may disable JS later, even during the same session.

Jdlrobson added a comment.Mar 7 2012, 3:08 PM

Say I open http://en.m.wikipedia.org/wiki/San Francisco without javascript - I can use the search in that I type a search term and click okay and get a list of search results.

If I do have javascript however, javascript could override all the links in the page and the search in the page so that when a future page is loaded it is loaded via javascript.

Say there was a link to California in the San Francisco page. When I click California normally the following happens...

  • request made to the api to get content
  • content put into page via javascript
  • functionality like toggling is added
  • the address bar is updated to point to the new resource (http://en.m.wikipedia.org/wiki/California) [1]

Now the key thing is the page hasn't actually changed - I still have the same javascript and same html. If I hit refresh I load the full page as reflected in the address bar.

Note if I open California in a new window I get a full page load.

So essentially we'd be cutting down quite a few HTTP request and give a quicker experience to many users but not everyone.

[1] https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history

Jdlrobson added a comment.Mar 7 2012, 3:09 PM

http://github.com is a great working example of this

MaxSem added a comment.Mar 7 2012, 3:12 PM

Agreed.

Yair_rand added a comment.Mar 7 2012, 10:18 PM

(Duplicating what I posted on the duplicate bug.) Since this would also need to work for when a user clicks on a link to an anchor, this would require an API module that could be given an ID of an element, and return the ID of the surrounding section along with the complete contents of the section.

MaxSem added a comment.Mar 7 2012, 10:32 PM

(In reply to comment #12)

(Duplicating what I posted on the duplicate bug.) Since this would also need to
work for when a user clicks on a link to an anchor, this would require an API
module that could be given an ID of an element, and return the ID of the
surrounding section along with the complete contents of the section.

If the user will click on link to section's anchor, they will jump to the collapsed section. This doesn't cover just a few cases when there's a custom anchor somewhere in the section - parser doesn't seem to provide this information.

Jdlrobson added a comment.May 8 2012, 11:44 PM

See http://www.mediawiki.org/wiki/MobileFrontend/Dynamic_Sections

yuvipanda added a comment.Jun 24 2012, 2:17 PM

Bug #37095 is equivalent on the app. I've implemented this in the app, awaiting review by Jon.

yuvipanda added a comment.Jun 24 2012, 2:21 PM

And I'll note that images are loaded in the app only when their section is expanded. This is because we load the html for the section into the DOM only when it is first expanded.

Jdlrobson added a comment.Oct 26 2012, 9:43 PM

This is currently deployed in beta mode
It currently has no fallback for older browsers

• Awjrichards added a comment.Dec 14 2012, 9:34 PM

Marking this resolved as support is now in beta.

• Phabricator_maintenance removed a subscriber: yuvipanda.Jun 7 2017, 7:05 PM
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL