The code seems to be coming from wikibase.client.data-bridge.init on further inspection.

Even Wikidata is itself a Wikidata client, loading data bridge is meaningless for entity pages.

Change #1153376 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/Wikibase@master] Load wikibase.typeahead.search on both Minerva and Vector 2022

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

Change #1152287 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/Wikibase@master] Load wikibase.typeahead.search on both Minerva and Vector 2022

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

Test wiki created on Patch demo by Jdlrobson using patch(es) linked to this task:
https://patchdemo.wmcloud.org/wikis/49d9fa1128/w/

Change #1153376 abandoned by Jdlrobson:

[mediawiki/extensions/Wikibase@master] Load wikibase.typeahead.search on both Minerva and Vector 2022

Reason:

Folded into https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/1152287

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

Test wiki created on Patch demo by Jdlrobson using patch(es) linked to this task:
https://patchdemo.wmcloud.org/wikis/554a7b92ce/w/

Change #1152287 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Load wikibase.typeahead.search on both Minerva and Vector 2022

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

Seems the above change moved Vue.js out of page load, but according to https://integration.wikimedia.org/ci/job/wmf-quibble-core-vendor-mysql-php81/7183/console (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1153718) the problem still remains for OOUI.

We saw the exact same issue on Wikipedia last week T403127: VisualEditor is loading oojs-ui on desktop page load where we saw significant impact on users via this graph: https://grafana.wikimedia.org/goto/1_Xv2wXNR?orgId=1

• Users were downloading 100kb for every page view which the browser has to parse
• For slower connections this could be making the page 60ms less responsive than before (https://web.dev/articles/tbt)
• Per web.dev performance guidelines "If the task is long enough (anything higher than 50 milliseconds), it's likely that the user will notice the delay and perceive the page as sluggish or broken.

For Wikidata.org I think we fixed the Codex issue but it is still loading both OOUI and additional bytes of code from other libraries so this would suggest something even more significant than a 60ms delay.

https://grafana.wikimedia.org/d/IvAfnmLMk/synthetic-testing-page-drilldown?var-function=median&orgId=1&from=now-2d&to=now&timezone=browser&var-path=desktop&var-testtype=firstView&var-group=www_wikidata_org&var-page=_wiki_Q64&var-browser=chrome&var-connectivity=4g&viewPanel=panel-248 has a lot of useful graphs that may be helpful to look through.

One suggests since last week users on slower connections are being blocked for up to 7.5s (up from 6.8s) before they can use the site (remember 50ms is considered sluggish) !

@Jdlrobson-WMF , the team responsibile for wikidata's UI has has looked into this

while the UI for wikidata is something we'd like to improve, it is not currently a priority. In addition to being complex to change, the majority of wikidata users are interacting via methods other than loading the website (e.g. via API calls).

However, the team is currently working on user's ability to edit statements from their mobile devices (T394621). For this, taking your findings into account, we will introduce on-demand loading for editing assets and then re-benchmark after the project is completed (predicted to be end of this calendar year).

Change #1153718 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] Drop wikibase.client.data-bridge.init workaround

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

Change #1153718 abandoned by Jdlrobson:

[mediawiki/core@master] Drop wikibase.client.data-bridge.init workaround

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