All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=731243

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDglsaMnQkM


Bot(s) for this bug's original alert(s):

Android Builder

Size graph:
https://chromeperf.appspot.com/report?sid=a097e74b1aa288511afb4cb616efe0f95ba4d347ad61d5e835072f23450938ba&rev=477707

Looks like growth is entirely from the new .js file being added. Since this looks to be a refactoring, I'd recommend reverting unless you've already got a plan for addressing the size increase.

=== BISECT JOB RESULTS ===
NO Perf regression found, tests failed to produce values

Bisect Details
  Configuration: android_nexus7_perf_bisect
  Benchmark    : resource_sizes
  Metric       : MonochromePublic.apk_Specifics/normalized apk size


To Run This Test
  src/build/android/resource_sizes.py --chromium-output-directory {CHROMIUM_OUTPUT_DIR} --chartjson {CHROMIUM_OUTPUT_DIR}/apks/MonochromePublic.apk

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8977325488501630544

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=6127630157348864


| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Speed>Bisection.  Thank you!

It's not just a refactoring, we're transitioning from one set of JS bindings to another. There will be brief window where the support JS library code for both sets is packaged in browser resources.

I don't think reverting is the correct thing to do here. Why don't we make this a stable RB and we can ensure the old bindings are removed (and thus the regression is resolved) before anything ships.

I tried to apply gzip / zip with mojo_bindings.js, the size reduced from 157.9kb to 23kb.

And I noticed that we have compress="gzip" for some other js resources, such as:
https://cs.chromium.org/chromium/src/content/content_resources.grd?rcl=b4d77cd58c7d5089e708e2965aaec294db76d0f0&l=17

It may help in this case. I could give it a try.

At the same time we will try to remove the old bindings ASAP.

Sounds like "already got a plan for addressing the size increase." is the case :)

compress=gzip would fit well here I think.

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8977321432927205040

=== BISECT JOB RESULTS ===
NO Perf regression found, tests failed to produce values

Bisect Details
  Configuration: android_nexus7_perf_bisect
  Benchmark    : resource_sizes
  Metric       : MonochromePublic.apk_Specifics/normalized apk size


To Run This Test
  src/build/android/resource_sizes.py --chromium-output-directory {CHROMIUM_OUTPUT_DIR} --chartjson {CHROMIUM_OUTPUT_DIR}/apks/MonochromePublic.apk

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8977321432927205040

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=6127630157348864


| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Speed>Bisection.  Thank you!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1a4797788c3fd17e40f37aa0379b148c38461bba

commit 1a4797788c3fd17e40f37aa0379b148c38461bba
Author: yzshen <yzshen@chromium.org>
Date: Fri Jun 09 08:11:33 2017

Mojo JS bindings: specify compress="gzip" for bindings JS files in .grd.

Numbers measured using a Release Android build:
=====================================
Before:
Analyzing pak files in out/ARelease/apks/MonochromePublic.apk...
Total pak files: 99
Total compressed size: 5.10m
Total uncompressed size: 9.93m
...
====================================
After:
Analyzing pak files in out/ARelease/apks/MonochromePublic.apk...
Total pak files: 99
Total compressed size: 5.01m
Total uncompressed size: 9.84m
...
===================================

BUG= 731243 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2931983002
Cr-Commit-Position: refs/heads/master@{#478233}

[modify] https://crrev.com/1a4797788c3fd17e40f37aa0379b148c38461bba/content/browser/webui/shared_resources_data_source.cc
[modify] https://crrev.com/1a4797788c3fd17e40f37aa0379b148c38461bba/content/browser/webui/shared_resources_data_source.h
[modify] https://crrev.com/1a4797788c3fd17e40f37aa0379b148c38461bba/ui/webui/resources/webui_resources.grd

Pls apply appropriate OSs label. Thank you.

This issue is marked as a release blocker with no OS labels associated. Please add an appropriate OS label.

All release blocking issues should have OS labels associated to it, so that the issue can tracked and promptly verified, once it gets fixed.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The Cl of #10 reduced the size by 90K. I think it should be okay to close this bug. We are tracking removal of the old bindings in a different bug:  crbug.com/699569 , which should further reduce the size.

WDYT?

compress=gzip reduced by 98262 bytes:
https://chromeperf.appspot.com/report?sid=a097e74b1aa288511afb4cb616efe0f95ba4d347ad61d5e835072f23450938ba&rev=478233

Closing.