2025 年の真のパフォーマンス向上

顧客とエンドユーザーは、かつてないほど即時のインタラクティブ性を求めています。Google などの企業が検索結果の主要なランキング要因としてパフォーマンスを確立しているため、パフォーマンスは成功の鍵を握っています。Akamai はサイトのパフォーマンスに多額の投資を行ってきました。改善と新機能を利用することで、実際のお客様に最適なアプリパフォーマンスを提供できます。

このブログ投稿では、お客様の Core Web Vitals（CWV）指標に改善がもたらすプラスの影響について説明します。SEO ランキングシグナルとして、特に 2025 年には、CWV は実際のパフォーマンスを把握するための事実上の標準となります。CWV を使用するのは、接続、場所、ブラウザー、デバイスに関係なく、現代のアプリケーションを使用している実際のユーザーに焦点を当てているからです。

次に、これらの最適化を使用してアプリケーションパフォーマンスを向上させる方法について説明します。これには、Akamai が導入した最適化と、サイトやアプリを高速化するために Akamai の設定に追加できる機能とコントロールの両方が含まれます。

それでは始めましょう。

過去 1 年間に導入したパフォーマンスの向上は、実際のユーザーに測定可能な影響を与えることができます。Google は、Chrome User Experience Report（CrUX）を通じてこれを確認しました。CrUX は、Google が提供する一般的なデータセットであり、実際のユーザーがパフォーマンスと読み込み時間の面でウェブサイトをどのように体験しているかについての知見を提供します。

このデータは実際にオプトインしたユーザーから収集され、Google ではシミュレートされたテストやラボベースのテストではなく、基本的なユーザーとの対話処理を反映した指標を追跡して集約することができます。

Akamai の新機能により、Largest Contentful Paint や Interactions to Next Paint、より技術的ですが馴染みのある最初の 1 バイトが到達するまでの時間など、ユーザー中心の主要パフォーマンス指標（KPI）の結果が改善されました。これらの Web Vital が順調に進化している Web サイトの例をいくつか見てみましょう。

注：次の図は、データセット内すべての Web サイトの CrUX 履歴データを視覚化できる、優れた treo.sh ツールのスクリーンショットです。

上部のグラフの緑色の部分は、LCP が 2.5 秒未満だったリクエストの割合を示しています。また、2 月以降には、3 か月前と比較して「良好」（緑色）なユーザー体験を得ている（LCP が 2.5 秒未満）ユーザーの割合が 20% 増加したことを示しています。

このサイトの測定結果は「要改善」領域（オレンジ色）であることが多く、Google 検索結果でペナルティが課されている可能性がありましたが、現在はユーザー満足度の向上を示す強力なシグナルである緑色に定着しています。

セキュリティに重点を置いているある銀行は、いくつかの点で Interaction to Next Paint（INP）が目覚ましく改善されたことに気付きました（図 2）。独自の実装の改善を行っただけでなく、過去数か月間にリリースされた複数の Akamai Bot Manager JavaScript 最適化の恩恵も受けました。この銀行では INP が継続的に改善され、「良好」な体験をしている（INP が 200 ミリ秒未満）ユーザーの割合が約 55% から 87% 以上になりました。

最初の 1 バイトが到達するまでの時間（TTFB）は、それだけでは CWV ではありませんが、LCP との相関性が高いことが多いため、追跡すべき重要な指標です。

すでに高速な E コマースサイトは、プラットフォームの改善により過去 8 か月でさらに高速化しました（「改善点」セクションで詳しく説明します）。図 3 では、Akamai プラットフォームリリースに合わせて、その Web サイトにおける TTFB 体験が良好なユーザーの割合が継続的に増加していることを示しています。

旅行業界の別のお客様は、これまで TTFB の数値が標準を満たしていなかったため、Akamai のパフォーマンス最適化を使用していませんでした。Akamai のパフォーマンスチームから推奨されたベストプラクティスを実行した結果、その顧客の TTFB は 1 か月強の間に 3 秒からわずか 0.6 秒に改善されました（図 4）。

