Reading/Web/Projects/Barack Obama in under 15 seconds on 2G

Tracked in Phabricator
Task T113066

The problem

If you have a 2G connection your Wikipedia experience is terribly slow. This leads to third parties transcoding our pages. We need to make this faster. This was highlighted as an issue back in 2012 but still hasn't been solved. It's time to fix that.

2G usage in the world

• First lets look what kind of connections people uses in the world. Almost no one has 2G in North America but the rest of the world the situation is different.
• Then it becomes really interesting by looking at the same numbers but scaled by market size.
• 62% of mobile contents are 2G across the world

Next 5 years

This graph shows us what the growth will look like for smartphones: The growth will happen where there's a lot of 2G users.

Proxy browsers?

But what about "proxy" browsers? A proxy browser is a browser where the content is prepared on the server side like Opera Mini, UC or Chrome with data reduction turned on. These browsers are mostly used where the connection type is slow and make the browser experience better. The numbers I've found doesn't perfectly add up but it seems like these browsers are still a fraction of the internet traffic. The first image shows percentage by OS where proxy browser are in the **others**.

And this chart show how much is actually by individual proxy browser.

This shows proxy browser users are a fraction of the total browsers.

All the graphs are taken from Tim Kadlecs talk Better By Proxy and Maximiliano Firtmans talk [Extreme Web Performance for mobile devices.

Google web light

Google provides a service in various countries that minimises our content payload, for example https://googleweblight.com/?lite_url=https://en.m.wikipedia.org/wiki/Barack_Obama. It does so at the expense of the experience and we never see this traffic. We have a responsibility to remove the need for this product on our projects by providing a faster experience.

Problems with Google Web Light from a movement perspective:

• Access to only a subset of features (No edit button, talk)
• Bad user experience
• No control (all routed via Google's servers)

We can opt out of Google Web Light but before doing so our users deserve a compelling product.

Conclusion

The majority of the mobile users in the world uses a 2G connection, the growth will happen in the countries where the 2G usage is highest. And proxy browsers usage is low so it doesn't solve the problem. We need to have a site that is fast on 2G.

Assertions

• The majority of users only read the lead section - only 39.9% of users opened a section according to our data.
• 30.5% of our users supported service worker (Nov 2015) according to this data.
• 50% of the HTML of a good quality article are references and navbox templates according to this data.

The how

The main issues are serving unnecessary content to mobile users that may not be used. This includes non-essential content and images. We believe by switching the mobile web site to Parsoid we will gain more control over the content we display to users. We believe we can initially serve just the HTML of the lead section and load the rest of the content, images included, via JavaScript, without ruining the existing experience for users who are fortunate enough to have a good connection. Switching to Parsoid will also allow us to create a more modern Wikipedia experience.

This will decrease the time the user gets to first paint and the time they get to first interactive. The later data point is important as when a user has fully loaded JavaScript this means we can also install a ServiceWorker for them - meaning on future visits we can cache browser Chrome, styles and previously visited pages.

Experiments

Loading just lead sections

Test 1

We took the top 5 pages from an arbitrary week in September and duplicated them on a MediaWiki instance. For each version we created a duplicate which only contained the lead section and tested speed on both 2G and 3G connections.

Analysing the data we collected we found that on this small sample of pages, the following was true:

• A median of a 40% decrease in total bytes shipped to user - the total bytes saved by such a move were around 40% decrease in page size, and a 31% decrease in the number of bytes needed to enable the first view of the content to the user.
• A median of a 22 percent decrease in time to first render on a 3G connection
• A median of a 31 percent decrease in time to first render on a 2G connection
• A median of a 12 percent decrease in time to fully load the content on a 3G connection
• A median of a 36 percent decrease in time to fully load the content on a 2G connection
• On the largest article in the sample, en:Serena Williams
  • there was a 47% decrease in time to first render on 3G, and 36% on 2G.
    • This equated to a saving of 4.9 seconds - 14 to 9s.
  • there was a 55% decrease in the time to fully load on 2G (32% on 3G)
    • This equated to a saving of 152.611s on the 2G connection

Conclusions

• Although obvious, reducing the size of the HTML shows promise that it will impact first paint and first interactive time (based on the lower fully load time) significantly.

Next steps:

• We need to test on a much larger sample to get a sense of the overall impact of these changes and the median improvement we can expect to see.
• The entire article should still be available.
  • We'll need to analyse where savings can be made by identifying content that can be defer loaded.
  • We'll need to measure whether simply loading lead section will satisfy a certain percentage of users (and what percentage that is)

Experiments with article composition on 2G

See A frontend powered by Parsoid/HTML content research

Experiments with Parsoid inside MediaWiki

An API specifically for optimising content sent to users could drive an entirely new mobile web app built in JavaScript (running on server side in Node) which uses MediaWiki as simply a storage space, editor and API that lives outside MediaWiki but on the same server. The API could also be used instead of the PHP parser, inside MediaWiki to generate the mobile reading experience, which already defers features such as talk, editing and categories to the API and JavaScript. Both of these experiences provide a reading experience faster than the current experience .

This was built using an extension called LootFrontend.

Integrating changes into Production

To achieve an improved first paint/fully loaded time for all users on a 2G connection we plan to lazy load images, references and other secondary content.

• Lazy loading secondary content
• Lazy loading images
• Lazy loading references
• Inlining CSS

Actions taken

Removal of srcset attributes

• As of 17th February 2016 (00:54) the mobile web site no longer serves srcset attributes. For the Barack Obama article this halved the amount of bytes we shipped to users from 1.12mb to 450kb.

  

Removal of secondary content

See Lazy loading secondary content.

Lazy loading images

See Lazy loading images.

Lazy loaded references

See Lazy loading references.

Key Results

At the start of the quarter the Barack Obama page was HTML 185KiB, Images accounting for 1.35MiB with average render time on a 2G connection at 10.16s and average fully load time at 24.3s (measurement taken on 4th February taken from grafana)

By the end of the experiment we hope for:

• Barack Obama to fully load in under 15 seconds on an emulated 2G connection
• Bytes per page view drops for all readers as demonstrated in text cache eqiad (bytes of HTML served) and upload cache eqiad.(bytes of images served)
• A visible impact on the global metrics for the upper value (worst case) fully loaded time - either a significant drop (due to speed improvement) or a significant increase (due to more data being collected for connections slower than reliable 2G).

It is hoped we may also see:

• First paint increase across the site (counter-intuitively due to more traffic from slower connections and our ability to collect data for them)
• Overall page visits for site increase due to increased engagement by lower end connections
• Mobile web service does not deteriorate e.g. there is not an increase in outages
  • Edit/View response time does not deteriorate significantly.

Join the conversation

This task is being tracked on Phabricator and we'd love to hear your thoughts.

Further reading

• Lazy load your images with a Service Worker