PING の読み方はさておき



(Katherine McGovern / Shutterstock.com)

こんにちは、中山です(写真は PINGU のモデルです)。
今回は HTML Living Standard で策定された A 要素の PING 属性についてのお話です。

PING 属性を持つリンクをクリック(タップ)すると、属性値に指定した URL へ POST リクエストが送信されます。
この機能を利用することでイベント発生のトラッキングが可能になります。
2013 年の記事 によれば Google のモバイル検索では PING 属性の導入が 200~400 ms の速度改善に寄与したそうです。

Google mobile search is getting faster - to be exact, 200-400 milliseconds faster! We are gradually rolling out this improvement to all browsers that support the <a ping> attribute (currently, mobile Chrome and Safari).

この改善は、従来のリダイレクタを経由したページ遷移

に対して

のように、トラッキング処理をバックグラウンドで実施したことによる効果です。

ブラウザ設定

では PING 属性を利用し、各種スキームのトラッキング等について確認してみましょう。
先立って、ブラウザ設定を変更します。

Chrome(63.0.3239.132)ではデフォルトで有効になっています。
Firefox(58.0)で利用する場合は about:config で send_pings を有効にします。

二番目の send_pings.max_per_link は同時送信可能な POST 先 URL 数(PING 属性には スペース区切りで複数 の URL を指定可能)です。

The ping attribute, if present, gives the URLs of the resources that are interested in being notified if the user follows the hyperlink. The value must be a set of space-separated tokens, each of which must be a valid non-empty URL whose scheme is an HTTP(S) scheme. The value is used by the user agent for hyperlink auditing.

Ping-To Request Header

Chrome で各種 HREF 属性値毎に、送信される Ping-To Header を確認してみます。

1. http: スキーム(フラグメント付き)

2. mailto: スキーム

3. tel: スキーム

4. javascript: スキーム

結果 1. ~ 4. の通り、もれなく HREF 属性値が Ping-To として送信されています。
フラグメント情報(ex. ハッシュタグ)の取得を含め、様々なトラッキング用途に利用できそうですね。

Set-Cookie Response Header

以前 マーケターの危機? ITP 時代にアドレサブル広告を活用すべき理由 にも記載しましたが、リダイレクタは Set-Cookie 処理を実行する場合があります。

しかし PING 要素のようにトラッキング処理をバックグラウンドで実施した場合、赤い点線部分の HTTP Response Header による Set-Cookie 処理は可能でしょうか !?

結論から述べると可能です。
ただし PING の送信先が閲覧中のサービスと異なるドメイン(3rd-party Cookie)の場合、Set-Cookie の成否は ブラウザ設定 に従います。

リダイレクタの場合 1st-party として Set-Cookie 処理を実行できる(ITP の影響はここでは無視します)ため、PING 属性はリダイレクタを完全に置き換える手段とは言えませんね。

速度改善テスト + まとめ

最後に sleep 処理(= Response を一定時間ブロック)を入れたリダイレクタ経由のページ遷移時間と、トラッキング処理を PING 属性で代替した場合のページ遷移所要時間について確認してみます。

遷移所要時間は LP 側で Navigation timing API を用いて取得した時間を可視化してみました。
(補足すると、テスト環境は localhost に構築したため sleep 以外はほとんど時間がかかっていません)

1.1. リダイレクタ(10ms sleep)経由

1.2. リダイレクタ(50ms sleep)経由

1.3. リダイレクタ(100ms sleep)経由

1.4. リダイレクタ(500ms sleep)経由

2.1. PING を「リダイレクタ(10ms sleep)」に送信

2.2. PING を「リダイレクタ(50ms sleep)」に送信

2.3. PING を「リダイレクタ(100ms sleep)」に送信

2.4. PING を「リダイレクタ(500ms sleep)」に送信

テスト結果から PING 属性を用いることで sleep 処理の影響を受けないことが確認できました。
以下、今回のまとめ(+ α)です。

  • 様々なスキームのトラッキングが可能
  • Set-Cookie 観点では完全な置き換えにはならない
  • リダイレクタ経由の場合と比較してページ遷移速度改善
    (+ リダイレクタのトラブルによるページ遷移(が出来ない)事故を防止)

未対応ブラウザの考慮が難儀ですが、導入のメリットは十分にありそうですね !!

(2/10 追記)

同様にトラッキングの文脈で、従来ピクセルや XMLHttpRequest を用いて実現していたデータ送信を、処理コストや実行担保観点で最適化してくれる navigator.sendBeacon() についても、別の機会に記事にしたいと思います。


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です