PagesとWorkersで実現する「エッジ配信、エッジ処理」

高額の広告費を投じてランディングページ（LP）に見込み客を誘導したのに、ページが開くまでに何秒も待たされて離脱されてしまう。ECサイトで商品一覧や詳細ページが重く、購入手続きの前にカゴ落ちしてしまう。海外からのアクセスで表示が極端に遅く、グローバル施策の成果が上がらない。

こうした問題は、単なる「Webサーバーの技術的な課題」ではありません。広告投資の回収率、検索順位（SEO）、そして何より問い合わせや売上につながるコンバージョン率（CVR）を直撃する、極めて深刻なマーケティングの事業課題です。

前節では、サーバー管理からエンジニアを解放するための開発基盤として「Cloudflare Workers」の概要を解説しました。

この節ではさらに一歩進めて、Webサイトのフロントエンドを高速配信する「Cloudflare Pages」と、動的な処理を最寄り拠点で実行できるようにする「Cloudflare Workers」について、それらがどのようにWeb施策の体験とビジネス成果の向上に寄与するのかを解説します。

PagesからWorkersへ： 静的配信と動的処理のシームレスな統合

CloudflareにおけるWebフロントエンドのホスティングは、もともと「Cloudflare Pages」というサービスを中心に普及しました。

GitHubなどと連携し、コードを更新するだけで世界中のエッジサーバーへ自動的にWebサイトが公開（デプロイ）される仕組みは、インフラの専門知識がない制作会社やフロントエンドエンジニアにとっても扱いやすく、LPやブランドサイトを迅速に公開できるツールとして親しまれてきました。

現在もPagesは利用されていますが、Cloudflareの開発基盤はさらに進化しています。新しくWebサイトやWebアプリを構築する場合、「Workers Static Assets」を活用し、Workers基盤の上で静的配信と動的処理をまとめて扱うアプローチが主流となっています。

• 従来： HTMLや画像などの静的ページを公開する「Pages」、プログラムを動かす「Workers」のように分担して実行
• 現在： 「Workers」という単一のグローバルな基盤の上で、静的ファイルの高速配信も、動的なプログラム処理も一元的に実行

ここで重要なのは、世界中の最寄り拠点（エッジ）で、ページの高速配信だけでなく、表示を切り替える高度な処理まで、一元的にこなせる基盤が整っているという点です。

出典： Cloudflare Docs: Workers Static Assets

出典： Cloudflare Docs: Cloudflare Pages

出典： Cloudflare Docs: Cloudflare Workers

ユーザーの近く（エッジ）で処理すると、なぜ劇的に速いのか

Webサイトの表示スピードを決定づける大きな要因のひとつが、ユーザーとサーバーの間の「物理的な距離」です。

東京に置かれたWebサーバーに対して、東京のユーザーがアクセスする分には遅延は小さく抑えられます。しかし、同じサーバーに対してアメリカ、ヨーロッパ、東南アジア、あるいは日本国内でも遠隔地や移動中のスマートフォンからアクセスすると、場合によっては大海を越えたり、無数のネットワークを中継したりする分だけ通信そのものに時間がかかるだけでなく、応答時間（レイテンシー）が積み重なって長くなってしまいがちです。

Cloudflareでは、世界330都市以上に分散されたエッジネットワークから、ユーザーに最も近い拠点を通じてHTMLや画像を即座に返します。

さらにWorkersの強みは、単にあらかじめ保存されたファイル（キャッシュ）を返すだけにとどまりません。以下のような機能を備え、高速処理を実現しています。

• アクセスしてきたユーザーの地域や言語の判定
• 条件に応じたURLの書き換えやリダイレクトの実行
• 外部APIから最新データを取得し、エッジ上でページを組み立てて返送

わざわざ遠くにあるオリジンサーバーまで通信を往復させることなく、こうした一連の動的処理を、ユーザー最寄りの拠点（エッジ）で完結させます。無駄な通信の往復（ラウンドトリップ）が物理的に消え去るため、画面表示までの体感速度が劇的に向上するのです。

わずか0.1秒の表示速度の差が売上（CVR）を左右する

「表示速度を少し改善したくらいで、本当に売上や成果が変わるのか？」と疑問に思う方もいるかもしれません。しかし、表示速度とビジネス成果の因果関係は、客観的な調査データによって明確に証明されています。

