= TODO
* Measure using webpagetest what a 3kb saving would mean for anons on 3G
= Background
Back in Sept 2015, render blocking CSS for mobile was only 6.4kb for an anonymous user (T97289) with JS disabled.
Since then it's been steadily increasing and it's now 9.3kb.
Render blocking CSS is problematic as it **blocks rendering** meaning that it slows down the time a user **sees content**.
According to real world data [[ https://grafana.wikimedia.org/dashboard/db/mobile-2g?panelId=72&fullscreen&orgId=1 | it currently our 95th percentile of users still wait up to 5-7s ]] to read Wikipedia on mobile devices. The median is just over 1s, so good but not awesome. On a 3G connection the [[ https://grafana-admin.wikimedia.org/dashboard/db/mobile-2g?orgId=1 | Barack Obama article takes around 2s to render ]].
For an anonymous user [[ https://en.m.wikipedia.org/w/load.php?debug=false&lang=en&modules=ext.cite.styles%7Cmediawiki.hlist%7Cmediawiki.ui.button%2Cicon%7Cskins.minerva.base.reset%2Cstyles%7Cskins.minerva.content.styles%7Cskins.minerva.icons.images%7Cskins.minerva.tablet.styles&only=styles&skin=minerva | our render blocking modules ]] are:
* mediawiki.hlist (470bytes)
* mediawiki.ui.button (5kb)
* mediawiki.ui.icon (844bytes)
*skins.minerva.base.reset (555 bytes)
* skins.minerva.base.styles (13.8kb)
* skins.minerva.content.styles (7.4kb)
* skins.minerva.icons.images (5.1K)
* skins.minerva.tablet.styles (1.9K)
= Problem statement
[] A quick run of https://uncss-online.com/ suggests a saving of 2.5kb ( 9.2kb-> 6.7kb) is possible just by trimming unused CSS from the critical path for anons. Caveat: uncss does not work with our icon css
[] This should improve the time to first paint for all our anonymous users, meaning they can access our content quicker
{@todo: add measurements}
[] Our CSS is messy. This is natural for a 6 year old repository. It could do with some cleanup. There are many outdated and unused CSS rules. This makes maintenance more difficult.
= Solution
Modules loaded in the head are as follows:
* mediawiki.hlist (2.0 KiB)
* mediawiki.ui.icon (887)
* mediawiki.ui.button (5.1 KiB)
* skins.minerva.base.reset (645)
* skins.minerva.base.styles (13.6 KiB)
* skins.minerva.content.styles (7.1 KiB)
* skins.minerva.icons.images (5.3 KiB)
* skins.minerva.tablet.styles (2.0 KiB)
To do so we'd make the following changes
= Potential changes
[] Restrict gallery styles in hacks.less to only pages which need it - we currently load all styles for galleries on all pages. We should use mediawiki.page.gallery.styles instead.
[] Separate styles for logged in users from anons - this is a huge saving and mostly focuses around the notification icon
[] Load JavaScript only styles with JavaScript e.g. overlay, touch-events, position-fixed
[] Load mw-ui-button-group and . multi-line and two-line, only on special pages which need it
[] Do not load mw-ui-button on page load - this is a large stylesheet and we should look to load a minimal version on the critical path. This should cover basic padding/colors for a neutral button. We do not use progressive buttons anywhere in the main UI.
[] Remove unused/redundant rules - we've picked up a lot of cruft over the years .mw-mf-banner, .mw-mf-image-replacement, .no-js-edit, .no-js-only, #mw-mf-last-modified seleectors
[] Limit #secondary-action . language-selector rule to main page - this is the only place it can be used
= Micro-optimisations
[] Move display:none rules to MobileFormatter e.g. #filetoc,.mw-editsection
[] Only load .beta code inside beta mode
[] Remove portal-column-left-wide rules to Portal: namespace (especially given the RFC to remove portals and TemplateStyles)
[] Limit return-link css rule to pages that need it
After these changes, when loading page with JS disabled, I see unused CSS rules drop from 60% unused to 30% unused.
= Additional changes to investigate
[] Investigate whether the references-column-count, references-column-count,.column-count and references rules are redundant now given changes to Cite extension
[] Investigate whether lazy-image-placeholder css rules can be loaded via JS
[] Investigate what impact simplifying selectors for table/thumb would have
= Acceptance criteria
[] As well as cleaning up the CSS, comments would be added to the CSS files and style entry points giving guidelines to developers to prevent good word being undone. It would make clear when something is going to be added to critical CSS and when it is not.
= Future plans
Although such an optimisation is unlikely to make much of a change to the start render time, it does go a long way to improving how our CSS is architected and sets us up for loading CSS as an inline style in future.
The leaner the CSS is, the more compelling it would be to inline the CSS in the head of the document per [[ https://developers.google.com/speed/docs/insights/PrioritizeVisibleContent#RemoveUnusedCSS | this recommendation ]]. This would remove the need for an additional HTTP request for CSS and would [[ https://www.smashingmagazine.com/2015/08/understanding-critical-css/ | give us the fastest first paint possible ]].