aaron added a comment.
From the perspective of popular/major articles, likely to have infoboxes, the extra 42.1 KB for loading the "app" JS doesn't seem crazy. I've looked through code several times and it seems reasonable. Testing with fast/slow 3G doesn't reveal obnoxious reflows or delay either. Having the edit link go directly to a Q<X> page when the JS hasn't fully loaded felt somewhat jarring, though I don't image that happening often. I don't see much editing at all given how discrete the icon is (a good thing). The bootstrapping "init" JS is also pretty tiny. It does have a fair number of module references in the using() call for pages with editable elements. OTOH, those seem to be loaded anyway, with the "app" being the only new thing triggered. The DOM search for editable entity links is just a simple CSS selector call with reasonable metadata extraction. I don't see (nor did I perceive) any CPU use or long task issue there. The client <=> api.php layer looks reasonable and well abstracted. Given the low-key nature of the GUI, I don't foresee any obvious edit rate, DB overhead, nor contention issues. I don't see any reason to block the wikidata-bridge deployment and consider this task resolved from my end. TASK DETAIL https://phabricator.wikimedia.org/T246456 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: aaron Cc: Gilles, Jakob_WMDE, Lydia_Pintscher, Addshore, Krinkle, Aklapper, darthmon_wmde, Michael, Nandana, Jony, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Vali.matei, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
