Reading/Web/Projects/Performance/Lazy loading images

Articles contain lots of images which when loaded can lead to multiple HTTP connections which compete against one another, slowing down the downloading of CSS and HTML. Many of the images loaded are never shown to the user. If we lazy load these images on demand when needed we will cut the size in bytes of the page served to the end user and speed up the downloading and rendering of content. When combined with other changes listed on the project page this could make a huge difference to our end users.

Progress

Lazy loading images was enabled on the production beta channel on the 24th March. As an example, this led to the overall bytes served to users for images on the Barack Obama article dropping from 657kb to 169kb.

On May 9th 2016 (4pm PST) we rolled out lazy loading of images to all users of Bengali Wikipedia. The purpose of this action was to collect data around page views, global NavigationTiming results from a project to guide a future roll out.

On June 23rd 2016 (4pm PST) we deployed lazy loading of images to all users of Farsi and Ukrainian Wikipedias (two medium sized wikis) with the hope of benefiting from the larger audience of those sites and to give more opportunities for feedback.

On Tuesday 5th July lazy loaded images was enabled on Japanese Wikipedia for all users.

This graph shows the impact of lazy loading images in beta in production on the Barack Obama page. Images were lazy loaded from the 24th March, but it must be clarified that the graph spiked due to the appearance of a lead image two days later (which is currently not in the stable environment).

Predicting impact on stable with static files

Static files emulating the lazy loaded images experience vs the current experience were uploaded to the cluster.

First view load was 38.541s for the current experience of the Barack Obama page on a 2G browser. With images lazily loaded under the same conditions first view load was 25.210s - a saving of around 13s and a 35% speed improvement.

Interestingly, our own webpagetest jobs simulating a 2G connection record fully loaded time as already being around the 25s mark. When run here the first load time was 22.787s for the current experience and 18.942s with lazy loaded images - a saving of around 4s - a 17% speed improvement.

The speeds simulated are supposed to be the same, so it is currently not clear which is a more accurate indication of how this change will benefit 2G users and this is being investigated.

Fully loaded times on different connection speeds for static pages representing the Barack Obama article

Speed profile	Without lazy loaded images	With Lazy Loaded Images	Delta	% change
2G	43.066s	25.249s	17.817	41.3
3G Slow	16.031s	11.243	4.788	29.8
3G	13.476s	11.320s	2.156	16.0
3G Fast	9.376	7.264	2.112	22.5

When you look at the 95th percentile for fully loaded time per day across the site in the last month it ranges from 11.5s to 15s. This is somewhere between a 3G Fast and 3G Slow connection. When pushing to stable if our visitor speed profile does not change we would hope to see it range between 7s and 11s. However, it is possible given the large difference in 2G before and after we might see it double if it leads to us obtaining more samples from users on slower profiles.

First paint times on different connection speeds for static pages representing the Barack Obama article

Speed profile	Without lazy loaded images	With Lazy Loaded Images	Delta	% change
2G	12.493s	13.795	-1.302	-10.4
3G Slow	4.353	3.320	1.033	23.7
3G	5.225s	4.096s	1.129	21.6
3G Fast	3.298	3.222	0.076	2.3

When you look at the 95th percentile for first paint per day across the site in the last month it ranges from 4.4 and 5.8s. Again this seems to match a 3G profile. When pushing to production we'd hope this would shift to either 3s or leap to 13s if new samples are collected.

Lazy loading images in production beta

There was a small positive impact on the 95th percentile of beta anonymous and authenticated users in our global metrics.

Impact was less clear in our controlled tests on Barack Obama.

There are many problems with using beta to predict performance impact in production. It should not be used for this purpose:

• Beta has a split cache compared to production so is generally not a reliable environment to predict performance changes - pages often load from an unpopulated cache.
• In beta there is a banner experiment running which greatly increases bytes loaded by introducing an additional image at the top of the page. This does not run in production
• The 95th percentile of beta users have a fully loaded time of 4s, in production it is closer to 11s. This suggests beta users are more likely to use a much faster connection than the types of connection we are targeting in production.

Lazy loaded images on Bengali mobile web Wikipedia

See main article. The data provided by this wiki was very sparse but indicated an improvement to fully loaded time for HTTP1 but not HTTP2.

Lazy loaded images on Ukranian and Farsi mobile web Wikipedia

See main article.

Lazy loaded images on Japanese Wikipedia

See main article.

Lazy loaded images everywhere

See main article.

Next steps

The change has been launched everywhere. A blog post is scheduled for Monday 19th September.

We will now focus time on analyse the impact of Lazy loading references.