| Jdlrobson | |
| Mar 8 2017, 7:41 PM |
| F7535390: Screen Shot 2017-04-13 at 5.13.28 PM.png | |
| Apr 14 2017, 12:14 AM |
| F6343016: Screen Shot 2017-03-08 at 3.16.08 PM.png | |
| Mar 8 2017, 8:19 PM |
| F6341201: Screen Shot 2017-03-08 at 11.40.19 AM.png | |
| Mar 8 2017, 7:41 PM |
According to the reading dashboard there was a spike in CSS on the 24th February (Friday) of about 1kb for Barack Obama and Facebook article. CSS spikes are bad as they can damage first paint. Was this due to the deployment of the new header CSS?
We should investigate this and try to recover this 1kb if possible.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Compress head loaded SVGS | mediawiki/extensions/MobileFrontend | master | +19 -20 |
This might be because of repeated css e.g. https://gerrit.wikimedia.org/r/#/c/339799/2/resources/skins.minerva.base.styles/ui.less
The first paint doesn't seem to be affected:
Given the page size +1kb of CSS doesn't seem big if it doesn't have any negative impact on the first paint time. If taken out of context then, yes, an about 10% increase seems big.
This may not reflect reality. Note this is a moving median. Users on slower 2G connections are likely to be more adversely impacted. Unfortunately we have no simulations of 2G connections any more but in our research CSS was found to be one of the worse offenders in slowing down 2G experiences.
It doesn't seem to be MediaWiki:Mobile.css so this suggests it's something we or another team introduced in Reading-Web-Sprint-92-🍜
Interestingly, the beta cluster did not seem to get impacted which suggests that whatever it was was enabled on the beta cluster already and it was a config change that introduced the spike.
23rd Feb was a Thursday so the change was probably made then.
According to the logs we enabled the new header on cawiki then (https://wikitech.wikimedia.org/wiki/Deployments/Archive/2017/02#Thursday.2C.C2.A0February.C2.A023) ... but that shouldn't have impacted english wikipedia.
I ran git bisect and when I jump to rEMFRf40e153d4485: Allow feature flagging of new header I see a CSS jump of 8.3kb to 10kb for the new header when the new header is enabled.
So conclusion.. pretty sure that new header was the cause in this jump.
We should probably review the CSS a little closer and work out why?
Change 346652 had a related patch set uploaded (by Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Compress head loaded SVGS
The icons alone apparently count for 0.5kb of that increase. https://gerrit.wikimedia.org/r/345487 recovers an additional 0.1kb.
Since this seems to be part of wrapping up the work with the new header I've pulled this into the sprint.
After talking to Baha, I've also created T162319 for a future sprint.
Change 346652 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Compress head loaded SVGS
I see a 0.5KB decrease in CSS size on the beta cluster for Barack Obama's article when comparing today's data to yesterday's (April 5). No change in the Facebook article though. I guess we'll leave the task open for now and check back next week to see if we've recovered all 1KB.
For now. Transition period.
(and to be clear we're not going to recover the whole 1kb... the new header is just more css intensive - it pulls in 2 icons for example. A 0.5kb recovery on production should be sufficient to sign this off)
We recovered about 0.6kb with the deploy of that fix so this looks good to me. As stated before we were never going to recover it all by virtue of having 2 new icons in the new header design.