Akamai を利用することで、低速の Web サイトが高速化しただけでなく、極めて高速な Web サイトがさらに高速化しました。図 5 に示すのは、月あたりの訪問数が何百万にも達する E コマースサイトです。このサイトは最近、P75 で 500 ミリ秒の LCP という見えない壁を越えました。また、INP は脅威の 50 ミリ秒であり、Cumulative Layout Shift（CLS）は 0.00 という完璧なスコアです。

Akamai のプラットフォームを使用することで、トップクラスのパフォーマンスによるアップタイムの改善のメリットを得られる、成熟した極めてスケーラブルなサイトを構築できます。トレードオフや妥協は不要で、ただただ優れています。

このブログ記事をここまで読んだ時点で、他のコンテンツ・デリバリー・ネットワーク（CDN）と比較して Akamai のパフォーマンスはどうであるかを知りたいと思われるかもしれません。しかし、特に 2025 年には、この種の比較を良心的に行うことは難しいと Akamai は考えています。

主な理由の 1 つは、実際のユーザーの CWV 指標は CDN の速度だけでなく、サイトのフロントエンドとバックエンドのプログラミングや、特定の CDN 設定にも依存しているためです。これらはすべて、サイト間で大きく異なる場合があります。そしてもちろん、高速な Web サイトと低速な Web サイトの両方を任意のプラットフォームで構築できます。 

もう 1 つの方法は、TTFB などの下位レベルの指標を使用することです。表面上、これは CDN 間で容易に比較できる指標です。各 CDN に 1 つのオブジェクトをダウンロードし、接続設定とリクエスト時間を測定するだけで、完成です！ 

しかし、これらの結果を簡単に収集することはできますが、現在の HTTP/3（および HTTP/2）とそのマルチオブジェクト接続の世界では、ますます意味がなくなりました。高度な機能（ストリームの優先順位付けや帯域幅の共有など）を使用してこれらの接続を効率的に（再）使用することは、接続の初期設定よりも、エンドユーザー体験（および LCP などの指標）においてはるかに重要です。

さらに、TTFB の測定方法は次のような他の多くの手法によって変わります。103 Early Hints、Early Data（0-RTT）、DNS HTTPS レコード、Speculation Rules API など（「改善点」セクションで説明します）。

そのため、2 つの CDN 上の 2 つの単一オブジェクト（これらの機能のいずれかを有効にしているオブジェクトと有効にしていないオブジェクト）の TTFB を測定すると、CDN の実際の能力については何も明らかにしていない、根本的に異なる結果が得られます（図 1～5 を参照）。

私たちの主張を証明するために、Akamai から移行すれば TTFB が大幅に減少すると予測したベンチマークを信用し過ぎた顧客の例を示します（図 6）。この顧客は 2024 年 8 月初旬に別のソリューションに切り替えましたが、残念ながらパブリック CrUX データが即座に悪化しました。

Akamai のお客様からの CWV データにフォーカスし、従来のベンチマーク手法に頼るのではなく、実際のユーザーにどのような影響を与えたかを示します。大きな可能性に興奮してはなりません。そうではなく、いくつかの世界最大規模のサイトの CWV を検索してみてください。そのサイトは Akamai で実行されており、パフォーマンスが極めて優れている可能性が高いです。

過去 12 か月間に Akamai が行った改善から期待できる目覚ましい結果を確認したところで、次にそれらの改善の内容を詳しく説明します。次の領域で機能強化を行いました。

• プラットフォーム
• Akamai Image & Video Manager
• セキュリティソリューション
• リアルユーザー監視と可観測性

Akamai の中心にあるのは、より多くのワークロードをエンドユーザーの近くに配置し続ける、高度に分散されたプラットフォームです。この広範なプラットフォームにより、これまでにない規模で改善を実施することができます。

コンテンツをできるだけ早く（実際のユーザーに）配信することを目的とした最新の機能強化には、次のようなものがあります。

• 103 Early Hints
• Early Data（0-RTT）
• オリジンへの TLS 1.3
• Speculation Rules API
• DNS 最適化
• 反増幅制限

