外部のパブリックCDNからjQueryを読み込むべきだという説を、かつてよく目にした。世界中にエッジサーバーを持つCDNなら自社サーバーより速いはずだ、という理屈だ。今もその前提でライブラリをパブリックCDNから読み込んでいるサイトは少なくないと思われる。
ネットワークの負荷分散という目的でパブリックCDNを使うサイトも珍しくない。狙い自体は理解できる。だが弊社の経験上、日本国内でパブリックCDNが体感できるほど速く働く場面はそう多くない。むしろ別ドメインへの接続にかかるDNS解決やTLSハンドシェイクが、最も急ぎたい初期表示のタイミングでオーバーヘッドとして上乗せされる。
しかし弊社の表示速度ボトルネック実例研究（vigilante）では、外部ドメインからのリソース配信がFCPやLCPを1秒以上押し上げているケースを繰り返し観測している。同一ドメインへのリクエストなら既存のHTTP接続を再利用できるが、別ドメインに初めて接続するときはDNS解決・TCP接続・TLSハンドシェイクをゼロから実施しなければならない。このオーバーヘッドが、状況によってはFCP・LCPに直結する遅延として表れる。
ただし影響の大きさはリソースによって大きく変わる。クリティカルパス上にあるCSSや同期的なJSライブラリでは接続コストがそのままFCP・LCPの遅延になりやすい。一方でクリティカルパスから外れたリソースでは、接続コストは存在しても指標への影響は小さい。この濃淡が実例の数値ではっきり見えてくる。
外部ドメインに接続するたびに発生するコスト
ブラウザが同一ドメインのリソースを取得するとき、HTMLの取得ですでに確立した接続をそのまま再利用できる。HTTP/2ではさらに多重化が効き、複数リソースを1本の接続で並列ダウンロードできる。
別ドメインに接続するときは話が違う。まずDNS解決でドメイン名をIPアドレスに変換し、次にTCP接続を確立し、さらにHTTPSならTLSハンドシェイクが必要だ。これらが積み重なり、初回接続だけで数百msのオーバーヘッドが生じる。実際にダイヤモンド・オンラインの例では、別ドメインへの初回接続TTFBが939msという値が観測された。
パブリックCDNのキャッシュ共有はもう効かない
かつて「人気のCDNのファイルは多くのユーザーのブラウザにキャッシュされているはずだ」という議論があった。しかし今この前提は崩れている。Chromeをはじめとするモダンブラウザはプライバシー保護のためにキャッシュパーティションを導入しており、サイトをまたいだキャッシュ共有は無効化されている。別サイトが取得してキャッシュしたパブリックCDNのファイルが自分のサイトで再利用されることはない。
結果として外部ドメインへの接続コストは避けられず、「キャッシュが効く」という利点は実質的に失われた。同じファイルを自ドメインに置いて配信すれば接続を再利用できる分だけ有利になることが多いと考えられる。
速い領域の0.1秒こそ効く
HTML・CSS・JavaScriptはできるだけ早く読み込みたい最優先のリソースだ。DNS解決のような処理は一瞬で終わる。だからパフォーマンスへの影響はないと感じるかもしれない。だがその数百msが初期表示のスタートダッシュに丸ごと乗ってくる。
ここで見落とされやすいのが、改善の価値は速い領域ほど大きいという点だ。弊社の観測では、LCPを5秒から3秒に縮めてもコンバージョンや収益への寄与はほとんどない。一方で1秒を0.9秒に縮めるほうが、収益へのインパクトははるかに大きい。だからこそ、すでに速いページでの0.1秒を甘く見ないことが大切だ。外部ドメインへの接続コストは、まさにこの0.1秒を削る余地として無視できない。
実例で確認する外部ドメイン配信の影響
弊社の表示速度ボトルネック実例研究（vigilante）では、まずサードパーティタグの影響を切り離した上で、サイト固有のボトルネックを一つずつシミュレーションして数値を記録している。以下の4例はいずれも、外部ドメインからのリソース配信を同一ドメインに変更した場合の結果だ。
ダイヤモンド・オンライン：CSSの別ドメイン配信でFCP・LCPが激変
ダイヤモンド・オンラインでは、トップページのレンダリングに必要なSwiperのCSS（swiper-bundle.min.css）が、HTMLの配信元 diamond.jp ではなく自社CDN dol.ismcdn.jp から読み込まれていた。別ドメインへの初回接続TTFBが939msと計測されており、この待ち時間がそのままFCPの遅延として積み上がっていた。
CSSはレンダリングブロックリソースだ。ダウンロードと適用が完了するまでブラウザはページの描画を開始できないため、外部ドメインへの接続コストがそのままFCPとLCPの遅延になる。変更は <link> タグのhref属性を dol.ismcdn.jp から diamond.jp に書き換えるだけだった。
<!-- 変更前 -->
<link rel="stylesheet"
href="https://dol.ismcdn.jp/common/dol/js/lib/swiper-11.1.3/swiper-bundle.min.css">
<!-- 変更後 -->
<link rel="stylesheet"
href="https://diamond.jp/common/dol/js/lib/swiper-11.1.3/swiper-bundle.min.css">| 指標 | 変更前 | 変更後 | 変化量 |
|---|---|---|---|
FCP | 1.5秒 | 0.1秒 | -1.4秒（92%） |
LCP | 2.4秒 | 0.2秒 | -2.3秒（94%） |
SI | 2.0秒 | 1.2秒 | -0.8秒 |
総合スコア | 97 | 100 | +3 |
1行の書き換えでLighthouseスコアが97から100に到達した。外部ドメインへの接続コストがFCP・LCPの支配的ボトルネックだったことが、この数値から明確に読み取れる。詳細はダイヤモンド・オンラインのボトルネック研究にまとめている。
ギズモード・ジャパン：Google Fonts CSSの外部ドメイン配信がFCPを遅延
ギズモード・ジャパンでは、Google Fonts CSS（3ファイル）が fonts.googleapis.com からレンダリングブロックリソースとして読み込まれていた。外部ドメインへの接続コストの合計が約517msと計測されており、この遅延がFCPに直接影響していた。
Google Fonts CSSを自ドメインから配信するシミュレーションを実施した。なお、CSS内で参照されるフォントファイル（fonts.gstatic.com）はレンダリングブロックリソースではない。フォントファイル自体が外部ドメインのままでも、FCPへの直接的な影響はないと考えてよい。
| 指標 | 変更前 | 変更後 | 変化量 |
|---|---|---|---|
FCP | 0.7秒 | 0.1秒 | -0.6秒 |
LCP | 0.7秒 | 0.7秒 | 変化なし |
SI | 0.9秒 | 0.9秒 | 変化なし |
FCPは0.7秒から0.1秒へ約0.6秒短縮された。LCPへの変化が出なかったのは、この段階ではまだjQueryのパーサーブロッキングという別のボトルネックが残っていたためだ。詳細はギズモード・ジャパンのボトルネック研究を参照してほしい。
弁護士ドットコム：複数のパブリックCDNがLCPを1秒押し上げ
弁護士ドットコムでは、polyfill-fastly.io・ajax.googleapis.com・cdnjs.cloudflare.com という3つの外部ドメインからJavaScriptライブラリが読み込まれていた。polyfill.min.js のTTFBが463ms・jquery.min.js のTTFBが468msと、接続確立に要する時間が計測されていた。
これらのスクリプトは <head> 内に defer 属性なしで配置されていた。同期スクリプトはHTMLパースをブロックするため、外部ドメインへの接続コストにダウンロード待ちが重なり、FCP・LCPの双方に影響が出た。
| 指標 | 変更前 | 変更後 | 変化量 |
|---|---|---|---|
LCP | 1.2秒 | 0.2秒 | -1.0秒 |
FCP | 1.1秒 | 0.2秒 | -0.9秒 |
SI | 1.6秒 | 1.1秒 | -0.5秒 |
3ドメイン分のリソースをまとめて自ドメインに集約するだけで、LCPとFCPがそれぞれ約1秒短縮された。詳細は弁護士ドットコムのボトルネック研究にまとめている。
タマチャンショップ：jQuery CDNの同一ドメイン化は効果が小さかった
タマチャンショップでも、jQueryが ajax.googleapis.com（Google Hosted Libraries）から読み込まれていた。接続コストの理屈は前の3例と同じで、外部ドメインへのDNS解決とTLS接続が発生する。
ただしこのシミュレーションは、LCP画像のlazyload解除やCLSの修正など主要なボトルネックをすべて解消した後の段階で実施したものだ。その時点でスコアはすでに100に達していた。
| 指標 | 変更前 | 変更後 | 変化量 |
|---|---|---|---|
SI | 1.3秒 | 1.2秒 | -0.1秒（119ms） |
総合スコア | 100 | 100 | 変化なし |
変化はSIが119ms短縮されるにとどまり、FCP・LCPへの影響は観測されなかった。ただし接続コスト自体は存在する。効果が小さかった理由は、この段階でjQueryがFCP・LCPのクリティカルパスから外れていたことにあると思われる。詳細はタマチャンショップのボトルネック研究を参照してほしい。
効果が大きいケースと小さいケース
4例を比較すると、外部ドメイン配信の影響の大きさに明確な差がある。どのサイトでも外部ドメインへの接続コストは発生している。それが指標に現れるのは、クリティカルパス上のリソースだけだ。
クリティカルパス上のリソースは効果が大きい
CSSはレンダリングブロックリソースだ。ブラウザはCSSのダウンロードと適用が完了するまでページの描画を開始できないため、外部ドメインのCSSは接続コストがそのままFCPの遅延に転嫁されやすい。ダイヤモンド・オンライン（FCP 92%短縮）とギズモード・ジャパン（FCP 0.6秒短縮）はこの構造を直接示している。
同様に <head> 内で defer なしに配置された同期スクリプトも描画をブロックする。弁護士ドットコムの例では外部ドメインの接続コストとパーサーブロッキングが重なり、FCP・LCPともに約1秒の改善が得られた。
補助的なリソースは効果が小さい
クリティカルパスから外れているリソースや、他のボトルネックに比べて影響が相対的に小さいリソースでは、接続コストは存在してもFCP・LCPへの改善はわずかにとどまることがある。タマチャンショップのjQueryはその典型だ。
補助的なリソースでも外部ドメインのコストはゼロではなく、ページ全体のロード時間には影響する。自ドメインへの集約に取り組む意義はある。ただしFCP・LCPへの即効性を期待するなら、まずクリティカルパス上のリソースを優先する判断が合理的だ。
自ドメインへの集約は比較的シンプル
外部ドメインのリソースを自ドメインに集約する実装は、難しくない。
CSSやJSライブラリ（パブリックCDNからの読み込み）:
対象ファイルを自サーバーやCDNに配置し、HTMLの link タグや script タグのURLを書き換えるだけだ。
<!-- 変更前: パブリックCDNから -->
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.7.1/jquery.min.js"></script>
<!-- 変更後: 自ドメインから -->
<script src="https://example.com/assets/jquery.min.js"></script>Google Fonts CSS:
Fonts APIから取得したCSSを自サーバーで配信する構成に変えるだけでも、レンダリングブロックの接続コストは解消できる。CSS内で参照するフォントファイル（.woff2）は引き続き fonts.gstatic.com から読み込んでよい。フォントファイルごと自ドメインに配置すれば外部ドメインへの依存を完全に排除できる。
自前配信に切り替えるときはバージョン更新フローも整備しておく必要がある。パブリックCDNは設定次第で最新版を自動配信するが、自ドメイン配信では更新を手動で管理することになる。
まとめ
- 外部ドメインへのリソース配信はドメインごとにDNS・TCP・TLS接続コストを生む。 同一ドメインなら既存接続を再利用できるが、外部ドメインは毎回ゼロから接続する必要がある。
- クリティカルパス上のリソースほど影響が大きい。 レンダリングブロックするCSSや同期的なJSが外部ドメインにあると、接続コストがそのままFCP・LCPの遅延として現れる。ダイヤモンド・オンラインではFCP92%・LCP94%、弁護士ドットコムでもLCP・FCPがそれぞれ約1秒の短縮となった。
- 補助的なリソースでは効果が小さいこともある。 タマチャンショップのjQueryのように、クリティカルパスから外れたリソースでは接続コストは存在してもFCP・LCPへの改善効果はわずかにとどまった。外部ドメイン配信の同一ドメイン化がすべてのリソースで劇的な効果を保証するわけではない。
- 「パブリックCDNはキャッシュが共有される」という前提はもう通用しない。 ブラウザのキャッシュパーティション化により、サイトをまたいだキャッシュ共有は無効化されている。
- HTML・CSS・JavaScriptは同一ドメインから配信したい。 初期表示のスタートダッシュを少しでも早く切るうえで、別ドメインへの接続コストは無視できない。すでに速いページでも、その0.1秒が収益を左右する局面はある。
- 対処は比較的シンプルで、ファイルを自ドメインに配置してURLを書き換えるだけだ。クリティカルパス上のCSSやJSライブラリから優先的に取り組む価値がある。
自社サイトのボトルネックを体系的に調べたい場合は、弊社の表示速度ボトルネック研究 vigilante の事例が参考になる。より詳しい調査が必要な場合はアイデアマンズまでご相談いただきたい。