きっかけはこちらの発表を見て、レガシーなJavaScript(jQuery)のフロントエンド開発でも結構できることはあるなぁと触発されたので。
ちょうど実務で無駄なjQueryの処理を削減したことで、表示速度が画面の内容量にもよりますが、2秒近く早くなりメモリ使用を抑え込めたことがありました。適切なJavaScriptの読み込みを工夫するだけでも、表示の高速化や安定化はできるなと思えたので、上記リンクほど深い話はできませんが、割と簡単に取り組めることをピックアップして紹介したいと思います。
簡単なチューニングのポイント４選
HTML/CSSで同様のことができないか検討してみませんか？
最近のHTMLの標準のタグやCSSで実装できる範囲って、普段バックエンドよりな人からすると見落としがちなところかと思います。
例えば、トグルメニューはdetailタグ + summaryタグでも実装できます。トグル系のJSライブラリの導入を検討しなくても、用途によっては十分なトグルの実装がJavaScriptなしでも実現できます。datalistタグでは絞り込み検索のできるプルダウンの実装ができます。
CSSで言えば最近はアニメーションでできることも増えている印象があり、わざわざJavaScriptでアニメーションを実装しなくても良い場面もありそうです。
ライブラリの検討やJavaScriptを書く前に求められている実装要件のレベルで実現できるHTMLやCSSの選択肢を探すこと、たまに追加されるHTML/CSSの新機能をキャッチアップしておくことで、無駄な作り込みや読み込みを減らすことができます。
そのJavaScriptが必要なタイミングって合っていますか？
呼ぶ必要がないJavaScriptをとりあえずscriptの読み込み時に読んでいるケースはないでしょうか？
冒頭の自分の経験ではクリックされる前には不要なJavaScriptのイベントをロード時に紐づけていることがありました。これをクリック時に限定することでHTMLとして生成しなければならなり要素自体の削減ができました。
多機能になるにつれ表示要素が多くなることで、それだけ単純にレンダリングのコストも意識しなければならないかと思います。これはYAGNI原則にもあてはまる例かと思います。とりあえず機能として利用できれば～でなく、タイミング(時間軸)も意識しないとアプリケーションが大きくなるにつれパフォーマンスに影響が出てきます。
イベントレベルで切り離す、必要なときだけつけたり外したりする、というのは技術のハードなスキル・知識がなくても実践できるところではあるので、日頃から無駄がないか、許容できる範囲の無駄かを意識しておくことは大事ではないでしょうか。
標準のAPIでなんとかできませんか？
これも知っているか知らないかで差になってくる部分かと思います。すごく簡単な例だとAjax処理を実現するのにaxiosなどのライブラリでなくfetch APIを使う、などです。
ライブラリによる記述の容易性や利便性とのトレードオフの部分も多いにあるので、全てで標準APIを使用していきましょうということはないですが、作成するものに応じて使い分けることで無駄なライブラリやモジュールの読み込みも減らせるのではないでしょうか。
単純にその画面で不要なJavaScriptを読み込んでいませんか？
最後はとても当たり前の話なのですが、その画面で不要なJavaScriptを読み込めばその分だけ無駄なリソースを食うことになります。開発初期には必要だったけど別のライブラリに置き換えて使わなくなったとか、別バージョンで入れたけど古いバージョンの方もなんとなく残っているとか。
以下のサイト調べでは3割～4割程度の利用されていないJavaScriptが読み込まれているそう。
JavaScript | 2022 | The Web Almanac by HTTP Archive
SPAでバンドルする場合にせよ、script読み込みにせよ不要なものが混ざっていることで無駄が出ます。年数が経過するサイトやアプリケーションほど起きやすいのかなとい気もするので、長く運用していくほど定期的な見直しが必要そうだなと思います。
まとめ
トリッキーなことをしなくても割と見落としがちなことを拾っていくことで改善になるケースは、規模感や年数が増すにつれ出てくるのかなと思います。シニアな技術者でなくても取り組める範囲のことだと思うので、たまにDevtools開いてどんなJavaScriptが落ちてきているか見てみると思った以上のUX改善につながることもあるかと思います。