河村です。
前回のhtml5 videoのシメに、「次回はAndroidの検証結果かcss3…」と言っていたにも関わらず、今回はgoogle closure compilerです。code compress and optimization、code inspector、体系化されたAPI、豊富なUIコンポーネントなどなど（参考：Closure Libraryを使うべき10の理由）非常に有用な機能が多いです。今回はこれのcode compress and optimizationを実際に使った結果を検証します。実際に使うデータと前提条件について以下に示します（ソースコードの内容は出せません）。
- APIローダ+API-IFとAPI本体の2段構成
- APIローダ+API-IFサイズ：9,512 バイト、API本体サイズ：237,187 バイト
- 開発中はSIMPLE_OPTIMIZATIONSでやっていて、後からADVANCED_OPTIMIZATIONSに対応させるためのコード整形を行った（つもり）
コンパイルレベルにはWHITESPACE_ONLY、SIMPLE_OPTIMIZATIONS、ADVANCED_OPTIMIZATIONSという3種類があります。それぞれの説明についてはこちら。以下はコンパイルレベル毎の結果です。
WHITESPACE_ONLY
APIローダ+API-IF：3,492 バイト、API本体：120,037 バイト（動作確認済）
どれだけホワイトスペース使ってんだ、という結果になりました。
SIMPLE_OPTIMIZATIONS
APIローダ+API-IF：2,896 バイト、API本体：85,830 バイト（動作確認済）
ADVANCED_OPTIMIZATIONS
コンパイルはなんとなく通ったものの、動作確認に失敗しましたww 以下の数値はコンパイルのみ行ったものです。
APIローダ+API-IF：893 バイト、API本体：54,934 バイト（動作未確認）
動作しなかった原因は
- [APIローダ＋API-IF] IFが利用するAPI本体の関数やオブジェクトまで圧縮されてしまった
- [APIローダ＋API-IF] API-IFのpublic関数、オブジェクトまで圧縮されてしまった
- [API本体] 利用するAPI-IFの関数やオブジェクトまで圧縮されてしまった
- [API本体] public関数、オブジェクトまで圧縮されてしまった
つまり、exportsとexterns関連がうまくできてなかったことになります。なので、ここらへんを参考に修正しようと思いましたが、今までのコードに色々な修正を行いたくない、という思いが強かったので、別の方法を考えました。
[ externs ]
これは外部で定義された関数、オブジェクトを参照する箇所で、そのシンボルを圧縮させないためのものです。これをソースファイルとは別のjavascriptファイルで定義し、コマンドラインオプションで指定します。これにより上記の1と3を解決することができます。コマンドラインオプションはこんな感じです。
–externs externs1.js
[ exports ]
これは外部に公開する関数やオブジェクトを圧縮させないためのものです。これは通常ソースコードに記述するようですが（色々見て回ったところ、対象となるファイル内で記述するようなモノしか見つけられなかった）、上で述べたように、もはやそんなことはしたくありません。なのでこれも別のjavascriptファイルとして定義したい。しかしこれを取り込むコマンドラインオプションは存在しません。どうしようかと迷った挙句「普通にソースコードとして取り込めばいいんじゃね？」と考えました。
結局同じファイルに書こうが違うファイルに書こうが、コンパイラに解釈させるんだったらソースコードに含まれていればよいはず。更にうまくいっているSIMPLE_OPTIMIZATIONSに変な影響を与えずに成功できるかもしれない。
という結論に至ったので、コマンドラインに以下を追加して実行してみます。
–js export.js
エラーなしでうまくいきました。動作確認もカンペキです。
APIローダ+API-IF：2,521 バイト、API本体：56,876 バイト（動作確認済）
まとめ
今回の検証結果をまとめます。一番下にYUI Compressor 2.4.6で同じファイルを処理したときの結果をまとめました。しかし、google closure compiler向けに作成したファイルたちなので、goog.provideとかgoog.requireは処理されていません。あしからず。また、それらが含まれている、closure libraryのbase.jsも処理対象から外しています。
| level | APIローダ+API-IF | API本体 |
|---|---|---|
| 非圧縮 | 9,512 バイト | 237,187 バイト |
| WHITESPACE_ONLY | 3,492 バイト | 120,037 バイト |
| SIMPLE_OPTIMIZATIONS | 2,896 バイト | 85,830 バイト |
| ADVANCED_OPTIMIZATIONS | 2,521 バイト | 56,876 バイト |
| （参考）YUI Compressor 2.4.6 | 3,135 バイト | 99,174 バイト |
これを見る限り、ADVANCED_OPTIMIZATIONSがずば抜けてます。ファイルサイズが小さくなれば、当然ローディング時間の短縮にも繋がります。3G回線でスマートフォンを使っている場合は、結構体感速度が変わりました。また今回は検証しませんでしたが、javascriptの解釈・実行速度の時間にも改善が見られる、とありました。（参考：Closure Libraryを使うべき10の理由）
ADVANCED_OPTIMIZATIONSのコーディングルールは非常に厳密であり、作るメンバーの力量に差がある場合は用いない方がいいかもしれません。しかし、今後webアプリを作る上では極めておきたい技術ではあります。
