Page MenuHomePhabricator

Make ULS more lightweight
Closed, ResolvedPublic

Description

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.


Version: master
Severity: enhancement

Details

Reference
bz56292

Related Objects

StatusAssignedTask
OpenNone
ResolvedNone
Resolved Nikerabbit
Duplicate Nikerabbit
ResolvedNone
ResolvedNone
Resolvedsanthosh
DeclinedPginer-WMF
ResolvedAmire80
ResolvedAmire80
OpenNone
ResolvedNone
Resolved Nikerabbit
Resolved Nikerabbit
DeclinedNone
Resolvedsanthosh
Resolvedtomasz
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
Resolvedbrion
DeclinedNone
ResolvedNone
Resolvedsanthosh
DeclinedNone
DeclinedNone
Resolvedsanthosh
Resolvedsanthosh
ResolvedNone
ResolvedNone
DeclinedNone
ResolvedNone
ResolvedNone
Declinedsiebrand
Resolvedori
DeclinedNone
ResolvedNone
ResolvedNone
ResolvedNone
Resolved Nikerabbit
OpenNone

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 2:15 AM
bzimport set Reference to bz56292.
bzimport added a subscriber: Unknown Object (MLST).
Isarra created this task.Oct 29 2013, 3:59 AM
  • 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
Screenshot of mw.loader.inspect() from the English Wikipedia, 2013-10-30

Attached:

(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 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!

Attached:

(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

Does someone know if this issue is still present and relevant for T15097? Seems not according to T58464#2452190

Nemo_bis closed this task as Resolved.Jul 12 2016, 11:32 AM
Nemo_bis assigned this task to Nikerabbit.

Things have been improved. We are no longer loading lots and lots of code before user interaction. Now I get jquery.uls.data (31 KB) and few other modules <10 KB.

Phabricator_maintenance renamed this task from Make ULS more lightweight (tracking) to Make ULS more lightweight.Aug 13 2016, 9:47 PM