中国へWebサイトを届ける4つの方法を計測——うち3つは一度も読み込みを完了しなかった

中国のWebプロジェクトには、問題は距離であり、したがって直し方は場所だ——バイトを近づけ、できれば本土の内側に入れれば、サイトは動く——という根強い思い込みがあります。それがどこまで本当かを知りたかったので、議論するのではなく計測しました。

何を計測したか

一つの参照ページを、ふつうのエンタープライズページらしく作りました。HTML、スタイルシート、スクリプト、219KBのヒーロー画像、Webフォント、タグマネージャー、公開CDNのスクリプト、埋め込み動画、検証ウィジェットで関門をかけた問い合わせフォーム、越境API呼び出し、そしてオリジン上のエンドポイントに送信するリードフォームです。

この品目構成は恣意的ではありません。前週に中国の内側から12の実在するベンダーWebサイトを計測し、実際に応答を止めた第三者ホストを記録したところから来ています。現れたカテゴリ——フォント、タグ管理、広告と解析、メディアアセット、クラウドの静的アセット——が、このチェックリストになりました。配信できるとわかっている機能を選んだわけではありません。

同じページを、次に4通りで配信しました。

	配信の構成	ICP備案	第三者参照
1	オフショアのオリジン	不要	変更なし
2	ニアショアのエッジ、香港	不要	変更なし
3	中国本土の内側	必要	変更なし
4	中国本土の内側、21YunBox Optimizer経由	必要	同一オリジンのパスに書き換え

経路1から3はバイト単位で同一のコンテンツを配信します——各実行の前に、3つのホストすべてで一次（ファーストパーティ）アセットのSHA-256を比較して検証しました。経路4は、第三者参照を中国の内側から配信される同一オリジンのパスに書き換えた、同じオリジンのコンテンツです。その書き換えこそが計測対象の処置であり、それは開示されています——依存は一つも削除していません。経路4は他よりも多くのリクエストを発行します。少なくではありません。他の経路で死んでいたリソースが、実際に読み込まれるからです。

プローブ：上海、受測対象のどれとも異なるクラウドプロバイダー上。どの経路にも自ネットワークの優位が生じないようにしています。5つのインターリーブされたラウンド——各経路を1ラウンドにつき1回ずつ、順繰りに計測——により、時間帯による変動が4つの間の差ではなく、4つ全体にわたるノイズとして現れるようにしました。

結果

	TTFB	FCP	LCP	60秒以内に読み込み完了	リクエスト数
1 オフショアのオリジン	140ms	2,468ms	8,176ms	0 / 5	14
2 ニアショア（香港）	35ms	548ms	1,480ms	0 / 5	15
3 中国国内、ICP備案済み	33ms	560ms	920ms	0 / 5	15
4 中国国内、Optimizer経由	493ms	1,120ms	1,124ms	5 / 5	34

機能面の結果、各5回の試行：

	Webフォント	タグマネージャー	埋め込み動画	フォーム検証	越境API
1 オフショア	5/5	5/5	0/5	0/5	5/5
2 ニアショア	5/5	5/5	0/5	0/5	5/5
3 中国国内、備案済み	5/5	5/5	0/5	0/5	5/5
4 Optimizer経由	5/5	5/5	5/5	5/5	5/5

一切応答しなかった第三者ホスト：経路1・2・3では2つ——3つとも同一。経路4ではゼロ。

これが示す3つのこと

問いは「どれだけ速いか」ではなく「完了するか」である

4つの配信構成のうち3つが、毎回、60秒以内にページ読み込みを完了できませんでした。これはパフォーマンスの勾配ではなく、二値の結果であり、訪問者が体験するのはそれです。動画が決して再生されず、フォームが決して送信できないページは、遅いページではありません。動かないページです。

第3行が最も重要な行である。なぜなら、それは当社にとって都合の悪い行だからだ

当社は中国国内からの配信を売っています。第3行の、中国国内の、ICP備案済みで、それ以外は無改変の経路は、**4つの構成の中で最良の最初のバイトまでの時間（33ms）と最良の最大コンテンツ描画（920ms）**を記録しました——そしてその動画、そのフォーム検証、その読み込み完了は、太平洋の反対側のデータセンターからページを配信するのと見分けがつきませんでした。

