地道にJSファイルのサイズを減らす #SPACEMARKET

※この記事はスペースマーケットプロダクトチーム Advent Calendar 2019 が終わって1日目の記事です。
面白い記事がいっぱいあるので良かったら見てください。

スペースマーケットのフロントエンドエンジニアの小牧です。
業務ではフロントエンドの機能開発やパフォーマンス改善などを行っています。
パフォーマンス改善は施策の合間で取り組んだり、一定の期間を設けて取り組んだりしています。
パフォーマンスは SEO にも UX にも大きく影響するので、優先的な課題として捉えています。
不要な CSS を削除、JS のバンドルファイルのサイズを小さくする、キャッシュ戦略、画像の遅延ロードなどの他にも様々なアプローチがありますが、本記事では JS のバンドルファイルのダイエットについて書いていきます。

まずは現状を知る

まず改善していくためには現状を知ることが何よりも大事です。
弊社では webpack を使っているので webpack でバンドルファイルの stats ファイルを出力し、可視化プラグインの webpack-bundle-analyzer で確認しています。
使ったことない人はプラグインのリンクにアクセスして確認していただくとわかると思いますが、バンドルファイルの内訳がとても見やすくなっています。
サイズが大きいファイルが大きく表示されていて、ひと目で大きなファイルがわかるようになっています。

ボトルネックを探す

webpack-bundle-analyzer のおかげでわかりやすくなったバンドルファイルの内訳を元に、自分が行ったことを挙げると

・サイズが大きすぎるライブラリ、リファクタリングで不要になったライブラリを探す
→ ライブラリを削除、同ライブラリの Tree Shaking される ES Modules 版、同機能の代替ライブラリを検討する

・その次に初回ロードされるバンドルファイルに不要なライブラリがないか
→ code splitting できるか検討

特別なことはしていませんが、こんな感じで地道にファイルサイズを小さくしていきます。

サイズが大きすぎるライブラリ、リファクタリングで不要になったライブラリを探して対処

サイズが大きすぎるライブラリは webpack-bundle-analyzer でひと目でわるので調査はそんなに難しくないですね。
見つけたライブラリは削除できれば削除します。
削除できなければ ES Modules バージョンや同機能の代替ライブラリを検討します。
ES Modules で Tree Shaking されるだけでライブラリによってはそれなりにサイズを縮小できます。

次に不要になったファイルはプロジェクトが大きくなればなるほど、探すのが大変です。これについては、それでも根気よく探すしかないですね…
不要なファイルは残さずにすぐ消すのが大事ですね。
とりあえず残しておくのは危険！

あと弊社では社内ライブラリを運用していて、バンドルしたときに同じライブラリの違うバージョンが混在していたことがありました。そのライブラリは別々のバージョンである必要がなかったので、アップデートして package.json に peerDependencies も追記しておきました。

初回ロードされるバンドルファイルに不要なライブラリがないか

初回ロードのタイミングによって不要なファイルは積極的に分割を検討します。
弊社は React を使っているのでコンポーネントは loadable-component で dynamic import をしています。
ボタンクリックしたあとに表示されるコンポーネントなどは初回に読み込む必要がないので dynamic import でも良いかもしれないですね。
onClick で呼び出すメソッド内のみで使うモジュールも同様に検討しても良いですね。

まとめ

今回はバンドルサイズへのアプローチだけですが Lighthouse や Google Search Console や Google Analytics などを使って他の改善へのアプローチも行っています。
やることは少なくなかったり、パフォーマンスへの影響が思ってたより少なかったりすることもありますが、前向きに頑張っていきたいですね！