キャッシュ不可能なリソースやキャッシュミスがある場合、Akamai のエッジサーバーはオリジンサーバーに接続する必要があります。これにより、クライアントのブラウザーとエッジサーバー間の接続は、応答が到着するまでアイドル状態になります。

Early Hints を使用すると、ブラウザーはその待機時間を使用して、上位の CSS スタイルシート、Web フォント、ロゴ、重要な JavaScript など、指定したリソースをプリロードし、サードパーティのドメインまたはサブドメインにプリコネクトできます。Akamai は、これらのヒントを完全にエッジで制御し、レンダリング体験（LCP）を大幅に高速化できるようにします。

Early Data は、HTTP/2 over Transmission Control Protocol（TCP）と HTTP/3 over QUIC の両方にとって強力な新機能です。これにより、ブラウザーは Akamai エッジへのほとんどの接続でネットワークラウンドトリップ時間（RTT）全体を削減できます。

また、Early Hints などの他のオプションとうまく連携して、ユーザーのブラウザーにできるだけ早くデータを取得できます。Akamai では、この強力な機能に固有のセキュリティパフォーマンスのトレードオフを詳細に設定できます。

Akamai は永続的な接続を最大限使用していますが、Akamai エッジからオリジンへの新しい TCP 接続を確立する必要がある場合があります。そこで、TLS 1.3 のサポートを追加し、TLS 1.2 で必ず生じる余計な RTT を回避しました。レイテンシーに関するこれらの利点を生かすためには、オリジンを正しく設定する必要があります。

将来のナビゲーションをプリフェッチしたり、プリレンダリングしたりすることで、新しい Speculation Rules API を利用し、マルチページアプリケーションの高速化を図ることができます。この API は、ユーザーが次にアクセスする可能性のあるページをプリレンダリングしたときに、ほぼ瞬時にロードするようにします。

Akamai には、Speculation Rules をエンドユーザーに配信するためのさまざまなオプションがあります。これにより、LCP や CLS などの重要な KPI に大きな影響を与えることができます。

当社の DNS チームは、次世代 Anycast DNS アーキテクチャの最初のフェーズを展開しました。このプログラムは「Megacloud」と呼ばれ、22 の独立したクラスターのうち 8 つがすでに変換されている段階にあります。

Megacloud は、さらに多くの拠点からの各 Anycast ネットワークについて発表しています。移行は、攻撃の回復力を損なわないように複雑かつ慎重に行われます。その結果、すべてのパーセンタイルやリージョンで Anycast DNS ルックアップが高速化されます。

通常、QUIC のハンドシェイクを完了するのには、ネットワーク上で 1 RTT しかかかりません。しかし、Akamai は特定の業界のセキュリティ要件に厳格に準拠（ RFC 9000 の推奨事項を反映）しているため、実際には多くの QUIC（および HTTP/3）接続が 2 つの RTT を必要としました。

この問題を解決するために、Akamai は QUIC の反増幅制限を 3（RFC に準拠）から 7 に増やし、単一の RTT だけで接続を確立して HTTP/3 のパフォーマンスを最大限に生かせるようにしました。

シャープな画像は、現代の Web に欠かせない要素です。LCP を適切にするためには、画像をすばやく読み込む必要があります。Image & Video Manager の 2 つの新機能がこの実現に役立ちます。

• SharpYUV Chroma Subsampling：AVIF および HEIF は、当社が提供する 2 つの最新画像形式で、クロマサブサンプリングの SharpYUV バージョンを使用して、より良いカラー表現と圧縮効率を提供します。

• Cache+：この新しいアドオンにより、Akamai Cloud Wrapper を使用して Image & Video Manager の派生物をキャッシュできるようになります。Cloud Wrapper 内に専用のキャッシュスペースを提供し、エビクションポリシーとキャッシュの保持をより細かく制御できます。これは、不要な再処理を減らし、画像をより長くキャッシュに保持し、ロングテールのミスを減らすため、パフォーマンスの向上に効果的です。

ほとんどのお客様は、セキュリティに妥協することを望んでいません。しかし、それはパフォーマンスを気にしないという意味ではありません。

