こんにちは、ナカムラです。
フロントエンドの仕事の中でパフォーマンスの改善というのは常に求められるものになります。
（PageSpeed Insightsによる計測を中心に確認しています）
読み込むファイルの容量を小さくする、というのも大切なことですが、コーディングの書き方にも気をつけていきたいです。
これまでの整理を兼ねて記事にしていきたいと思います。
画像の軽量化
webpの使用や、圧縮率の変更などでより軽くすることができます。
パフォーマンススコアにはそれほど大きな影響はありませんでしたが、必要以上に大きなファイルを読み込ませるのは良くないので、常に気をつけたいと思います。
javaScriptの読み込み
</body>の直前に読み込んでいたものを<head>内に移動し、defer属性をつけました。
これにより、DOMの解析を進めながら、同時進行でjavaScriptのファイルを読み込むことができます。
ただし、deferの場合はDOMの解析が終わった後に実行されるため、ページ内の要素数によっては効果を実感できないこともあります。
要素の少ないページでは45程度だったものが60前後に上がったところもあります。
※同じような役割としてasyncがありますが、読み込みが完了したら実行されるため、ロード後に実行したい処理などには使えません。
javaScriptの見直し
ある程度共通の処理は1ファイルにまとめていたのですが、ページに必要な分だけを読み込むことにしました。
「使用していないjavaScript の削減」の項目は減らすことができます。
これについてはCSSも同様です。
webフォントの読み込み
Googleフォントの読み込み方法はGoogleフォントのサイトに掲載されているCSSの読み込みで実装することができます。
このままでは時間がかかってしまうため、WEBフォントの読み込みをAjaxにするプラグイン「webfontloader」を使用するようにしました。
First Contentful Paintが2秒以内になったのでやってよかったと思います。
ただ、改善したいページではパフォーマンスの数値としてはあまり変わりませんでした。
Total Blocking Timeが高いのが原因のようですが、体感として表示のもたつきは解消されたように思います。（改善するページにより原因は様々です）
これから改善したいこと
上記の施策は細々とした改善になり、劇的な変化とまでにはなりませんでした。
今後フロントエンドとしてできそうな施策は要素のノード数を減らすこと、CSSセレクタの改善になると思います。
ノード数の改善
ノード数（要素タグの数）の基準は下記の通りです。
- body 要素のノードの数が 800 を超えると警告します。
- body 要素のノードの数が 1,400 を超えている場合に発生するエラーです。
レイアウトを組むためのdivなどのグルーピングを減らせないかなど、マークアップに必要な最低限の組み方ができるように見直す必要があります。
改善できるところは改善していきます。
子要素の上限数は60のようです。
一覧の表示件数などに気をつけたいところです。
（Googleの記事は見つけられていなかったので過去の色々な記事を参考にしています）
DOMの深さについては32を超えるとエラーになるようですが、今のところそこまでのものはありませんでした。
特殊なコンテンツでもなければ、なかなか32まではいかないと思いますが、過剰な入れ子はCSSのセレクタも複雑になりますので、やらない方が良いですね。
CSSセレクタ
スタイル計算速度に影響します。
Chromeの開発者ツールで検証することができます。
スタイル再計算イベント中の CSS セレクタのパフォーマンスを分析する | Chrome DevTools | Chrome for Developers
パフォーマンスの設定で「CSS セレクタの統計データを有効にする」にチェックを入れて「記録」します。
- 経過時間（ミリ秒）
- マッチング試行回数
- 一致数 などから、改善したいセレクタを特定していきます。
::beforeや::afterなどの擬似要素や、liなどの要素タグのセレクタなどが上位に上がってきます。
ベースやリセットとして記述している記述も見直した方が良さそうです。
nth-childなどの擬似クラスも多用しすぎると負荷につながりますので、シンプルなセレクタを心がけたいと思います。
まとめ
上記で書いた以外にも、細かなパフォーマンス改善は色々と行っています。
小さな積み重ねになりますが、無駄ではないと信じて改善していきたいです。
適切なマークアップと、シンプルな設計を目指していきます。
