Some first part of patch work: https://chromium-review.googlesource.com/c/v8/v8/+/821071

Second patch work: https://chromium-review.googlesource.com/c/chromium/src/+/853500

Have you considered gzipping such resources instead of minifying them, to save space? Example CL at [1]

IMO using parking additional functionality within GRIT, such as JS minification is not a great approach to begin with, and I've tried to capture why our usage of GRIT is fairly problematic, at least for WebUI, see [2] 

[1] https://chromium-review.googlesource.com/c/chromium/src/+/770550 
[2] https://docs.google.com/document/d/1Z18WTNv28z5FW3smNEm_GtsfVD2IL-CmmAikwjw3ryo/edit#heading=h.pmqrv7fqbjg6

Some old bug about this: https://bugs.chromium.org/p/chromium/issues/detail?id=619091

And some discussion about gziping things: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/fgc2dfRvjsQ/discussion

+dbeam, aberent (although I think they are already aware?)

The more people the better, some discussion is also in the https://chromium-review.googlesource.com/c/chromium/src/+/853500, generally it looks, that we need one generic approach for handling HTML, JS, CSS, SVG...

*** Bulk edit ***

Setting Feature Requests as: Untriaged 

Is there a reason we can't just zip-compress everything?

I don't think this is related to WebUI or android frontend.

In answer to #11; yes, there are reasons for not zip-compressing everything. This has been discussed a number of times before, but I will summarize.

There are three possible reasons for making the APK smaller:

1 - To reduce it's size in storage on the device. Zip compression of the PAK files and resources will work here.
2 - To reduce the network usage when downloading the APK. Play store downloads are compressed in transit, double compression rarely works, and sometimes actually makes things larger.
3 - To reduce the size of Chrome in memory. At the moment the PAK files and resources are memory mapped directly from the APK. If they were compressed then they would have to be inflated in memory before being used. This would both slow down Chrome startup, and require Chrome to allocate memory, or a memory mapped file, to store the inflated PAK files and resources. In addition Chrome would require some working memory for inflation.

In other words, compressing everything would reduce the size on disk but would add significantly to memory usage, and could affect performance. It would make no difference to download cost.

See https://sites.google.com/corp/google.com/clank-fundamentals/binary-size