Last modified: 2014-01-21 20:38:49 UTC
Created attachment 14294 [details] 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.
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.
Created attachment 14295 [details] Screenshot article Attaching image and copying URL for the records https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FUniversalLanguageSelector/23c961e4ba812ae75c791d7d31c9bb74f0a037c9/tests%2Fbrowser%2Ffeatures%2Fautonym.feature#L32
Change 107028 merged by jenkins-bot: Wait till rendering thread completion before applying webfonts https://gerrit.wikimedia.org/r/107028
Created attachment 14331 [details] Graph showing drop in bandwidth utilization of Bits caches after syncing I2da436caa
(In reply to comment #7) I suppose this bug should no longer be marked PATCH_TO_REVIEW.
Created attachment 14348 [details] 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.
(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).
