| ovasileva | |
| Mar 9 2017, 3:12 PM |
| F6827854: goodnews.gif | |
| Mar 21 2017, 9:19 PM |
We are currently experiencing a number of bugs related to mathematical expressions and lazy loaded images. We would like to find the optimal way to display equations without lazily loading their images:
Current options:
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Disable lazy loaded images in print mode | mediawiki/extensions/MobileFrontend | master | +11 -1 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | ABorbaWMF | T162623 Problems with lazy loaded inline images | |||
| Duplicate | None | T160079 [Spike] Do not lazy load images for math and other symbols |
What about standard images? Are we explicitly saying we don't want those to show and only want symbols.
A definition of symbol would also be useful here.
@Jdlrobson - I suppose the easiest way to do it would be by the size of the image? Unless you can think of something better. Math, chemical nomenclature, subscripts, superscripts, and certain scripts would be the first candidates.
Limiting by dimensions is dangerous. On pages which contain multiple flag elements, there has been evidence that the amount of HTTP requests can saturate browsers on slow connections and compete with other render blocking resources leading to a slower first paint. This was exactly why we defer loaded those as well. We should seek a solution that fixes the printed version but does not jeopardize the performance of all users.
Agreed, but i also think we should look at the pageviews to these pages - while they might be very large if we don't lazy load images, they are probably not within the majority of our traffic.
... but targeting only small images would impact all our pageviews as we don't have a nice way to differentiate say a image that's a flag from a math equation.
Might be best to focus on the Math problem first since it's well contained and known, but we shouldn't try to fix it by loading any images (unless we inline them to avoid an HTTP request...).
It seems we can test whether we are in the print mode via JS using http://caniuse.com/#search=matchmedia which is widely supported
I've written a patch which does just this, for your consideration...
Change 343974 had a related patch set uploaded (by Jdlrobson):
[mediawiki/extensions/MobileFrontend] Disable lazy loaded images in print mode
Change 343975 had a related patch set uploaded (by Jdlrobson):
[mediawiki/extensions/MobileFrontend] Disable lazy loaded images in print mode
@Jdlrobson - I'm not sure I'm following entirely. So when we trigger printing from the browser, we know we're in print mode and can thus load all images? Or would this still be just for server-side pdf's?
Modern browsers run JavaScript after you open a page in print mode. The javascript can thus be aware it is being printed and load all images.
@Jdlrobson I cannot find patches related to this task. The ones linked above are about disabling lazy loaded images in print mode.
Ahh.. I've got the wrong bug it seems. There was a request not to lazy load math images '''in print mode'''. Is there a task for that?
I'm not sure if this was part of the motivation in this task. I'll move back to backlog and make this a subtask of the print task in the mean time.
We are in a trade off situation. Is it more important to keep first paint down or ensure these images load in the print mode?
@Jdlrobson - I think the new task you created covers it in terms of the print mode (thank you!). I'll need to think a bit more as to whether we'll still need to do this as well - moving it to the po column for now.