Last modified: 2014-06-01 08:31:58 UTC
For many users, ULS serves no practical purpose. It is also quite large, which can be problematic if you're not on a first-world internet connection (or are in rural US), is occasionally host to somewhat problematic bugs, and generally is not worth the trouble if you're not part of the target audience. So there should be a way for such people to just turn the thing off, not load it at all, and be happy. I appreciate that adding an option for this has been been wontfixed, though I don't know why, but even without there being an option in the interface, there SHOULD be support in the extension itself to disable it, regardless of where it actually appears. There should be a way for users who are truly and consistently inconvenienced by it to actually solve the underlying problem (such as with a hidden preference or cookie), instead of just hiding it. There should also be a way for third-party hosts to add such an option for their users who also fit the target audience, even if they don't necessarily want it on for everyone. As it is it seems to inconvenience as many people as it helps on wikimedia projects, and isn't very appealing to third-party hosts, either, despite it solving some very real problems facing some of our users as well.
*** This bug has been marked as a duplicate of bug 46306 ***
According to mw.loader.inspect(), ULS appears to be by far the largest contributor to JavaScript load on <https://en.wikipedia.org/wiki/Main_Page>: * jquery.uls * jquery.uls.data * ext.uls.init * ext.uls.webfonts.repository * ext.uls.interface * ext.uls.languagenames * ext.uls.ime And possibly others. This is all for a feature that most users do not use. This is unacceptably large given that the vast majority of users on the English Wikipedia don't use ULS. This is disproportionate resource usage and is a valid bug to address. I'm re-opening this bug with a focus on making ULS more lightweight and acceptably performant.
(In reply to comment #2) > I'm re-opening this bug with a focus on making ULS more lightweight and > acceptably performant. As it sohuld be possible for bug reports to define when they are fixed: When exactly would ULS be "lightweight enough" and "acceptably performant"? Currently I consider this bug report unfixable (and hence INVALID) as requirements are highly subjective and it's impossible to say "and now ULS is performant and lightweight enough so we can close this bug report".
(In reply to comment #3) This isn't a helpful comment. Please don't leave unhelpful comments. Nobody is required to justify a bug report's existence to you. If you can't understand the bug, that's a personal problem. Try following the steps laid out in comment 2 (i.e., run mw.loader.inspect() on the English Wikipedia and look at its output).
Created attachment 13629 [details] Screenshot of mw.loader.inspect() from the English Wikipedia, 2013-10-30
(In reply to comment #4) > This isn't a helpful comment. The way to avoid this is to define when a report can be considered fixed. "Make X faster" is an invalid report as everybody can disagree when it's considered fast enough. Instead, "Make X load within Y seconds" has clear criteria. It's up to requesters to explain and define issues well enough to avoid invalid bug reports, so I disagree with your interpretation.
Lego, Ori, or anyone else who might know: is there a reason that ULS loads anything more than the init script by default? This is what VisualEditor does, as I understand it.
(In reply to comment #6) > (In reply to comment #4) > > This isn't a helpful comment. > > The way to avoid this is to define when a report can be considered fixed. > "Make X faster" is an invalid report as everybody can disagree when it's > considered fast enough. Instead, "Make X load within Y seconds" has clear > criteria. On what hardware? On what connection? Where, geographically? This is not a clear criterium either, and I'd argue that you can't define a "clear" one.
Removed dependency on bug 56514. It no longer is relevant after Gerrit change #93035.
So, as far as we know and until corrected the plan still is, per Erik Moeller, bug 56433 comment 22: > OK, then I'd like to request that the language engineering team implement > that > approach for now, unless there are issues we're overlooking. As noted, we can > attach EventLogging to font activation, and we could potentially also run > notices or calls-to-action in specific affected wikis. We can figure out in > the > next couple weeks if we want to prioritize getting back into a default-on > state > for automatic font delivery for some users/languages quickly, or if this > should > take a backseat to the language team's other priorities. > > But, considering the significant payload added by automatic font delivery, I > think that's a reasonable compromise for now. I appreciate the team's efforts > to improve ULS performance across the board. https://gerrit.wikimedia.org/r/#/c/108024/ was already merged and is supposed to serve webfonts only when strictly necessary. So, once the way forward is detected, we need another report for what's needed to complete the plan.
(In reply to MZMcBride from comment #5) > Created attachment 13629 [details] > Screenshot of mw.loader.inspect() from the English Wikipedia, 2013-10-30 I just added up how many kilobytes the ULS loader's scripts take up once loaded onto client systems using my Mac's Calculator.app, and it came out to 450.2 KB!!! This definitely needs to be fixed!
(In reply to Bryce Glover from comment #11) > I just added up how many kilobytes the ULS loader's scripts take up once > loaded onto client systems using my Mac's Calculator.app, and it came out to > 450.2 KB!!! This definitely needs to be fixed! In which conditions did you make this calculation?
(In reply to Bryce Glover from comment #11) > I just added up how many kilobytes the ULS loader's scripts take up once > loaded onto client systems using my Mac's Calculator.app Such comments are not helpful if you do not provide exact steps to reproduce.
(In reply to Amir E. Aharoni from comment #12) > (In reply to Bryce Glover from comment #11) > > I just added up how many kilobytes the ULS loader's scripts take up once > > loaded onto client systems using my Mac's Calculator.app, and it came out to > > 450.2 KB!!! This definitely needs to be fixed! > > In which conditions did you make this calculation? Oops; I should have mentioned that I just used my Mac's built-in Calculator.app application to add up all of the script sizes from the right-hand side of the table provided as an attachment by MZMcBride in Comment #5. I thought that my source would be obvious! Now that I think about it, though, where exactly did the results provided by that table come from again?
The table is from the output of mw.loader.inspect(). You can also run it from your developer tools console of your browser. But the result of that has a few caveats. ULS has to serve a small svg file(cog icon) to UI. See https://github.com/wikimedia/mediawiki-extensions-UniversalLanguageSelector/blob/master/resources/css/ext.uls.interlanguage.css#L1 You can see the svg with 'embed' more than once. Also note that the ResourceLoader module will have css with the image data embedded. So the RL module have this repeated svg data at client side, it is an image, so it will have some size. While calculating the module size, the total size is javascript, css and this image data(potentially duplicated) at client side. But what matters is bandwidth usage and in this case you will see a big difference between actual bandwidth usage and the uncompressed RL module size at client side. This is because the module is gzip compressed while serving. Gzip is efficient in compressing the duplicated strings. In short, don't take the output of mw.loader.inspect literally.
Change 113957 had a related patch set uploaded by Bartosz Dziewoński: resources/images: Optimize all SVGs (partially by hand) https://gerrit.wikimedia.org/r/113957
Change 113957 merged by jenkins-bot: resources/images: Optimize all SVGs (partially by hand) https://gerrit.wikimedia.org/r/113957
https://www.mediawiki.org/wiki/Universal_Language_Selector/Announcement_Feb2014 https://www.mediawiki.org/wiki/Universal_Language_Selector/Upcoming_development_plan
