肥大化したコードサイズを約1/10に軽量化
「サードパーティスクリプトの軽量化では約1/10に軽量化できました。従来はgzip圧縮前で307キロバイトあったのスクリプトが、新しいサードパーティスクリプトでは、最小設定ではありますがgzip圧縮前で25キロバイトという計量化に成功しました。」
西村氏は、軽量化のために実施したいくつかの改善策を説明した。まずはプロジェクトごとにJavaScriptを作成することで、お客さまごとに必要な機能を取捨選択できるようにした。
プロジェクトごとのJavaScriptは、全プロジェクト共通のコードとプロジェクトごとのJSON Configをbundleして生成している。このとき、機能の取捨選択を2つのステップで実現している。
図のようにentry.jsとfeature.jsのような2つのコードがあり、rollupなどでentry.jsのコードをbundleする場合を想定する。entry.js内のUSE_A、USE_Bはプロジェクト別の設定ファイルで定義されており、USE_Aがtrue、USE_Bがfalseのようにbundle時に定数置換することができる。これをterserで最適化すると、featAだけが有効になり、featBのコードを消すことができる。
このほかにも、Treeshakingや Dead Code Eliminationを意識した開発をおこない、公式にサポートが終了したInternet Explorerの対応をしないといった改善策により、コードサイズの軽量化を実現した。
「ただ、こういう手法にもデメリットがあります。1番大きなデメリットとして感じていることは、全プロジェクト共通のJavaScriptの更新時に、プロジェクトの数だけJavaScriptを生成し直す必要があることです。これには、2つの課題がありました。」
1つ目の課題は、デプロイ時間が長くなることだ。サービスが成長していきプロジェクト数が膨大になると、全体のデプロイ時間も長くなる。たとえば、リリース直後にバグが発見されたときに、巻き戻しにも時間がかかってしまい、お客さまにも迷惑をかけてしまう可能性があるのだ。
「この課題の解決のために、bundleの最適化を実施しています。たとえば、bundleの方法をrollupからesbuildにして試験しているところです。また、プロジェクトごとの最適化はできませんが、bundleしないでプロジェクトごとの設定をそのまま文字列置換する方法も行っています」
2つ目の課題は、CDNのInvalidationに制限があることだ。JavaScriptを更新した際にはキャッシュ削除をおこなうInvalidationをかけるのが一般的だが、同時にInvalidationできるファイル数に制限があるのだ。
「サービスの成長に連れてプロジェクト数がすごく多くなった場合、Invalidationの制限に引っ張られてInvalidationできないプロジェクトが出てくるなどスケール面で問題が出てきます。」
そこで、CDNのInvalidationをかけずに、CDNのキャッシュ時間を短めに設定して、キャッシュ時間が切れることで、エッジのJavaScriptが更新される仕組みにした。
複数プロダクトや機能の追加に対応できるようプラグイン化
「会社のフェーズの変化もあり、サードパーティスクリプト上で動かすプロダクトも増えてきました。プロダクトというのは、ポップアップ表示とかチャット機能とか、エンドユーザーの困り事に合わせたFAQの表示などを表しています。こういったさまざまなプロダクトをサードパーティースクリプト上で動かす統一的な仕組みがなく、プロダクトごとに自由に開発している状態でした。」
こうした課題を解決するためプラグイン化を進めたが、次図のような要件があった。
こうした要件への対応のうち、プロジェクトごとに必要な機能が異なるという点は、先ほど紹介したようにプロジェクトごとにJavaScriptを生成する方法で実現した。
「さらにサートパーティスクリプト本体から切り離されて開発される点、サードパーティスクリプト本体から情報を渡す必要がある点については、dynamic importとシンプルなinterface規約を設けるという単純な方法で解決しました。」
プラグイン開発時には、図の左側にある疑似コードのようなインターフェースを満たしたプラグインを実装してもらい、管理画面での変更登録に応じて本体からプラグインをロードするようにした。本体部分に絡む引数をargsで渡すようにしてあり、共有ライブラリという概念を持たない。また、プラグイン開発用にargsのモックを介するユーティリティを社内パッケージへ提供している。
「社内のエコシステムでもう少しもんでから、このプラグインシステムを社外にも公開したいと考えています」
プラグイン間のデータのやり取りに関しては、Pub/Subの仕組みを採用した。Pub/Subでは、さまざまなトピックを定義して、各トピックに対して色々なプラグインからメッセージをパブリッシュする。トピックをサブスクライブすると、保持しているメッセージを含めてメッセージを受け取りできるようになる。
この仕組みを利用することで、プラグイン間のデータのやり取りを実現したのだ。
