ウェブサイトのパフォーマンス低下やネットワーク転送量の増加にお悩みですか?その原因がCookieにあるなら、効果的な解決策の1つにCookieフリードメインの利用が挙げられます。

Cookieは、オンライン体験の向上に役立ちますが、その名前から連想されるような「甘い」ものとは一概には言えません。サードパーティCookieに関連するプライバシーやセキュリティの懸念に加え、サイトの画像や他の静的コンテンツに自動的に付加されることで、パフォーマンスに深刻な影響を与える可能性があります。

Cookieフリードメインを使用すれば、そんな従来のCookieともお別れ可能に。この記事では、Cookieフリードメインの基礎と有用性、そしてWordPressサイトでの使用方法をご説明します。

まずは、「クッキー缶」の中を覗いて、ドメインとCookieの関係性、そしてメリットとデメリットを見ていきましょう。

Cookieフリードメインの基礎

Cookieフリードメインは通常、サイト訪問者のブラウザへのCookie送信を行わない(その必要のない)特定のアセット配信に使用します。

しかし、なぜCookieにそのような制限をかけなければいけないのでしょうか。訪問者にメリットのあるCookieは、できる限り送信するほうがいいのでは?

実は、必ずしもそうとは限りません。Cookieフリードメインの「Cookie」は、もちろんHTTP Cookieを意味します。HTTP Cookieは、皆が大好きな焼き菓子のクッキーとは異なり、ウェブサイトから訪問者のブラウザに送信される小さなデータパケットです。ウェブサイトが次回訪問時までにユーザーを「記憶」します。

ただし、焼き菓子のクッキー同様、あまりに大量に送られると厄介に感じるもの。これから詳しくご紹介していきますが、Cookieはほどほどに送信するのがベストプラクティスです。必要以上に送信すると、サイトのパフォーマンスに悪影響を与える恐れがあります。

HTTP Cookieの基礎

HTTP Cookieは、ウェブ上のあらゆる場所に存在します。

訪問者がウェブサイトにアクセスすると、ほとんどのウェブサイトはブラウザにCookieを保存するよう要求します。Cookieには、ウェブサイトや閲覧したページに関する情報に加えて、訪問者と訪問者のブラウザに結びついた個人識別子が含まれます。この識別子によって、ウェブサイトは訪問者が過去にそのページを訪れたかどうかを記憶します。

このCookieの仕組みを図で表すと、以下のようになります。

ウェブサイトからウェブブラウザへのHTTP Cookieの送信方法
ウェブサイトからウェブブラウザへのHTTP Cookieの送信方法

上の図からもわかるように、Cookieは以下3つのステップで送信されます。

  1. ブラウザがウェブページをリクエスト─訪問者がブラウザのアドレスバーにアドレス(たとえば、「kinsta.com」のようなドメインのURL)を入力するかリンクをクリックすると、ブラウザはHTTPリクエストを生成し、ウェブサイトに対してそのページを要求します。このリクエストは、ウェブサイトとページをホストしているウェブサーバーに送信されます。
  2. ウェブサーバーがページとCookieを送信する─リクエストを受けたウェブサーバーは、要求されたページと、特定の情報を含むCookieを送り返します。前述したように、このCookieに、訪問者とブラウザの個人識別子が含まれるのが通例です。
  3. ブラウザが同じサーバーに別のページをリクエスト─ここでは訪問者がウェブサイト上の別のページ、例えばECサイトの商品一覧ページや、会社概要ページへのリンクをクリックしたとします。ブラウザは、この別のリクエストと最初に渡されたCookieをウェブサーバーに送信します。ウェブサーバーはリクエストを受け取ると、過去に送信したCookieを確認し、訪問者が過去に訪問していることを記憶します。この情報をもとにログインの状態、ショッピングカート内のアイテムを保持することで、顧客体験が向上します。

また、目的の異なるCookieもあります。上の例では、セッションを管理するウェブサーバーは、ユーザーのログイン状態やカート内の商品、つまりウェブサイト上のセッションの維持にCookieを使用しています。また同様に、最近の注文や閲覧した商品の表示からターゲット広告の設定まで、パーソナライズされた体験の実現にも使用されます。