Googleの委託を受けてDeloitteが実施した大規模調査（2020年）では、欧米の小売、旅行、ラグジュアリーなどのモバイルサイトを詳細に分析しました。その結果、サイトの読み込み速度がわずか0.1秒改善しただけで、小売サイトのコンバージョン率（CVR）が8.4%、旅行サイトでは10.1%も向上したことが報告されています。

また、Cloudflareの顧客事例においても、越境ECプラットフォーム「Ueeshop」では、Cloudflareの導入によって平均ページ読み込み時間を約30%短縮し、出店企業のCVRやリピート率の大幅な向上を達成したことが公表されています。

数秒単位の致命的な遅延はもちろんのこと、わずかコンマ何秒の「待ち時間」を取り除くだけで、ユーザーのストレスが減り、購入や問い合わせという行動へスムーズに進んでくれるのです。

Web高速化は、単にエンジニアの技術的な課題、努力目標ではありません。広告費やマーケティング投資の回収率を最大化する、即効性のある売上改善施策なのです。

出典： Deloitte: Milliseconds make Millions

出典： Cloudflare Case Study: Ueeshop

SEOにおいて「表示速度」が持つ意味

SEO（検索順位）の観点においても、表示速度は無視できない要素です。Googleは検索アルゴリズムの評価指標のひとつとして「Core Web Vitals（コアウェブバイタル）」を採用しており、以下の3つの指標を良好に保つことを推奨しています。

• LCP（Largest Contentful Paint）： 主要コンテンツが表示されるまでの速さ（目安：2.5秒以内）
• INP（Interaction to Next Paint）： クリックやタップなどの操作に対する反応性（目安：200ミリ秒未満）
• CLS（Cumulative Layout Shift）： 読み込み中の画面レイアウトの安定性（目安：0.1未満）

ただし、ここで注意すべきなのは、表示速度を改善すれば、自動的に検索順位が上位になる、といった単純なものでないという点です。Google自身も公表しているとおり、検索順位の根幹はあくまでコンテンツの品質や検索意図との合致であり、速度だけで上位表示が保証されるわけではありません。

速度改善を、検索エンジンの評価を上げるための小手先のテクニック、と捉えるのではなく、検索から訪れてくれた貴重な見込み客を逃さず、最高の体験を提供するための基盤として整備することが本質的なアプローチと言えるでしょう。

出典： Google Search Central: Core Web Vitals and Google Search results

マーケティング施策を加速させる「エッジA/Bテスト」

Workersが、その真価を発揮する場は、Webページを速く届けることだけに限られません。マーケターの日々の施策そのものを劇的に進化させる武器にもなります。その代表例が「エッジA/Bテスト」です。

キャンペーンLPなどで、たとえば「価格訴求のAパターン」と「機能訴求のBパターン」の効果を比較検証したい、といった場合、従来のクライアントサイド型A/Bテストツールでは以下のような問題が発生しがちでした。

• JavaScriptが動くまで画面が一瞬白くチラつく「Flicker現象」の発生
• 計測スクリプトの重さによる、ページの表示速度（Core Web Vitals）の悪化
• リダイレクトのタイムラグ発生による、ユーザーの離脱

Cloudflare Workersを活用すれば、ユーザーからの通信が最寄りの拠点に届いた瞬間に、CookieやURLパラメータに基づいたA/Bパターンの振り分けをエッジで即座に判定します。

画面のチラつきやリダイレクト遅延を一切発生させず、完全にシームレスな状態で高速なA/Bテストを展開できます。この仕組みを応用することで、訪問者の地域（国、都道府県）に応じたコンテンツの切り替えや、キャンペーン対象者向けの限定案内なども、極めてスムーズに実装可能です。

出典： Cloudflare Docs: A/B testing on Workers

パーソナライズは「やりすぎない」設計が肝心

エッジで高度な動的処理ができるようになると、「ユーザーごとに表示を極限までパーソナライズしたい」などと考えがちです。しかし、マーケティング実務においては慎重なバランス感覚が求められます。

表示の出し分け条件を複雑に増やしすぎると、以下のようなデメリットが生じる可能性が高くなるためです。

• キャッシュが効きにくくなることによる、全体的な配信コストやレスポンスへの悪影響
• どのユーザーに何が表示されているかといった、計測や検証の複雑化
• 検索クローラーと一般ユーザーで異なる内容を見せることによる、SEO上のリスク

技術的に可能であることと、施策として成功することは別問題です。まずはシンプルなA/Bテストや、地域別の拠点案内など、「何を検証したいのか」、「どの指標で成否を判断するのか」が明確な用途からスモールスタートで取り組むことが推奨されます。