サイトは合法。サイトは近い。それでもサイトは動きません。

これは、ICP備案と中国国内のサーバーだけでは、それ自体は答えにならないという、当社の持つ最も明確な証拠です。それらは、動く構成のための前提条件であり、それは別の、はるかに狭い主張です。なぜそうなのかは別途書いており、これはその背後にある計測です。

最も速い最初のバイトは、決して完了しなかった経路のものだった

第3行はTTFBで第4行に15倍の差をつけて勝ちます。完了する行は第4行だけです。見出しになる遅延の数字に最適化すれば——そして中国のパフォーマンスの議論の大半はそれに最適化しています——失敗する構成を選ぶことになります。

当社に有利でない点を、率直に

経路4は4つの中で最悪の最初のバイトまでの時間であり、それも桁違いです。 33msに対して493ms。ページ自身のHTMLが、ブラウザに届く前に本土の外へ出て戻ってきます。これを当社は別の場所で越境のラウンドトリップを取り除くものだと説明してきました。それは誤りで、この計測がそれを正したのです。ラウンドトリップは取り除かれていません。ブラウザのクリティカルパスから外に移され、そこで冷たい接続を何十回も使う代わりに、ウォームでプールされた接続で一度だけ払われるのです。

経路4の最大コンテンツ描画は、経路3よりわずかに劣ります——920msに対して1,124ms。経路3は、何も間に挟まずにローカルディスクから静的ファイルを配信しています。その数字で勝つべきであり、実際に勝っています。

ニアショアと中国国内の差は、予想よりずっと小さい。 静的配信の遅延では、オフショアからニアショアへは5.5倍の改善、ニアショアから中国国内へは13%です。この軽さのページでは、ニアショアのエッジが生の遅延の便益の大半を捉えます。ラウンドトリップがもっと多い重いエンタープライズサイトならその差は広がりますが、計測したのは13%であり、それを倍率として述べるつもりはありません。

リードフォームは4つの経路すべてで成功したので、何も区別しませんでした。 当社のテスト用エンドポイントは自社のオリジン上にあり、中国から到達可能です。ただ遅いだけです。実際のマーケティングオートメーションのエンドポイントは、しばしばそうではありません。この機能は、意味を持つ前にもっと代表的なエンドポイントが必要で、それまでは証拠として使いません。

この計測の限界

• プローブはオフィス回線ではなくデータセンター回線です。 そこからは、失敗すると見込んだ第三者ホストのうち2つが実際には到達可能で、他は到達不能でした。商用クラウドは企業のブロードバンド接続よりも国際トランジットが実質的に良好です。ここのすべての数字は下限であって、最悪値ではありません。
• 参照ページは軽量です。 実在のエンタープライズサイトより一次アセットが少なく、したがってラウンドトリップも少なく、したがって経路2と3の計測差は本番サイトが示すよりも小さくなります。
• 経路あたり5ラウンド。 毎回一貫していた二値の結果を立てるには十分ですが、連続値の分布を特徴づけるには不十分です。それに対処する24時間サンプリングの実行が進行中です。
• 経路4のここでの動画の扱いは、本番の構成ではなく、計測しやすさのために作った簡略化された構成です。
• 1日、1つのプローブ場所。 中国の越境の挙動は1日の中で2桁以上変動します。

次に計測すること

5つの第三者リソースのカテゴリを10分おきに、直接と当社ネットワーク経由で比較する24時間の実行。平均ではなく中国現地時刻の時間帯ごとに報告します——日次の平均は、事業者が実際に計画の軸に据える夕方の劣化を消してしまうからです。次に、中国のオフィスのブロードバンド回線から同じ参照ページを。これにより、上のすべての数字が実態より良く見えることになります。

それらも、何を言おうと、公表します。

同じ到達性チェックは当社の中国ファイアウォールテスト（英語）で自社サイトに走らせられ、本土の内側からのLighthouse監査は当社の中国スピードテスト（英語）で行えます。この計測を正しくやる前に8通り間違えた話がほしければ、そのリストはこちらです。