Yes I am talking about the wait, not the data limit. Sometimes people just
want the lead paragraph text and don't want to wait for images in the rest
of the article. We have lots of very long articles on English Wikipedia,
sometimes dotted with images as well. Wikipedians who work on them tend to
have very fast, high quality connections and never stop to think whether
their beautiful long article is making some reader wait who has a slow
connection.
On Thu, Sep 1, 2016 at 1:08 PM, Isarra Yos <zhorishna(a)gmail.com> wrote:
On a slow desktop connection, lazy-loading is
generally the opposite of
what you want - unlike mobile, there's usually no data limit, it just takes
awhile getting the data. A common pattern is thus to start a large page
loading and then do something else, or just wait for it to finish then.
It's like buffering video, so that way you have it all there when you
actually go to it, and when it finishes, it's done. Lazy loading prevents
such an uninterrupted experience by forcing the user to instead sit through
every slow-loading image/section, with no way to avoid it.
For mobile, though, where you need to worry about running out of data but
generally have much faster speeds, lazy loading makes a lot more sense.
It's great that we have it here!
-I
On 26/08/16 16:47, Jane Darnell wrote:
Interesting to see the drop in bytes sent to the
Japan article and this
makes me think we should "fold up" article sections on desktop too for
very
long articles, such as the Japan article. The benefits for mobile are
obvious, but this may be beneficial for slow desktop connections as well.
---------- Forwarded message ----------
From: Jon Robson <jrobson(a)wikimedia.org>
Date: Tue, Aug 23, 2016 at 5:20 PM
Subject: [WikimediaMobile] Mobile site is now lazy loading images
To: mobile-l <mobile-l(a)lists.wikimedia.org>rg>, Wikimedia developers <
wikitech-l(a)lists.wikimedia.org>
FYI after much experimentation, research and testing the mobile site has
been lazy loading images [1] since Thursday 18th August. This means if you
do not see an image you will not download it. We have taken care to ensure
users without JavaScript can still view images and that most users will
barely notice the difference.
We are currently crunching the data this change has made and we plan to
write a blog post to reporting the results.
In our experiments on Japanese Wikipedia we saw a drop in image bytes per
page view by 54% On the Japanese Japan article bytes shipped to users
dropped from 1.443 MB to 142 kB.
This is pretty huge since bytes equate to money [3] and we expect this to
be significant on wikis where mobile data is more expensive. In a nutshell
Wikipedia mobile is cheaper.
As I said blog post to follow once we have more information, but please
report any bugs you are seeing with the implementation (we have already
found a few thanks to our community of editors).
~Jon
[1]
https://www.mediawiki.org/wiki/Reading/Web/Projects/
Performance/Lazy_loading_images
[2]
https://www.mediawiki.org/wiki/Reading/Web/Lazy_loading_
of_images_on_Japanese_Wikipedia
[3]
https://whatdoesmysitecost.com/
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wik
i/Mailing_lists/Guidelines
New messages to: Wikimedia-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wik
i/Mailing_lists/Guidelines
New messages to: Wikimedia-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>