クッキーはいつもらっても嬉しいものですが、Cookieの場合はそうとは限りません。次のセクションでご説明しますが、ウェブサイトはCookieを好きなだけ送信することができますが、その中には多くの人が「食べたくない」ものも。

HTTP Cookieの用途

HTTP Cookieの重要な用途の一つが個人の識別ですが、他にもパーソナライズされたウェブ体験の実現、ターゲットコンテンツの配信など、様々な目的に使用されます。

中にはプライバシーを侵害するCookieもある
中にはプライバシーを侵害するCookieもある

ウェブサイトとブラウザ間で、HTTP Cookieが訪問者を記憶する仕組みについてはすでにご説明しました。Cookieはログインセッションやカート内の商品の維持に有用ですが、一方で悪意のある(あるいは明らかに迷惑な)目的でも使用されます。

HTTP Cookieを使用する目的には、以下のようなものがあります。

  • セッション管理─これについてはすでにご説明しましたが、セッション管理は、基本的にはユーザーにとって最もメリットのある使用方法と言われています。ユーザーが同じ操作を繰り返さなくてもよくなり、ひいてはユーザー体験の向上につながるためです。以前の操作が記録されることには、プライバシーの懸念があるかもしれませんが、そこまで有害になることはありません。真のプライバシーの問題は、後述するトラッキングCookieにあります。
  • パーソナライゼーション─セッション管理は、訪問者の好みや行動に基づいたウェブページのパーソナライズにも使用できます。例えば、訪問者が好きな言語を選択すると、次回の訪問以降では、選択した言語でウェブサイトを閲覧することができます。また、ウェブサイトは、Cookieを使用して異なるウェブブラウザの特定の要件にも対応できます。
  • トラッキング─Cookieには賛否両論な一面も。ブラウザにはウェブサイトから送信されたCookieが保存されるため、このCookieは、訪問者をウェブ上で追跡する目的に使用されることがあります。例えば、ウェブサイトの中には、訪問者のブラウザにトラッキングCookieを送信し、ウェブ上のアフィリエイト広告主にページへのアクセスを通知するものがあります。さらに、ターゲット広告の表示だけでなく、サイバー攻撃の手段としても利用できてしまいます。トラッキングCookieは、いかなる目的であってもユーザーを「追跡」することには変わりなく、多くの倫理的問題やプライバシーの侵害に関する懸念が拭えません。

ほとんどのHTTP Cookieは、セッション管理とパーソナライゼーションに使用されますが、無害なCookieでさえも時に問題を引き起こすことがあります。

これまでは、1つのページが1つのCookieを送信するという想定で見てきました。しかし実際には、1つのページから複数のCookieが送信されており、HTMLや画像ファイルなど、ページの各要素ごとに、Cookieが送られることがほとんどです。その一部は、セッション管理やパーソナライゼーションに必要になりますが、ほとんどは不要なものです。

結果として、過剰にCookieが送信され、さまざまな問題を引き起こす可能性があります。続いては、このような問題について見ていきましょう。

Cookieの過剰使用

一般的なドキュメントとは異なり、ウェブページは、形や構造、意味を与えられた様々な要素の集合体です。要素には、それぞれ独自のCookieを設定できます。

.pdfや.docx形式の通常のドキュメントは、テキストと画像の単一の「組み合わせ」に見えますが、ウェブページは、多くの小さな部品で構築されています。

HTML、CSS、JavaScriptはウェブサイトの基本コンポーネント
HTML、CSS、JavaScriptはウェブサイトの基本コンポーネント

例えばウェブページのリクエストでは、実際には、HTML(構造)、CSS(スタイルと形式)、JavaScript(インタラクティブ機能)、画像を始めとするメディアなど、個別のページ構成要素を要求しています。ブラウザは、ウェブページを受信すると、この構成要素を受信して再結合し、画面上に完全なページを表示します。

ウェブサーバーがCookieも送信する場合は、すべての要素ごとに自動的に送信されることになります。画像が数枚だけのシンプルなウェブページではあまり問題になりませんが、数十、数百のコンポーネントで構成されるページなら大変です。

