HomePhabricator

resources: Remove `@embed` where it may do more harm than good

Description

resources: Remove @embed where it may do more harm than good

With the new practice as of T121730, @embed should be avoided by default
unless there is a specific rationale for opt-in.

For the cost of using @embed in a nut shell, see "Best practices" in
task description of T121730.

Actual changes:

  • jquery.tipsy (JS module): This is dependend on by code that might create tooltips, but doesn't always (depends on user-interaction, not lazy-loaded), so avoid the embedding. Also, the image merely provides an extra arrow sticking out from the bubble. It uses alpha transparancy and the bubble still looks fine without the arrow. Let it render afterwards instead.
  • jquery.tablesorter.styles (Style module): These styles only apply when the browser supports JavaScript. For those, we generally expect and require SVG support. As such, remove the PNG fallback for these. Also, tables are rarely used above the fold, so don't delay rendering of the article text on these icons. Their space is reserved (no risk of layout-shifting FOUC), and the icons have long-expiry headers so they will display instantly on non-first views in a browsing session (0 RTT).
  • filepage The embedded background pattern blocks rendering. Affects file description pages. The image is only used below the fold (in the history) or if the user interacts (hover). Does not need to block rendering for the page as a whole. Also, it falls back gracefully as the pattern is mostly the same color as the fallback color (white), which is now visible slightly longer when the user first hovers an image if the background pattern isn't cached yet.
  • redirectPage (Style module): The embedded icon blocks rendering. The primary content makes sense without this icon, the space is visually reserved (no FOUC, or visual breakage). Not important enough to block on. Also, it embedded both RTL and LTR versions, but used only one.
  • mediawiki.feedlink (Style module): The embedded icon blocks rendering and has no shared caching between features. Affects action=history, Watchlist, and various special pages. Shows an icon in the sidebar (below the fold). Not worth blocking on.
  • mediawiki.htmlform (Style module): The embedded icon blocks rendering. It is used for checkbox-matrix fields in an HTMLForm, such as Special:BotPasswords. The icon's space is reserved already (avoids FOUC) and is not more important than skin layout and general interface text, so fine to load zero or more paint frames later.
  • oldshared.css (Style module) and mediawiki.skinning (Style module): The embedded icon blocks rendering and has no shared caching between different kinds of articles. Affects all articles.

    The icon is used in the corner of thumbnail frames, usually below the fold. Space is reserved (no FOUC). Not worth blocking on. Also, it embedded both RTL and LTR versions, but used only one.
  • mediawiki.special.userlogin.common.styles (Style module) The embedded icon blocks rendering. Affects the login page for all users, but the icon is rarely used (only if $wgSecureLogin is true, which is not very common these days, with HTTPS-by-default). Most users will never see this. The feature is also buggy and should probably be removed (T156320, T149977, T219350, T180886, T55197).
  • mediawiki.special.userlogin (Style module): The embedded image blocks rendering. Affects the login page for all users. It is the "people silhouette" towards the bottom of the login form. The space is reserved (no FOUC), and the fallback color (white) is similar to the tone and feel of the image (white with some grey). Should not delay rendering of the form itself.
  • mediawiki.widgets.MediaSearch: Not used in core. Mainly used by VisualEditor. The embedded image blocks all loads of the editor for users, even if they don't end up interacting with the "Insert media" dialog. Even then, it is only used if a thumbnail failed to load (e.g. because of an internal server error with the generation of the thumbnail file). Until that point, the canvas in which the thumbnail is shown by VE media search results, is empty, and removing @embed here just means it will remain blank a little bit longer for the case of the thumbnail file being broken and the user not having hit that scenario before (cached icon), until the icon is requested/loaded as well.
  • mediawiki.less: This changes the mixin functions ".background-image-svg()" and ".background-image()" to also no longer embed their respective icons. This affects 'mediawiki.helplink' (e.g. question mark on action=history), and 'mediawiki.skinning/content.externallinks' in core, as well as most icons used in extensions such as WikiEditor and MobileFrontend. Full list for core, can be found at: https://gerrit.wikimedia.org/r/539422. Basically, the same applies to all of this: The icon is not more important than the layout and overall content of the page, and should render concurrent to the page instead of synchronously before it. Referencing them by URL in this way, also allows more efficient use of caching, and makes more efficient use of LocalStorage by not including icons there that can be referenced from the HTTP cache instead.

Bug: T121730
Change-Id: I888c111ffb2e1629ea01eca38b660fe59995cca7

Details

Provenance
KrinkleAuthored on Jul 26 2019, 4:35 PM
Parents
rMWbcbd880b1310: user: Fix documentation of User::mBlock and related
Branches
Unknown
Tags
Unknown
ChangeId
I888c111ffb2e1629ea01eca38b660fe59995cca7