過去 12 か月間に、当社のセキュリティソリューション（Akamai Bot Manager  や Akamai Content Protector など）のエッジ側とクライアント側両方のロジックを最適化しました。クライアント側のライブラリでは、次のような JavaScript の一般的な最適化が行われています。

• 長いタスクを小さなピースに分割
• 未使用コードの削除
• 高速ライブラリへの切り替え
• 古いコードを高速なコードに置き換え

これらの最適化により、ネットワークを通じて送信されるバイト数が減少し、クリティカルパスの輻輳が減少し、JavaScript 構文解析とコンパイル時間が短縮されました。さらに、Total Blocking Time（TBT）および Interaction to Next Paint（INP）指標に対するセキュリティソリューションの影響も大幅に軽減されました（例：図 2 を参照）。

パフォーマンス測定基準と、さまざまな最適化がそれらにどのように影響するかを理解したところで、次に問うべきことは何でしょうか。「それらをどのように計測するか」です。特に複数のクラウドプロバイダー、異なるサービス、CDN を使用する場合は、エンドツーエンドの可視性を実現することが困難な場合があります。

幸いなことに、Akamai mPulse リアルユーザー監視（RUM）ソリューションや CDN の可観測性など、これらの特定の運用上の問題に対処するためのソリューションがあります。

• CWV アトリビューションダッシュボード：サイトが遅いということを把握することは 1 つの課題ですが、サイトが遅い理由を明らかにすることはより難しい課題です。この問題を解決するために、いくつかの新しい mPulse ウィジェットが利用可能になりました。CLS の問題の属性付け、最悪かつ最も頻繁な INP の原因の特定、LCP 要素の分類に役立ちます。

• 新しい指標とタイマー：mPulse には、多くの興味深いタイマーとディメンションが追加されました。一般的な可視性のギャップを解消し、RUM ノイズを低減することで、最も関連性の高いデータまで簡単にアクセスできるようになります。これには、Frustrationindex、Page CDN Cache Status、4 つの新しいフロントエンドタイマー、BFCache 情報が含まれます。

• Unattributed Navigation Overhead（UNO）：この新しいタイマーは、他のタイマーでは考慮されない、ナビゲーションのすべての「不明な」時間と「余計な」時間を蓄積します。これには、ブラウザーの遅延、ディスクアクセス時間、クロスオリジン制限からの隠れた時間などが含まれます。この指標は、見落としがちな問題を発見し、ギャップを埋めるために役立ちます。

• Akamai DataStream 2 が修正され、パフォーマンスに関心のあるユーザーに関連するデータポイントが追加されました。

  • TLS 初期データおよび 103 Early Hints フィールドのサポート
  • Akamai EdgeWorkers のサポート
  • TrafficPeak 宛先のサポート

• Breadcrumbs：新しい Breadcrumbs 機能は、コンテンツ配信に影響を与えるパフォーマンスやエラーの状況をリアルタイムで可視化します。

• Common Media Client Data（CMCD）：動画、音楽、ゲームなどのコンテンツをストリーミングするデバイスからパフォーマンスデータと使用状況指標を収集することは、ストリーミングのパフォーマンスを測定するために不可欠です。特定して緩和する：

  • バッファリングイベント
  • 起動時間の遅さ
  • 再生品質の問題
  • エラー率
  • スループット

過去 12 か月間で、Akamai は、最新のアプリケーションがより高速になることを、紙面上だけでなく実際のユーザーも実感できるようにするいくつかの改善を導入しました。これらの変更の効果は CrUX データに何度も明確に現れており、CWV の結果の大幅な改善につながり、エンドユーザー体験と誰もが望む Google 検索エンジンランキングの両方が向上しています。

多くの機能強化に満足しているものの、セキュリティ、拡張性、可用性を考慮しつつ、チームは常にミリ秒単位の削減の機会を模索しています。

今後数週間、数か月、そして数年で、多くの最適化を開始する予定です。Akamai は今後もさらなる高速化を目指しますので、ぜひご期待ください。