「サイボウズ式」トップページの表示速度ボトルネック研究

サイボウズ株式会社が運営するオウンドメディアで、「新しい価値を生み出すチームのメディア」をコンセプトに、チームワークや働き方、組織づくりに関する記事を発信しています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

Core Web Vitalsにつながる指標の改善ポテンシャル ​

観測されたボトルネックを仮に解消した場合、Lighthouse スコアは以下のような変化を示しました。

観測時点	全ボトルネック解消シミュレーション後

総合スコア が72から100へと28ポイント変化するというシミュレーション結果が得られました。特に LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）が6.3秒から0.1秒へ、FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）が2.5秒から0.1秒へと大きな変化が観測されています。一方で TBT（Total Blocking Time）と CLS（Cumulative Layout Shift）には変化がなく、サイト自体のJavaScript実行やレイアウト安定性には問題がなかったことが読み取れます。

読み込みプロセスの変化を動画で体験 ​

本サイトでは、解消シミュレーション後に大幅な表示速度の改善が見て取れます。

サードパーティータグの影響 ​

詳細レポート

本研究ではまず、サードパーティータグを段階的に除去することで、タグ全体が表示速度に与えている影響を観測しました。あわせて、タグ由来のノイズを取り除くことで、サイト自体のボトルネックを観察しやすくする狙いもあります。タグを完全に除去することは現実的ではありませんが、最適化によってどこまでの改善ポテンシャルがあるかを把握する材料としてご覧ください。

本セクションは「サードパーティータグがページスピードに影響を与えている」という現実を数値で示すとともに、それらを最適化することでどれだけのスピード改善ポテンシャルがあるかを示唆するものです。

オリジナルページの全124リソースのうち、サイト固有のリソースは59件（約5割）、サードパーティタグ由来のリソースは65件（約5割）を占めていました。ページスピードのボトルネックを正確に把握するには、まずこの5割のタグを取り除いてサイト固有のパフォーマンスを分離する必要があります。

サイボウズ式のトップページでは、以下の10種類のサードパーティータグが検出されました。

HTMLから直接読み込まれているタグ ​

GTM経由で読み込まれているタグ ​

GTMコンテナが2つ（GTM-56XSHQ、GTM-5N49D3）同時に設置されており、GTM経由で多数のタグが連鎖的に読み込まれている構造が観測されました。サードパーティータグ全体の転送サイズは約2,774KBに達しており、そのうち YouTube埋め込み が1,806KBと大部分を占めていました。

段階的に除去した際の指標変化は次のとおりです。

サードパーティータグを全て除去した状態では、総合スコア が72から100へ変化し、LCP は6.3秒から1.7秒へ、FCP は2.5秒から0.6秒へと短縮される結果が得られました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。以降のセクションでは、この状態を起点としてサイト固有のボトルネックを観察していきます。

サイト固有のボトルネック ​

サードパーティータグの影響を切り離した状態を起点として、サイト固有のボトルネックを調査しました。本研究では全9件のボトルネック仮説を検証しています。その中から、特に影響の大きかった2件を紹介します。

ボトルネック1: パブリックCDNの外部ドメイン配信 ​

詳細レポート 差分コミット

観察された状況 ​

パブリックCDN（unpkg.com）からSwiper.jsが同期的に読み込まれている状態が観測されました。外部ドメインからのJavaScript読み込みでは、DNS ルックアップと TLS ハンドシェイクで100〜300ms程度の遅延が発生します。

<script src="https://unpkg.com/swiper@4.5.1/dist/js/swiper.min.js"></script>

解消シミュレーションの方法 ​

unpkg.com から配信されていた swiper.min.js を、サイトと同一ドメイン（cybozushiki.cybozu.co.jp）から配信するように変更しました。

シミュレーション結果 ​

解消前	解消後

外部ドメインへの DNS ルックアップと TLS ハンドシェイクが不要になったことで、LCP が0.4秒短縮されるという結果が観測されました。パブリックCDNの利用は手軽である一方、接続コストがページ読み込みに影響を与えていたことがこのシミュレーション結果から読み取れます。

ボトルネック2: Google Fonts（日本語Webフォント）の読み込み ​

詳細レポート 差分コミット

観察された状況 ​

サイトでは Google Fonts（M PLUS Rounded 1c）が使用されており、fonts.googleapis.com からCSSが <link rel="stylesheet"> で読み込まれていました。Lighthouse の推定によると約550msのレンダリングブロックが発生しており、さらにCSS内で参照される16個の woff2 フォントファイルが直列で読み込まれるCritical Request Chain（HTML → CSS → woff2の3段階）が形成されていました。合計転送サイズは約227KB（M PLUS Rounded 1c: 192KB + Roboto: 35KB）でした。

このシミュレーションはサイトの仕様（フォントの見た目）が変わることを前提として行いました。

解消シミュレーションの方法 ​

Google Fonts のCSS参照と woff2 ファイル18件を除去し、CSSの font-family から M PLUS Rounded 1c を除去して、既存のフォールバックフォント（ヒラギノ角ゴ ProN W3、Meiryo、YuGothic等）に切り替えました。

/* 変更前 */
font-family: 'M PLUS Rounded 1c', 'Hiragino Kaku Gothic ProN',
             'ヒラギノ角ゴ ProN W3', Meiryo, YuGothic, sans-serif;

/* 変更後 */
font-family: 'Hiragino Kaku Gothic ProN',
             'ヒラギノ角ゴ ProN W3', Meiryo, YuGothic, sans-serif;

シミュレーション結果 ​

解消前	解消後

日本語Webフォントの読み込みを取り除くと LCP が1.2秒、FCP が0.6秒変化するという結果が得られました。日本語Webフォントは文字数の多さからデータ量が英語フォントと比べて桁違いに大きく、レンダリングブロックとフォントファイルの直列読み込みが重なることで、LCP と FCP に対して非常に大きな影響を及ぼしていたことがこのシミュレーション結果から読み取れます。

まとめ ​

サイボウズ式（cybozushiki.cybozu.co.jp）の表示速度を観測したところ、総合スコア 72、LCP 6.3秒、FCP 2.5秒という値が計測されました。本研究では、この計測値の背後にあるボトルネックを切り分けて観測するため、順に解消シミュレーションを実施しました。

観測されたボトルネックとその影響は次のように整理できます。

• サードパーティータグの集合体: 除去によって 総合スコア が +28、LCP が4.6秒短縮。10種類のタグ（特に YouTube埋め込み 1,806KBとGTM経由のタグ群）の影響が大きく、サイト自体の作りは十分に高速であることが判明しました。
• パブリックCDNの外部ドメイン配信: 同一ドメイン化で LCP が0.4秒短縮。外部ドメインへの接続コストが表示速度に影響していたことが観測されました。
• Google Fonts（日本語Webフォント）: 読み込み停止で LCP が1.2秒、FCP が0.6秒短縮。約550msのレンダリングブロックと16個のフォントファイルの直列読み込みが影響していました。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は72から100へ、LCP は6.3秒から0.1秒へと変化しました。特筆すべきは、サードパーティータグを除去した時点で 総合スコア が100に到達していた点で、パフォーマンス低下の主因がサードパーティータグにあり、サイト自体の構成は高い水準にあったことがこの結果から読み取れます。