「Workers Previews」が変える制作、確認フロー

Webマーケティングの改善サイクル（PDCA）を回す上で、ボトルネックになりがちなのが公開前の確認、承認フローです。

テキストの修正やバナーの差し替えを行うたびに、制作会社にテストサーバーの環境構築を依頼し、Basic認証の設定を待つ。このようなフローでは施策のスピードが大きく鈍ってしまいます。

Cloudflareの開発環境では、Gitのブランチごとに本番同等のプレビュー環境を瞬時に自動生成できる「Workers Previews」が提供されています。専用の確認用URLを制作会社から共有してもらうだけで、マーケターやクライアント、社内関係者が実機で即座にデザインや文言を確認できます。

フロントエンドエンジニアや制作会社がストレスなく開発できる環境を整えることは、マーケティングチームにとっても「施策の制作からリリースまでの待ち時間を極小化する」という大きな恩恵をもたらします。

出典： Cloudflare Docs: Workers Previews

DOMOの視点

ツールを導入する前に、ユーザーの待ち時間を分析する

DOMOとしてWeb表示速度やエッジ基盤について検討する際、「とりあえず」PagesやWorkersへの移行をお勧めすることはありません。最初に確認させていただくのは、ユーザーが、画面のどこで、なぜ待たされているのか、といったボトルネックの所在です。

それによって、以下のような施策を検討します。

• 画像やフォントが重い場合： サーバーの移行を急がず、画像の自動最適化（Cloudflare Images等）やキャッシュ設計を整える
• バックエンド（CMSやDB）の処理が遅い場合： オリジンサーバーへの負荷をエッジキャッシュで逃すアーキテクチャを先に検討する
• 海外からのアクセスが多い／動的な出し分けを行いたい／A/Bテストでチラつきをなくしたい／制作から公開までのリードタイムを縮めたい場合： ここで初めて、Workersを活用して処理そのものをエッジへ移す

DOMOが大切にしているのは、「最新技術を導入した」という自己満足ではなく、「広告費の無駄が減ったか」、「離脱を防いでCVRが上がったか」、「マーケティング施策が早く世に出せるようになったか」という、あくまでビジネス上の成果なのです。

どこをエッジに任せ、どこを既存の仕組みに残すべきか。課題を細かく分析して、最適な役割分担を設計することこそが、成果に繋がるエッジ開発の基本です。

まとめ

Cloudflare PagesやWorkersは、Webサイトのコンテンツ配信と動的処理をユーザーの最寄り拠点で完結させ、表示体験を劇的に引き上げる開発基盤です。

• 静的配信と動的処理の一元化： Workers Static Assetsにより、高速なコンテンツ配信と柔軟なプログラム実行をひとつのプラットフォームで実現
• 0.1秒の改善がCVRを変える： Deloitteの調査が示すように、わずかな待ち時間の削減が離脱を防ぎ、購入や問い合わせなどの事業成果に直結
• エッジA/Bテストと高速な制作サイクル： 画面のチラつきがないシームレスな出し分けや、Workers Previewsによる確認フローの迅速化で、施策のPDCAスピードを最大化

自社のWeb施策において、ユーザーが購入や問い合わせに至るまでのどこで待たされているのか、ボトルネックの分解から始めましょう。

覚えておきたい用語

• Cloudflare Pages： 静的サイトやフロントエンドをCloudflare上へ公開するサービス。現在も利用できるが、新規開発ではWorkersが推奨されている
• Cloudflare Workers： Cloudflareのグローバルネットワーク上でWebサイトやプログラムを実行する開発基盤
• Workers Static Assets： HTML、CSS、画像などの静的ファイルをWorkersと一緒に配信する仕組み
• エッジ： ユーザーに近い場所でデータ配信や処理を行うネットワーク拠点
• Core Web Vitals： Googleが定める、表示速度・操作性・表示の安定性を測るユーザー体験指標
• LCP： ページ内の主要コンテンツが表示されるまでの時間を測る指標
• INP： クリックなどの操作に対して画面が反応するまでの時間を測る指標
• CLS： ページ読み込み中のレイアウトのずれを測る指標
• A/Bテスト： 複数の表示パターンをユーザーに見せ、成果を比較する検証方法
• デプロイ： 作成したWebサイトやプログラムを実際に利用できる環境へ公開すること