Could you provide some data what "slower" means (e.g. via Firebug and/or Firefox Developer Tools)? Do you know if other users (Village Pump discussions etc.) have also faced this problem?

Eugene.Zelenko wrote:

Browser waiting while reading bits.wikimedia.org much more often. Before USL deployment it was ~ once in 20 minutes.

I think Live HTTP headers will be best tool to investigate problem.

Previous discussion about frequent bits.wikimedia.org fetches was in wikitech mailing list.

Note to myself: wmf4 was deployed on May 15 to Commons, ULS on May 20: https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=71004&oldid=71003

Still needs some specific data in this bug report, e.g. for "reading bits.wikimedia.org much more often" - filenames, time it takes until loading successfully etc.

In my case (using Firebug), some fonts seem to not load successfully, e.g.
https://bits.wikimedia.org/static-1.22wmf4/extensions/UniversalLanguageSelector/data/fontrepo/fonts/IranianSans/IranianSans.woff?version=1.0&20120101

Eugene.Zelenko wrote:

Live HTTP Headers log

I opened file page, user contributions page, user talk page, then left message on user talk page and deleted file.

attachment LiveHTTPHeaders.log ignored as obsolete

Eugene.Zelenko wrote:

Live HTTP Headers log

I opened file page, user contributions page, user talk page, then left message on user talk page and deleted file.

attachment LiveHTTPHeaders2.log ignored as obsolete

Eugene.Zelenko wrote:

I attached couple of Live HTTP Headers logs.

My actions: I opened file page, user contributions page, user talk page, then left message on user talk page and deleted file.

Logs were made in "warm" state, after several of similar deletions.

The content of attachment 12393 has been deleted by

Sam Reed (reedy) <sam@reedyboy.net>

who provided the following reason:

Personal data

The token used to delete this attachment was generated at 2013-05-25 14:55:50 UTC.

The content of attachment 12394 has been deleted by

Sam Reed (reedy) <sam@reedyboy.net>

who provided the following reason:

Personal data

The token used to delete this attachment was generated at 2013-05-25 14:56:08 UTC.

I don't see any reliable data here yet what "slow" exactly means, hence it's also impossible to define/discuss what is "too" slow. It's normal that loading takes longer if more stuff gets loaded, so I don't see a valid bug yet.

If it is extremely slow, please provide data (without personal data included).

Eugene.Zelenko wrote:

Sorry, my log file were deleted because of personal data. I could sent them via e-mail.

You could try to reproduce them with Firefox Live HTTP Headers extension yourself of both Commons and Wikidata.

Just in case: I use User Messages and Quick Delete gadgets on Commons, slurpInterwiki, Preview, labelLister, AuthorityControl, CommonsMedia gadgets on Wikidata.

Please don't forget that not everybody has fast Internet connection or free unlimited traffic. So forcing more traffic because of extension (mostly decorative in my case) is bad idea.

Alternatively extension could provide way to turn off functionality completely.

(In reply to comment #10)

Sorry, my log file were deleted because of personal data.

That should not block you from defining what "slower" means. :)

So forcing more traffic because of extension (mostly
decorative in my case) is bad idea.

The improvements provided by the extension are considered more important than the amount of additional traffic (about how many bytes do we talk?). If you want to avoid costs I'd rather switch off images by default, etc.

Eugene.Zelenko wrote:

I think you could try 56 kbit mode to replicate slowness :-)

Please note that if extension functionality is not used, its value is equal to zero.

Images may provide value for user, but almost constant fetching of bits.wikimedia.org without apparent reason is not.

To clarify, is this merely about time spent transferring data from the server or other problems like timeouts, repeated HTTP requests, CPU usage, memory consumption and so on? Does it happen on all page loads or is it something that happens occasionally (albeit too frequently) as this seems to suggest:

(on comment #2)

Browser waiting while reading bits.wikimedia.org much more often. Before USL
deployment it was ~ once in 20 minutes.

?
This is the kind of clarification about "slowness" that devs are seeking, I think.

Eugene.Zelenko wrote:

I think it mostly transferred data size related. From point of view that bits.wikimedia.org content should not be changed every minute, it's repeated HTTP requests.

It happens not for every opened page, but at least for majority of opened pages.

Providing an option to disable ULS is not planned, see bug 46306.
Note though that ULS can be disabled for anonymous users (bug 42157).

I still cannot see a valid bug in this report.

Eugene.Zelenko wrote:

Sorry, I tried my best to explain a problem.

Please try Live HTTP headers. If you'll notice repeated accesses to bits.wikimedia.org, it's good idea to investigate why it happens.

If bits.wikimedia.org was not changed at that time, such fetching is waste of time and bandwidth on bot WMF servers and users sides.

Closing this as works for me. No actionable data has come to light in the past 16 comments.