焼き菓子のクッキーの食べ過ぎと同じように、大量のHTTP Cookieの送受信は、「パフォーマンス」の低下につながります。必要以上のデータの送信には、当然必要以上の時間とリソースが求められるもの。すべての要素にCookieを送信すると、十分に確保されたネットワークリソースをいとも簡単に消費し尽くしてしまいます。

ドメインのダイエット─Cookieフリーへの道

このような大量のCookie送信問題を解決し、パフォーマンスを向上するには、単にCookieの数を減らせばOKです。

しかし、どのCookieを除外すればよいのでしょうか。基本的には、ページ上の静的要素のCookieを削除するのがベストプラクティスです。

静的な要素とは、訪問者の行動で変化することがない画像やCSSファイルのような、静的ファイルを指します。こうした要素にCookieは不要であり、削除することで、ネットワークの負荷を軽減し、パフォーマンスを向上することができます。

Cookieの削除は、チェックボックスの選択を外すだけのような簡単な操作では実行できません。

実際のところ、ウェブサーバーは、Cookieありのコンテンツとは別に、Cookieフリードメインを使用してCookieなしの静的コンテンツを送信しています。Cookieフリードメインは通常、別個のドメインになります(「static.kinsta.com」や「kinsta.com」のようなサブドメインFQDNなど)。

サブドメインを示すURLの構造
サブドメインを示すURLの構造

Cookieフリードメインの使用は、ツールを使用すればそれほど難しくありません。また、サブドメインの設定以外にも方法があります。

Cookieフリードメインを設定する前に、まずはCookieフリードメインのメリットとサイト(および予算)への影響を見ていきましょう。

Cookieフリードメインのメリット

余分なCookieの削除は、一見取るに足らない解決策に思えます。確かにその通りです。

とは言え、この取るに足らない解決策には大きなメリットがあります。ネットワークのデータ転送量が少なくなるだけでなく、以下に挙げるような多くの利点があります。中には、パフォーマンス改善以外のメリットも。

不要なデータ転送量の削減

Cookieフリードメインを使用する主なメリットは、不要なCookieの転送を止めることで、ネットワーク負荷が低減することにあります。

先に触れた通り、ページの要素を訪問者に送信するには、ある程度のネットワークリソースが必要です。この送信には、要素そのもの(あるいは、同じ要素の複数の部品)に加えて、ルーティング情報を含むレスポンスヘッダーなども含まれます。

Cookieは比較的小さなデータファイルですが、すべてのページリクエストごとに複数のCookieを送信すれば、すぐに肥大化してしまいます。結果、ページの読み込み速度が下がり、性能の低いウェブサーバーには大きな負荷がかかります(ひいては、予算を超えてしまうことに)。

しかし、Cookieフリードメインを使用すれば、不要なCookieによる負担を大幅に減らすことができます。

パフォーマンスの改善

ご想像のとおり、不要なCookieを除外することによるネットワーク負荷の軽減は、読み込み時間やウェブサイトのパフォーマンスを大きく改善します。

ページでのクリックごとにウェブサーバーに個別のリクエストが発生するため、基本的なナビゲーション(「トップページ」>「会社案内」>「ショップ」ページへの移動など)を実行するだけでも、ページの表示に時間がかかります。ページの要素やCookieは、キャッシュされ、2度目以降の読み込み時に再利用されますが、ページを変更したり、ウェブサイト内を移動すれば、問題が生じる可能性があります。

SEOとユーザー体験の向上

不要な転送を減らしてウェブサイトのパフォーマンスが向上すれば、検索エンジン最適化(SEO)はもちろん、ユーザー体験にもメリットをもたらします。

表示速度が高速化されれば、訪問者は目的のコンテンツをすぐに閲覧することができます。その結果、訪問者がウェブサイト(および製品やサービス)に滞在する時間が長くなる可能性が高くなり、クリックなどの操作でイライラする可能性は低くなります。

また、SEOにも効果的です。ページの読み込み時間はSEOに直接影響しませんが、直帰率(最初にアクセスページからどこにも移動せずに離脱した訪問者の割合)には確実に影響します。

ページの読み込み速度
ページの読み込み速度

Unbounceのレポートによると、ユーザーの4分の3は、ページの読み込みに4秒以上かかるとそのページから離脱すると回答しています。

