Status update: I have managed to create a proof of concept for integrating vulcanize into the GN/Ninja build, such that we don't need to check-in vulcanize's output into the repository. It works (see https://codereview.chromium.org/2535113003).
Remaining tasks:
1) Modify vulcanize to provide a list of input files (necessary to know when to re-trigger vulcanization).
2) Add all dependencies to the toolchain.
3) Migrate MD Downloads and MD History first, to use the new vulcanize.gni rule (and delete checked-in copies of generated code.
4) Vulcanize settings!
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src.git/+/b64500afce5b9342dba43f53f445c12a0ffc57e2
commit b64500afce5b9342dba43f53f445c12a0ffc57e2
Author: dbeam <dbeam@chromium.org>
Date: Tue Feb 28 18:52:46 2017
Polymer: use polymer-css-build --no-inline-includes
Chromium updated polymer-css-build to 1.0.9 to use this feature:
https://codereview.chromium.org/2714833003
This also required rolling to Polymer 1.8.1 which happened here:
https://codereview.chromium.org/2717403003
And finally requires a change to Polymer's internal config via:
Polymer.preserveStyleIncludes = true;
Given the example DOM:
<dom-module id="css-module">
<template>
<style>
/* module styles */
</style>
</template>
</dom-module>
<dom-module id="my-element">
<template>
<style include="css-module">
/* template styles */
</style>
</template>
</dom-module>
before this patch is combined both at compile time and at runtime into:
<my-element>
#shadow
<style>
/* module styles */
/* template styles */
</style>
</my-element>
This defeats blink's CSS SheetContents caching and inlines many
duplicate styles into the output (settings ends up at like 1MB of
HTML/CSS combined before gzip).
With --no-inline-includes, the generated output is significantly smaller
(65% before compression, ~15% after compression) and include="" modules
are cloned dynamically at runtime via Node#cloneNode().
The end results (in the DOM) are basically:
<my-element>
#shadow
<style>
/* module styles */
</style>
<style>
/* template style */
</style>
</my-element>
I also verified locally that many more <style> tags are bypassing
parsing and being used from the cache.
R=dpapad@chromium.org
BUG= 597347
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
Review-Url: https://codereview.chromium.org/2718243005
Cr-Commit-Position: refs/heads/master@{#453652}
[modify] https://crrev.com/b64500afce5b9342dba43f53f445c12a0ffc57e2/chrome/browser/resources/polymer_css_build_gn.py
[modify] https://crrev.com/b64500afce5b9342dba43f53f445c12a0ffc57e2/ui/webui/resources/js/polymer_config.js
Status update regarding splitting MD Settings to a main module and a lazy loaded module:
I was able to build the two modules correctly (I think), which involves
1) https://codereview.chromium.org/2726403003: Split unpack_pak functionality to its own GN rule
2) https://github.com/Polymer/polymer-bundler/pull/442: Fix vulcanize, to not attempt to load excluded JS scripts.
3) https://codereview.chromium.org/2714613002: Split MD settings to two modules.
The JS/HTML bundles looks as follows:
Before splitting
391K crisper.js
368K vulcanized.html
After splitting
262K app.crisper.js
246K app.vulcanized.html
129K lazy_load.crisper.js
123K lazy_load.vulcanized.html
This means that the code we initially load (unzipped) is reduced by
JS: -32%, HTML: -33%
I'll dig in to some more metrics (first meaningful paint shortly).
Having said all that, there is still work needed to make the "ensure lazy loaded module exists" work. Which I'll evaluate after I get some initial perf gain measurements.
The CL that splits MD Settings to a basic and a lazy module has landed (and hopefully will stick). FYI, the remaining potential performance enhancements I have in mind:
1) Strip non-Chrome CSS prefixed rules from our copy of Polymer. https://codereview.chromium.org/1633603004. Saves about 6% size the vulcanized bundle.
2) Improve scrolling performance, issue 699302 .
3) Replace usage of obsolete iron-flex-layout with iron-flex-layout-classes, issue 635633 . A bit unclear whether it is related to performance, see @michaelpg's comment at https://bugs.chromium.org/p/chromium/issues/detail?id=635633#c2.
Comment 1 by michae...@chromium.org
, Mar 23 2016