Minify Files app and its companion apps for faster load time |
|||||||||
Issue descriptionCreated a document comparing Vulcanize, Uglify-es and closure compiler on nodejs. https://docs.google.com/document/d/1tdJRrxrvgGwseiWHAwGlysPxFKhXK29ZKefYDebtyT8/edit?hl=en# I guess Vulcanize is what we should try first given Files app (and its companion apps) use Polymer.
,
Jun 20 2017
,
Jun 20 2017
OK, I'll take a look. Thanks!
,
Jun 20 2017
Vulcanize & crisper processed files are also minified using uglify by default. https://cs.chromium.org/chromium/src/chrome/browser/resources/vulcanize_gn.py?l=191&rcl=147c403c07d51867150336afc0fd9c00e62e0ebf I couldn't find the way to enable SourceMap with Vulcanize. One example md_downloads does not seem to have SourceMap for crisper.js, which may be OK because it's small, but I think we need one for FilesApp.
,
Jun 20 2017
According to the docs at https://github.com/Polymer/polymer-bundler, there is a --sourcemaps option. Note that the migration from Vulcanize to polymer-bundler has not happened yet, because there are still blocking issues (https://bugs.chromium.org/p/chromium/issues/detail?id=731881). Having said that, why do you need source maps? In WebUI, we have survived without them, my using the use_vulcanize GN flag. When you turn that to false, nothing is minified/bundled (ideal for debugging). When you turn it on, the code is minified and bundled (ideal for performance, but not for debugging).
,
Jun 21 2017
Thank you for your information. Given the fact that WebUI does not use source maps, use_vulcanize=false seems sufficient.
,
Dec 19 2017
,
Feb 23 2018
What are the advantages of doing this? Would minifying it make the app load and run slightly faster? This would make the app much harder to debug, almost impossible in production.
,
Feb 23 2018
HTML imports are slow (and deprecated). Minifying a Polymer-based app with polymer-bundler, makes it such that there are no HTML imports used in production, which makes initial load time much faster (along with polymer-css-build which eliminates some runtime parsing). For MD Settings just eliminating HTML imports, cut initial load time in half. > This would make the app much harder to debug, almost impossible in production. You can open DevTools for of chrome://settings, chrome://history, chrome://downloads in production and determine how debuggable these pages are. IMO, they are very debuggable, since JS code is not affected (there is no JS-Compiler style obfuscation/re-naming), JS code is simply concatenated, comments are removed, and blank space (and can be re-formatted via DevTools "Pretty print" feature).
,
Feb 24 2018
,
Feb 28 2018
,
Sep 24
,
Nov 9
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by oka@chromium.org
, Jun 20 2017