つまり、不要なCookieを削除して読み込み時間をたった1秒短縮するだけでも、直帰率は大幅に減少し、検索順位の上昇も期待できます。

サーバー費用の削減

ネットワークの転送量は、最終的にサーバーの利用料金に影響します。

必要以上のCookieを送信すれば、必要以上のサーバー費用が発生することを意味します。もしCookieがパフォーマンスに悪影響を及ぼしているなら、ダメージ倍増。過剰なデータ転送量の料金を支払うだけでなく、表示速度の低下が原因の直帰率上昇への対策として、さらに料金を支払わなければならなくなります。

KinstaのWordPress専用マネージドホスティングのようなサービスを利用すれば、上記のような心配も解消されます。KinstaのAPMツールやその他の機能を使って、WordPressサイトを最適化することができます。

Cookieレス時代への備え

Cookieフリーのコンテンツの配信は、現時点ではまだ明らかなメリットとは言えないかもしれませんが、Cookieレス時代に向けた備えになります。

GDPRなどのプライバシーポリシーを受け、Cookie規制論争が高まる中、多くの大手検索エンジンやIT企業が、Cookieを完全に廃止する方法を模索しています。Cookieの完全廃止までには、おそらくまだ時間がかかりますが、いずれ実現する可能性は非常に高いことが見込まれます。備えあれば憂いなし。いずれCookieレス時代を迎えても、簡単に適応することができます。

Cookieフリードメインの使用方法

先でも触れましたが、Cookieフリードメインの一般的な考え方は、Cookieなしで静的コンテンツを配信すること。最も簡単な方法は、別のドメインやサブドメインの作成ですが、CDNといくつかのWordPressの小技を使って実行することも可能です。

個別のCookieフリードメインの作成

この方法では、個別のドメインを作成して、画像やCSSなどの静的要素を管理します。

まったく別のドメインも登録できますが、通常は、既存のドメインのサブドメインを作成する方が簡単で費用対効果も上がります。ほとんどのCookieフリードメインで、サブドメインとして接頭辞「static」(静的)が使用されています(例:「static.yourdomain.com」)。

注意)この方法は、ドメインのwwwバージョン(例:「www.yourdomain.com」)が、ウェブサイトのルートファイルのルートドメインである場合にのみ有効です。

サブドメインをCookieレスにするには、通常特別なコードを使用して、直接.htaccessファイルを編集する必要があります。しかし、後ほどご紹介するように、WordPressサイトを再構成するか、プラグインを使用した方がはるかに簡単です。

なおCookieフリーサブドメインを設定しても、CSS、画像、テキスト、JavaScriptなどの静的要素はアップロード可能です。

コンテンツデリバリネットワーク(CDN)の使用

コンテンツデリバリネットワーク(CDN)を使用すると、Cookieフリードメインの利用が非常に簡単です。

個別のサブドメインの作成や設定ファイルの編集は必要なく、静的要素のレスポンスヘッダーから、Cookieを無視して除外するようにCDNに指示するだけでOKです。少し複雑に聞こえるかもしれませんが、CDNに一般的に搭載されている機能です。

ただし、すべてのCDNにこの機能があるわけではありません。そのため、Cookieを無効化できるCDNを使用している場合を除き、基本的にはウェブサイトの設定を変更する方が得策です。

WordPressサイトの再構成

WordPressサイトなら、wp-config.phpファイルの2行を更新するだけで、Cookieフリードメインを指定することができます。詳しい手順については、次の「Cookieフリードメインを使用するWordPressの構成方法」に進んでください。

WordPressプラグインの使用

WordPressサイトでのもう一つの簡単な方法は、プラグインを使ってWordPressサイトを静的化することです。

WP2Staticプラグインは、「WordPress-to-Static」の文字通り、WordPressサイトを静的化する人気プラグインです。プラグインをインストールした後、WordPressの管理画面でウェブサイトを静的サイトとしてエクスポートするための設定を行います。

WP2Static
WP2Static

Cookieフリードメインを使用するWordPressの構成方法

前述したように、WordPressサイトの場合は、Cookieフリードメインを実装する簡単な方法があります。手順は、大きく分けて以下の3ステップです。

  1. 代替サブドメインとそれに紐付くDNSを作成
  2. WordPressに静的アセットを送信するドメインを設定
  3. 既存のWordPressデータベースレコードを更新して、新しいアドレスを反映

