Page MenuHomePhabricator

Only load tablet styles when on not on mobile
Closed, DeclinedPublic

Description

We currently load styles for tablet devices but we might want to consider conditionally loading them to minimise the first paint time or at least loading them at the bottom of the page - they are 4kb.

Spike: Arrange a meeting with the performance team and discuss and decide on an approach going forward for loading tablet styles
Duration: 2hr
Output: Update this card detailing what we need to do (if anything) for MobileFrontend
Do it <we can re-estimate if our guess is not correct>.

Related Objects

Event Timeline

Jdlrobson assigned this task to Gilles.
Jdlrobson removed Gilles as the assignee of this task.
Jdlrobson raised the priority of this task from to Medium.
Jdlrobson updated the task description. (Show Details)
Jdlrobson removed a project: Patch-For-Review.
Jdlrobson set Security to None.
Jdlrobson added subscribers: Jdlrobson, gerritbot, phuedx and 2 others.

Change 209505 had a related patch set uploaded (by Florianschmidtwelzow):
Load tablet styles only on tablets

https://gerrit.wikimedia.org/r/209505

So I guess we don't want to do this since they cause visible styling changes.

I proposed an alternative solution at some point of the changeset which would still work. Basically don't load the tablet styles in the head, but on tablets hide the DOM with a CSS class until the tablet styles have been loaded. Performance will be roughly the same as the status quo for tablets, and will be improved for everything else. They key to this is to make the tablet/non-tablet detection as small as possible, as it will have to live in the head (in order to reveal/hide the body accordingly).

So when would we hide the content area? We need to consider possibilities such as the CSS for tablets never being loaded due to a drop of connection.

Rather than loading with JS it seems like this could be achieved by putting

@media all and width > 768px {
.visual-editor-style-loader-bar { display: block; }
#content { display: none; }
}

Add tablet styles to bottom of page which turn off loader.

@media all and width > 768px {
.visual-editor-style-loader-bar { display:none; }
#content { display: block; }
... everything else...
}

You can reveal the content in its non-tablet style state in case of error or timeout on the RL load of the tablet styles.

@Jdlrobson & @Gilles: I'm not sure, if this is a good idea. Hiding content until the tablet styles are loaded sounds like a bad idea to me. Think about a 2G connection, or a very slow connection in a train, where you "just want to read a Wikipedia article", and you have to wait seconds on a white page (or a page with just the header, doesn't matter) before you see the content :/

Again, remember that everyone is already waiting for that time right now because those styles are blocking in the head. It would make things much better for non-tablet, and only slightly worse for tablets due to the latency of the extra round-trip.

Sure, but i'm still not sure, how we should implement it. If we want to do that, we need to add the hidden class with JavaScript, but if we are able to execute JS, the user normally already see the content. What am i missing?

Florian subscribed.

Implementation would require identifying survival tablet style (maybe that's what Jon included above), i.e. tablet styles that make the content jump. Tablet styles that don't make the content drastically jump should be in their own module, to be lazy-loaded.

Inside the head JS, we should check whether we're dealing with a tablet or not. If we're not on a tablet, there is nothing more to do or load. If we're on a tablet, we add a class to hide the body. Then in some bottom-loaded JS, we load the tablet styles. When that's done or if we time out, we remove the hiding class from the body to reveal the page.

One thing to be careful with is that if we want the lazy-loaded styles to work in no-JS mode, they will be added as a <script> tag at the bottom of the page. Meaning that we can't tell when it's done loading and that we'll have RL load the same content. We should be careful to hit the same URL in both cases. A compromise here could be to decide that no-JS doesn't get the non-survival tablet JS.

Current timeline, commons for JS and no-JS, tablets and non-tablets:

Page starts loading -> head loads, with all styles (regular + tablet) -> page appears

No-JS timeline after proposed change:

Page starts loading -> head loads with regular styles + survival tablet -> page appears -> rest of tablet styles load

Tablet JS timeline after proposed change:

Page starts loading -> head loads regular styles + survival tablet, tablet is detected and we hide page -> page should appear but doesn't -> tablet styles load (or load times out) -> page appears

Non-tablet JS timeline after proposed change:

Page starts loading -> head loads regular styles + survival tablet, tablet is not detected, do nothing special -> page appears

Note: the file is actually pretty tiny so I don't think this is that high a priority. I'm not sure what is causing a content jump - the only thing I can think of is the max width and margin of the content area but I'm wondering if that could be done in a more clever way.

Change 209505 abandoned by Florianschmidtwelzow:
Load tablet styles only on tablets

Reason:
Currently not working on it

https://gerrit.wikimedia.org/r/209505

Jhernandez lowered the priority of this task from Medium to Low.Aug 28 2015, 12:09 PM
Jdlrobson renamed this task from Only load tablet styles when on not on mobile to Spike: Only load tablet styles when on not on mobile.Sep 1 2015, 11:10 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson renamed this task from Spike: Only load tablet styles when on not on mobile to Only load tablet styles when on not on mobile.Sep 1 2015, 11:16 PM
Jdlrobson updated the task description. (Show Details)

I don't think we should do this. The styles are significantly small to have little impact on first paint and not loading on startup could have unexpected results for certain devices where something as simple as a device rotation may trigger the loading.