Change 230286 had a related patch set uploaded (by Krinkle):
Do not embed images in file modules as data URIs

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

@Krinkle / @Peter to discuss next steps.

Raising priority. At the very least, there should be no data URIs in above-the-fold CSS. @Krinkle, could you take this on?

Change 257887 had a related patch set uploaded (by Krinkle):
[WIP] resourceloader: Disable CSSMin data URI embedding

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

Change 257888 had a related patch set uploaded (by Krinkle):
[WIP] resourceloader: Disable CSSMin data URI embedding

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

Change 257888 abandoned by Krinkle:
[WIP] resourceloader: Disable CSSMin data URI embedding

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

Change 257887 abandoned by Krinkle:
[WIP] resourceloader: Disable CSSMin data URI embedding

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

@Peter and I did some research today with https://gerrit.wikimedia.org/r/257887 applied to test.wikipedia.org and comparing the before and after in WebPageTest from various browsers and devices.

We previously felt like the browser (especially on mobile devices) were spending a lot of time parsing, processing, and other synchronously allocating image objects for images found in data URIs in the stylesheet.

However after removing all data URIs and replacing them with regular urls that point to the same resource, we found no notable speed gain. Not on desktop/Chrome and not on a real Android device.

A few observations:

• Bandwidth gained. The main CSS request went from 12K to 8K (presumably due to omission of embedded data URIs). Naturally some of these images were now requested separately (amount to about 1.5K). That's still a 2,5K win, presumably due to no longer loading images that aren't used and/or from the lack of base64 inflation.
• loadEnd regressed slightly. There is a longer tail of requests in the waterfall. Despite HTTP/2, the tail is longer because these requests start much later. This is an inevitable problem because browsers (by design) only request images referenced by CSS for style rules that apply to elements on the page, which is only known after said elements are parsed.
• Content images earlier. Images used in the content (e.g. the first main image of the article) are requested earlier and rendered earlier. Previously it requested the stylesheet first, but now in most cases it requests the images first. They download in parallel as before. But the first non-blank render used to be 52% (article without logo and no image), but is now 73% (image included in first render).

Other WebPageTest runs:

Desktop:

http://www.webpagetest.org/video/compare.php?tests=151209_DR_REX-r:1-c:0 (before)

http://www.webpagetest.org/video/compare.php?tests=151209_6R_SPT-r:3-c:0 (after)

• Before: Text and icons (e.g. lock badge) are in first render. Image and rest in final render.
• After: Text in first render. Icons, image and rest in final render.

Both cases, first render is at the same point, so we didn't get text earlier. Regression.

Mobile:

http://www.webpagetest.org/video/compare.php?tests=151209_AY_RJS-r:3-c:0 (before)

• Before: Text and icons (e.g. hamburger menu) in first render. Infobox image in final render.
• After: Text and infobox image in first render. Icons in final render.

Having the image in the first render is nice, but in "after" first render was actually 0.3 seconds later. (from 1.9s to 2.2s). So it actually delayed rendering of text (and extension of the blank canvas) by 300ms. But at the gain of having the image in the first render. But with the side-effect of icons popping in much later (potentially distracting).

Either way, the final render ("settled") was also later still. So a loss in almost all ways, except for the small bandwidth gain in the CSS payload.

Action items:

• Removing data URIs globally doesn't seem to have measurable positive impact. We should not consider embedding to be an anti-pattern.
• Saving bandwidth for unused resources is still worth pursuing. We should audit individual uses of @embed and consider removing them from places not commonly used above the fold on first render.
• Removing from from highly-visible areas (e.g. above the fold icons on every page) would cause a regression both in perceived performance and actual NavTiming metrics. Instead, we should keep @embed in those cases for the time being and consider using HTTP/2 push for those in the future (T120984).

Change 230286 abandoned by Krinkle:
Do not embed images in file modules as data URIs

Reason:
Moving conversation back to T118514 on Phabricator.

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

@Krinkle I'm wondering if your test cases for WebPageTest were first load results? When encoding in base64, the issue stated in this heatedly discussed article from mid 2013:

Regardless of whether the data URI content exists in a cached CSS or HTML file, the browser must decode the image each time a page renders: the decoding cost is paid repeatedly every time a page is viewed.

First off, it's not clear how appropriate the data from the article is nowadays, mid 2013 is a quite a while back. Also, for SVG icons we don't use base64. Only URL encoding is used due to performance reasons. SVG rendering (URL decoding?) speed might have increased significantly in recent mobile browsers.