Kinstaのお客様であれば、一部の手順はMyKinstaで実行可能です。Kinstaをご利用でない場合は、cPanelで実行できます。

以下、それぞれの手順をご説明していきます。

MyKinstaでCookieフリードメインを設定する方法

Kinstaでは、MyKinsta内でサブドメイン(または異なるドメイン)をWordPressサイトに紐付けることができます。また、MyKinstaの機能を使用して、ドメインのDNSを構成することも可能です。

例として、すでに稼働中のウェブサイト「www.example.com」を使って、Cookieフリードメイン「static.example.com」を作成していきます。

ステップ1. MyKinstaでのサブドメインの作成

KinstaでWordPressサイトを構築した際、ドメインにワイルドカード(例:「*.example.com」)を使用していれば、すでに任意のサブドメインをサポートしています。そうでなければ、以下の手順で追加してください。

  • 左側のメニューから「WordPressサイト」を選択
  • WordPressのサイト名をクリック
  • 左側のメニューから「ドメイン」を選択
  • ドメインを追加」ボタンをクリック
MyKinstaでサブドメインを追加
MyKinstaでサブドメインを追加

「ドメインの追加」画面で

  • Cookieフリードメインの名前を入力
  • ドメインの追加」ボタンをクリック
MyKinstaでサブドメインを指定
MyKinstaでサブドメインを指定

次に、静的ドメイン用に既存のウェブサイトに紐付けるDNSレコードを作成します。サードパーティのサービスを利用してドメインのDNS管理しているなら、専用のツールを使って適宜紐付けを行ってください。KinstaでDNSを管理している場合は、以下の手順で実行します。

  • 左側のメニューから「DNS」を選択
  • DNSマネジメント」画面をスクロールダウンし、「DNSレコードを追加する」ボタンをクリック

なお、サブドメインは、CNAMEレコードとしてDNSに追加することをお勧めします。IPアドレスとの紐付けは、セカンドレベルドメインのみに依存します。以下では、「example.com」と紐付けられた「static」のCNAMEレコードを追加しています。

MyKinstaでCNAMEレコードを作成
MyKinstaでCNAMEレコードを作成

ステップ2. 静的サブドメインでのCookieの無効化

WordPressサイトのwp-config.phpファイルを編集して、wp-contentフォルダ内のアセットは「static」ドメインから、そして、Cookieは「www」アドレスを介してのみ配信されるようにします。

Kinstaをご利用の場合は、FTP/SFTPクライアントを使用してWordPressサイトにログインし、wp-config.phpをPCにダウンロードして編集していきます。

wp-config.phpファイルをPCにダウンロード
wp-config.phpファイルをPCにダウンロード

テキストエディターを使用して、wp-config.phpファイルに以下の行を貼り付けます(ドメインは自分のものに置き換えます)。

define("WP_CONTENT_URL", "https://static.example.com/wp-content");
define("COOKIE_DOMAIN", "www.example.com");

ファイルの保存後、WordPressサイトにアップロードして、以前のバージョンを上書きします。

ステップ3. 既存のアセットをサブドメインにリダイレクト

この時点で、ブラウザが「www」アドレスからページやブログ記事などのコンテンツを読み込むとCookieが送信されますが、メディアやテーマ内のJavaScript、CSS、フォントなどのアセットは「static」ドメインから配信されます。

しかし、ウェブサイトには、すでにアセットへのリンクを「www」アドレスとしているコンテンツがあるかもしれません。これは、WordPressのデータベース内の検索と置換で解決できます。

データベースで作業する前に、必ずWordPressサイトをバックアップしてください。その後、以下の手順で実行していきます。

  • MyKinstaの左側のメニューから「WordPressサイト」を選択
  • WordPressのサイト名をクリック
  • 左側のメニューから「ドメイン」を選択
  • サイト情報」画面の「データベースへのアクセス」セクションまでスクロール(、データベースのユーザー名とパスワードの情報はここで確認可能)。
  • phpMyAdminを開く」をクリック
  • WordPressデータベースにログイン
  • SQL」タブを開く
