Agree that removing the citations from search engine indices could cause huge problems. But perhaps this is mitigated by the fact that rel=canonical still points to the desktop version?

But if you hit the Citations page there's no way to come back to the article.

Also think we should highlight that we change the behavior (one extra click) if you do a search and end up on the Citations page (I don't say it's not worth it, only that we should make the visible if we haven't discussed it before).

This is true but I suspect most users will hit back button. A simply "return to page" link under the title should suffice. Can you create a card. I don't think we should be indexing this.

Agree that removing the citations from search engine indices could cause huge problems. But perhaps this is mitigated by the fact that rel=canonical still points to the desktop version?

SEO is a little mystery but as I understand it the desktop is the canonical uri and what gets indexed and the mobile site is only used for optimising. JavaScript is run on indexed pages in some form. If someone is seriously concerned and has a Google contact it would be great to clarify that rather than guess.

Removing sprint 73 tag as not all subtasks are in the current sprint. This is just protocol. I created a separate placeholder goal task.

What's the status of this goal? Stalled?

I found this task when searching for goal-related Phab tasks 🙂

See Problems with existing implementation and T146396
The existing implementation is a little slow on large articles for the first view, but fine on the majority. When the new REST base references endpoint is available we will be able to speed this up significantly.

We rolled it out to the entire of Russian Wikipedia for a month and were aware of no issues with that, so really it's a question of whether to promote this feature from beta to stable or remove the code.

The advantages of doing so are bytes savings on all articles (by up to 50% of HTML) but given HTML is smaller than images they are less significant than the lazy loaded images initiative (which got all the attention).

Product decision from @ovasileva is needed. We should do some work either way - removing the code or promoting it.

In T123328#3778717, @Jdlrobson wrote:

The advantages of doing so are bytes savings on all articles (by up to 50% of HTML) but given HTML is smaller than images they are less significant than the lazy loaded images initiative (which got all the attention).

Removing HTML is not only about size. A huge DOM tree takes time to parse, layout and paint and that definitely has a toll on less powerful devices.

We didn't measure when researching the performance impact of having a reduced DOM tree, that would be very interesting to know to have additional reasons to push for this feature.

Removing HTML is not only about size. A huge DOM tree takes time to parse, layout and paint and that definitely has a toll on less powerful devices.

Right and I think this is valuable work. I just wanted to flag that it was pushed down the priority list because lazy loaded images was seen as more significant a change. TBH even with the slow API calls I think this is any improvement and should be shipped.

We're trying to come up with a JSON API for references. You may want to check out https://www.mediawiki.org/wiki/Page_Content_Service/References and leave feedback at T170690.

Side-note, I'd be very interested in the testing setup for DOM tree performance comparison, as I could need this elsewhere myself.

It is a hard topic to check, I'm guessing real device testing would be needed, as the devtools can only go so far with the network and CPU throttling (no memory constraints, and other real device troubles).

A quick (inaccurate, anecdotal) comparison shows nothing big in terms of performance in the Chrome Devtools (slow 3g, 6x slowdown, after 1 refresh), but if you look closer you can see some differences (see nodes and listeners for example):

• Barack Obama en.wiki
  
• Barack Obama en.wiki (beta, with lazy references)
  

So there are big differences when not loading the references DOM, but we haven't found a good way to measure the impact on real devices. I'd also be very interested to hear how to test the DOM performance, as I'm not sure how we would do it.

My guess would be something like, save static HTMLs (with & without references), serve them locally, access the page with a real device, with the chrome devtools connected to the computer chrome to record. Do a bunch of runs and record them, save the HARs and get the averages and deviation. Repeat for a few URLs.

Very manual, it would be great if we can find a better way to do this kind of stuff.

@Volker_E FYI @Peter has been doing on-device tests at T184527: Test performance win with lazy references on a real mobile phone, and has also improved docs, see T184681: Document how to run performance tests on real phones. He has documented his steps and methods up until now, in case you are interested 👍.

given https://bugs.chromium.org/p/chromium/issues/detail?id=849106 I'm wondering if it would be useful to finish up this work now.

T193221 is our own task for the Chrome upstream bug.

I think like this: This is a generic Chrome problem so it affect all sites on H2 and slow connections where you have a render blocking CSS and it seems the bug gets quite a lot attention from the Chrome developers. So I think we should sit tight for a while and see, maybe they have a way of fixing it. If there's no way for them, then we can take on lazy loading and/or think about other solutions?

Sounds good to me!

Change 506594 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Remove the lazy load references beta feature

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

Change 523983 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/MinervaNeue@master] Drop lazy loading references feature usage

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

Change 523983 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Drop lazy loading references feature usage

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