Page MenuHomePhabricator

ULS loading language-specific fonts for interlanguage links
Closed, ResolvedPublic

Description

Waterfall diagram showing impact on latency and resource utilization

On http://en.wikipedia.org/wiki/Conjunctivitis, UniversalLanguageSelector loads just under half a megabyte of fonts (490.2 Kb). By comparison, the combined size of all other resources -- that is, *all* javascript, CSS, images and text -- is 346 Kb.

The impact on page performance is severe. It is clearly noticeable even on a high-bandwidth, low-latency connection. The attached image shows the font requests saturating bandwidth, then CPU as they are retrieved and rendered.

More details here: http://www.webpagetest.org/result/140111_D1_TEV/1/details/

WebKit browsers hide text until the font is available. This causes the interlanguage links for which ULS is overriding the system default font selection to appear in one font, vanish for several seconds, and then re-appear in a different font. I recorded this on my laptop: http://www.youtube.com/watch?v=J3Wd7d8Y7wE. Note that I am using a bleeding-edge browser version and connecting to the internet via a broadband connection.

In my assessment, the frequency and regularity with which this issue has recurred makes it clear that ULS's strategy for loading web fonts is fundamentally misguided. I do not consider a selector exemption to be an adequate solution to this bug.


Version: unspecified
Severity: normal

Attached:

uls-waterfall-11-jan-2014.png (295×930 px, 8 KB)

Details

Reference
bz59958

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 2:39 AM
bzimport set Reference to bz59958.
bzimport added a subscriber: Unknown Object (MLST).

Premises don't match conclusions.

(In reply to comment #0)

On http://en.wikipedia.org/wiki/Conjunctivitis, UniversalLanguageSelector
loads just under half a megabyte of fonts (490.2 Kb).

By the current design, it's supposed to load only about 50 KB for interlanguage links. If it doesn't, maybe that's the problem? Or the problem is not what in summary. In any case, the conclusion is not currently justified.

(In reply to comment #1)

By the current design, it's supposed to load only about 50 KB for
interlanguage links. If it doesn't, maybe that's the problem?

It doesn't. That's the problem.

(In reply to comment #2)

(In reply to comment #1)

By the current design, it's supposed to load only about 50 KB for
interlanguage links. If it doesn't, maybe that's the problem?

It doesn't. That's the problem.

Are you sure it's loading fonts other than autonym for interlanguage links on that page? (You should be able to check by emptying the page.) If yes, I suggest to include information on what fonts get included that shouldn't, preferably with clear steps to reproduce/exact conditions triggering the mistake, and that can be addressed specifically.

Change 107028 had a related patch set uploaded by Santhosh:
Wait till rendering thread completion before applying webfonts

https://gerrit.wikimedia.org/r/107028

The issue is present but not consistently reproducible. See http://i.imgur.com/W49VKZV.png

That could be the reason why browser tests(http://goo.gl/TMhdMg) did not pick up this.

Change 107028 merged by jenkins-bot:
Wait till rendering thread completion before applying webfonts

https://gerrit.wikimedia.org/r/107028

Created attachment 14331
Graph showing drop in bandwidth utilization of Bits caches after syncing I2da436caa

Attached:

bits-after-I2da436caa-deploy.png (388×747 px, 32 KB)

(In reply to comment #7)

I suppose this bug should no longer be marked PATCH_TO_REVIEW.

Created attachment 14348
bits bandwidth investigation around 1.23wmf10 wikipedias deployment peak, #wikimedia-operations, 2014-01-16

Ori pasted logs with context at https://gerrit.wikimedia.org/r/#/c/108192/ , apparently also related.

Attached:

(In reply to comment #10)

Ori pasted logs with context at https://gerrit.wikimedia.org/r/#/c/108192/ ,
apparently also related.

That was committed and merged upstream too. I assume this is fixed, file a new report if needed. The general discussion continues at bug 56292 (mostly superseded by the axe-approach at bug 46306 though).