Generic tag for current issues that are causing slow server responses or slow/costly client-side payloads.
This is a form of Technical-Debt (use that workboard).
(For the workboard of the Performance Team, see Performance-Team.)
Generic tag for current issues that are causing slow server responses or slow/costly client-side payloads.
This is a form of Technical-Debt (use that workboard).
(For the workboard of the Performance Team, see Performance-Team.)
CentralAuthUser::getBlocks() isn't called in relatively performance-sensitive situations but CentralAuthUser::getLocalGroups() is.
Change #1214646 had a related patch set uploaded (by Reedy; author: Bartosz Dziewoński):
[mediawiki/extensions/CentralAuth@REL1_43] CentralAuthUser: Cache getLocalGroups()
Change #1214645 had a related patch set uploaded (by Reedy; author: Bartosz Dziewoński):
[mediawiki/extensions/CentralAuth@REL1_44] CentralAuthUser: Cache getLocalGroups()
Change #1214644 had a related patch set uploaded (by Reedy; author: Bartosz Dziewoński):
[mediawiki/extensions/CentralAuth@REL1_45] CentralAuthUser: Cache getLocalGroups()
Change #1213583 merged by jenkins-bot:
[mediawiki/extensions/CodeMirror@master] performance: lazy load CM module when VE wikitext editing session begins
Change #1213583 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):
[mediawiki/extensions/CodeMirror@master] performance: lazy load CM module when VE wikitext editing session begins
Yep @A_smart_kitten I agree with you that I wouldn't invest days of work in a partial solution that speeds up just 20 rules. I evaluated that speculation first because it was at first glance the easiest and safer.
@valerio.bozzolan Admittedly I'm out of my depth here, but I'm not sure if async Herald rules would necessarily have to be limited to non-content-affecting actions? I included this in the upstream task I filed:
In T108586#11417857, @Aklapper wrote:In T108586#11414050, @valerio.bozzolan wrote:I would be surprised to see a big number. I expect ~10 results, so no real benefit probably.
In T108586#11414050, @valerio.bozzolan wrote:I would be surprised to see a big number. I expect ~10 results, so no real benefit probably.
This would be a good candidate for using Codex PHP (cc: @Catrope ) and I think we should implement some kind of server-side rendering for this page for a general release. Performance gets more problematic the more cards are loaded on the page (could be an issue for mobile app users who have lots of saved items). When rendering this page via JS, the browser looses the ability to do any preloading or preconnection for image resources and doesn't prioritize them the way it would if the cards were server-rendered.
Change #1212285 merged by jenkins-bot:
[mediawiki/core@REL1_45] ApiResult: Fix "ord(): Providing a string that is not one byte long is deprecated."
Change #1212284 merged by jenkins-bot:
[mediawiki/core@REL1_44] ApiResult: Fix "ord(): Providing a string that is not one byte long is deprecated."
Change #1212283 merged by jenkins-bot:
[mediawiki/core@REL1_43] ApiResult: Fix "ord(): Providing a string that is not one byte long is deprecated."
Change #1212285 had a related patch set uploaded (by Reedy; author: Reedy):
[mediawiki/core@REL1_45] ApiResult: Fix "ord(): Providing a string that is not one byte long is deprecated."
Change #1212284 had a related patch set uploaded (by Reedy; author: Reedy):
[mediawiki/core@REL1_44] ApiResult: Fix "ord(): Providing a string that is not one byte long is deprecated."
Change #1212283 had a related patch set uploaded (by Reedy; author: Reedy):
[mediawiki/core@REL1_43] ApiResult: Fix "ord(): Providing a string that is not one byte long is deprecated."
Change #1212225 merged by jenkins-bot:
[mediawiki/core@master] ApiResult: Fix "ord(): Providing a string that is not one byte long is deprecated."
P.S. in phabricator.wikimedia.org - has it ever been necessary to manually disable Herald rules for de-activated ("disabled") users? Just to know whether to open another upstream feature request (yum).
In T108586#11259630, @A_smart_kitten wrote:Noting that after asking upstream (https://we.phorge.it/Q207) about the possibility of Herald rules running asynchronously
got the script and PNG working locally
A new SVG sanitizer has been built (originally for T407783, hack attempts welcome!), which could be used for client-side rendering. This would avoid the security issues from users opening the image in a new tab, even without a CSP policy. Essentially, we could keep the transformation step but do SVG -> sanitized SVG instead of SVG -> PNG. While we're at it, multilingual SVGs can be handled with some postprocessing to avoid client-side language selection (process elements with systemLanguage attribute and check if it matches the lang= of the thumbnail - remove the attribute if it does, or remove the element if it doesn't).
entrypoint: [] command: "npm start"
and add under its environment:
NODE_OPTIONS: --expose-gc