WordPressコンテンツ内のアセットのリンクを更新するSQLクエリを実行
WordPressコンテンツ内のアセットのリンクを更新するSQLクエリを実行

以下のコマンドを実行して、既存の投稿内のアセットのリンクがCookieフリーサブドメインに紐付いていることを確認してください(ここでも、ドメインも置き換えをお忘れなく)。

UPDATE wp_posts SET post_content = REPLACE(post_content, 'www.example.com/wp-content/', ' static.example.com/wp-content/')

以上で、WordPressサイトへのCookieフリードメインの設定が完了です。このCookieフリードメインは、WordPressのCookieを送信したくない、静的コンテンツの管理に使用され、他すべてのコンテンツには通常のドメインが使用されます。

cPanelでCookieフリードメインを設定する方法

次に、上でご紹介した手順を、cPanel(またはcPanelの代替ツール)で実行する方法を見ていきます。

ステップ1. cPanelでのサブドメインの作成

cPanelメインページの「ドメイン」セクションに移動します。「サブドメイン」で、WordPressサイトのトップレベルドメインと紐付いたサブドメインを作成します。

以下は、サブドメイン「static.example.com」の作成例です。

cPanelでサブドメインを作成
cPanelでサブドメインを作成

ステップ2. cPanelでの静的サブドメインの構成

サブドメインを作成したら、WordPressサイトの静的コンテンツがこのサブドメインで配信されるように設定します。

これを行うには、WordPressサイトのwp-config.phpファイルを編集します。cPanelのファイルマネージャーから開くのが1番簡単です。

ファイルマネージャーで、ウェブサイトのpublic_htmlフォルダに移動し、① wp-config.phpを選択します。次に、②「Edit」をクリックして、ファイルを編集します。

wp-config.phpファイルの編集
wp-config.phpファイルの編集

wp-config.phpファイルに、以下の行を貼り付けてください(ドメインは自分のものに置き換えます)。

define("WP_CONTENT_URL", "https://static.example.com/wp-content");
define("COOKIE_DOMAIN", "www.example.com");

Save Changes」をクリックして変更を保存します。

ステップ3. 既存のアセットをサブドメインにリダイレクト

最後に、既存のアセットを作成したサブドメインにリダイレクトします。なお、実行する前に、万が一に備えて、WordPressサイトをバックアップしてください。

次にcPanelの「データベース」セクションで、phpMyAdminを開きます。サイトのデータベースをクリックし、_postsテーブルを選択します。

_postsテーブルの「SQL」タブをクリックします。以下のコマンドを実行して、アセットのURLがCookieフリーサブドメインに紐付いていることを確認します(ここでもドメインの置き換えをお忘れなく)。

UPDATE wp_posts SET post_content = REPLACE(post_content, 'www.example.com/wp-content/', ' static.example.com/wp-content/')
既存のアセットをサブドメインにリダイレクト
既存のアセットをサブドメインにリダイレクト

以上で、WordPressサイトのCookieフリードメインの設定が完了です。画像、CSS、JavaScript、フォントなどの静的コンテンツは、Cookieフリードメインから配信され、Cookieはサイトのプライマリドメインで配信されます。

まとめ

Cookieフリードメインを導入することで、サイトパフォーマンスの向上やサーバー費用の削減、さらには顧客体験やSEOの強化につながります。

今回ご紹介したように、WordPressサイトでCookieフリードメインを設定することには、多くのメリットがあります。KinstaのようなWordPress専用マネージドホスティングを利用すれば、このメリットをすべて活用することができます。

Set-Cookieヘッダーを削除したり、データベースに直接接続して、アセットをサブドメインにリダイレクトしたりできることから、Cookieフリードメインの使用が簡単です。KinstaのAPMツールやその他のパフォーマンス監視機能を使用すれば、変更した後の結果も追跡できます。

Kinstaのプレミアムホスティングサービスにご興味がございましたら、こちらのページからお問い合わせいただくか、見本紹介セッションをご予約ください。

Jeremy Holcombe Kinsta

Content & Marketing Editor at Kinsta, WordPress Web Developer, and Content Writer. Outside of all things WordPress, I enjoy the beach, golf, and movies. I also have tall people problems ;).