サイトパフォーマンス改善でよく見るボトルネックになる要因

こんにちは森田です。
最近サイトパフォーマンス改善に取り組む機会が多いのですが。ページスピードや Core Web Vitals などやる事が多くて大変ですがやり甲斐を感じてます。

その際によく目にするボトルネックになる要因をピックアップして紹介いたします。

※今回はわかりやすい基準として、PageSpeed Insights や Core Web Vitals のスコアを挙げていますが、そのスコアがサイトパフォーマンスの全てではないことを理解ください。

日本語 Web フォント

日本語Webフォントで代表するフォントと言えば Noto Sans が挙げられます。
デバイスやOSを同じフォントに出来るということで、「とりあえず Noto Sans」という形で選ばれていることも多いと思います。

例えば、Google Fonts で Noto Sans JP を3ウェイト選択 すると以下のようなコードを head 要素や CSS に記述するコードが出力されます。

<link href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP:wght@300;400;700&display=swap" rel="stylesheet">

@import url('https://fonts.googleapis.com/css2?family=Noto+Sans+JP:wght@300;400;700&display=swap');

このコードをそのまま使うとサブセットされているとはいえ、サイズが重い日本語フォントのダウンロードが発生します。
また、 font-display: swap の指定でフォントが読み込まれてからフォントが変わるので Core Web Vitals の CLS も低下することがありました。

日本語 Web フォントを使うと使用することによりサイトパフォーマンスは確実に落ちます。フォント軽量化やローカルフォントのみの指定なども検討してもいいかもしれません。

デザインとの兼ね合いはあると思いますが、日本語 Web フォントの使用をやめて PageSpeed Insights スコアが20〜30点増加した例もあります。

Noto Sans は最近バリアブルフォントに対応したとのことで、ウェイトを増やすことでサイズが増える事は無くなるかもしれません。

参考：アドビの「源ノ角ゴシック」がバリアブルフォントに対応–ウェイトを自由に調整可能

画像

画像によるサイトパフォーマンスの低下も起こりやすい要因の1つです。
画像1枚でパフォーマンスを大きく下げてしまう事もあります。

サイズ属性がない

これまでレスポンシブサイトでは書かないことも多かったサイズ属性ですがこれからは必ず書いた方がいいでしょう。

<img>要素に width 属性や height 属性がないとブラウザが読み込み時にサイズを理解できないのでレイアウトシフトが発生してしまいます。

CLS やレイアウトシフトについては以下の記事をご参考ください。

サイズが適切でない

これはレスポンシブサイトなどで良く見受けれらますが、PC の画像をそのままSP でも使っており、画面サイズよりも大きい画像を読み込んでしまいパフォーマンスを低下させるいうものです。

scrset属性 や <picture>要素などで画面サイズごとに適切な画像サイズで切り替えることが望まれます。

最適化（軽量化）されていない

Photoshop や XD で書き出された最適化されていない重い画像をそのまま使っているというパターンです。
画像最適化を行いメタデータ削除や圧縮をして軽量化しましょう。

ターゲットブラウザによっては WebP を導入してもいいかもしれません。
WebP image format – Can I use… Support tables for HTML5, CSS3, etc

LazyLoad していない

画像の遅延読み込みをする Lazy Load。
Lazy Loadしていないと見えていないページ下部の画像も読み込んでしまいパフォーマンスが低下します。

Chromeなどはネイティブの LazyLoad をサポートしているので loading属性を指定するだけで簡単に実装することができます。

<img src="gaji-labo.png" alt="Gaji-Laboロゴ" loading="lazy" />

LazyLoadを導入したことで LCP のスコアが改善、結果 PageSpeed Insights スコアが改善したケースもあります。

計測・分析ツール

Google Analytics や Facebook Connect など、アクセス解析やコンバージョン、マーケティングなどの計測ツールはサイトパフォーマンスを大きく下げる要因となることがあります。

これは分析やマーケティングで必要なものなので仕方がないですが、不要なものは削除したり、読み込み順序や非同期などで対応できるものはした方がいいでしょう。

スクロールイベント

window.addEventListener('scroll', function(){
  # スクロールした時に何かする
});

固定ヘッダーや追従バナーなどスクロールによって動きを付けたい場合、スクロールイベントを使うと思いますが、上記のようなコードをそのまま使うとスクロールごとに大量のイベントが発生し、スクロールジャンクと呼ばれる画面がカクつく現象も発生しやすく、パフォーマンスの低下が体感で分かるほどに起こります。

スクロールジャンクを防ぐためにも第3引数に passive フラグを指定します。

window.addEventListener("scroll", func, { passive: true });

参考：Does not use passive listeners to improve scrolling performance

また、Lodash の throttle などでイベント自体を間引くのも有効です。

window.addEventListener('scroll', _.throttle(func, 100));

参考：Lodash Documentation

MPA（Multiple Page Application）

結局この話になってしまうのですが、 WordPress などの MPA サイトはアクセスがあってからサーバーが html を生成するので、どうしてもパフォーマンスは落ちます。

SPA や Jamstack構成のサイトの方がパフォーマンスが高いのは言うまでもありません。（サイトによる特性はあるので全てのサイトに SPA や Jamstack が向いているというわけではありません）

このあたり弊社原田の記事がわかりやすいのでお勧めいたします。

まとめ

サイトパフォーマンス低下の要因について幾つか挙げました。
サイト構築やコーディングの際にもここはパフォーマンスが低下しそうだなと予想が付きやすくなるかもしれません。

それ以外にもサーバーの設定など施策する事は他にも沢山あります。
全てを完璧に最適化する事は難しいですが、まずはできる範囲で改善をしていきましょう。