ウェブサイトから統計を収集し、自分自身にぶつからないようにする方法

こんにちは、Habr！ 私の名前はSlava Volkovです。私はBadooのフロントエンド開発者です。 今日は、フロントエンドから統計を収集することについて少しお話ししたいと思います。

アナリティクスを使用すると、任意のWebサイトのパフォーマンスを評価し、その作業を改善できるため、売り上げを増やし、ユーザーのサイトとの対話を改善できることがわかっています。 簡単に言えば、分析は、Webサイトで行われるプロセスを制御する方法です。 ほとんどの場合、通常のサイトでは、GoogleアナリティクスまたはYandex.Metricaをインストールするだけで十分です。その機能は十分です。

しかし、標準の監視ツールでは不十分な場合はどうでしょうか？ または、収集された統計を独自の分析システムに統合して、異なるコンポーネント間で何が起こっているかを完全に把握する必要がある場合はどうでしょうか？ この場合、ほとんどの場合、システムを開発する必要があります。 しかし、ウェブサイトから統計を送信する最良の方法、どのような問題が発生する可能性があり、どのようにそれらを回避するかについては、この記事で説明します。 に興味がありますか？ 猫へようこそ。

Badooなどのサービスの場合、統計情報は、リソースの現在の状況、ユーザーのクリック、見たブロック、実行したアクション、サイトでの作業中のエラーなどを評価するための非常に重要な方法です。 この情報に基づいて、サイトを監視し、新しい機能の外観、ページ上のブロックの位置の変更、その他の変更が依存するかどうかを判断します。 したがって、非常に多様な統計を使用します。 このようなメッセージの流れに遭遇すると、どのような困難に直面するでしょうか？

発生する可能性のある最初の問題は、1つのドメインへの同時接続数に関するブラウザーの制限です。 たとえば、ページをロードするとき、4つのAjaxリクエストを実行してデータを取得し（フォント、SVGグラフィックスをダウンロード）、スタイルを動的にロードします。 その結果、ブラウザーが同時に実行する6つのリクエストを受け取ります（ 例番号1 ）（すべての例で、遅延を2秒に設定し、ネットワーク遅延を回避するためにマシン上で監視する方が良いです）。

function sendAjax(url, data) { return new Promise(function(resolve, reject) { var req = new XMLHttpRequest(); req.open('POST', url); req.onload = function() { if (req.readyState != 4) return; if (req.status == 200) { resolve(req.response); } else { reject(Error(req.statusText)); } }; req.onerror = function() { reject(Error("Network Error")); }; req.send(data); }); } function logIt(startDate, requestId, $appendContainer) { var endDate = new Date(); var text = 'Request #' + requestId + '. Execution time: ' + ((endDate - startDate) / 1000) + 's'; var $li = document.createElement('li'); $li.textContent = text; $appendContainer.appendChild($li); } document.querySelector('.js-ajax-requests').addEventListener('click', function(e) { e.preventDefault(); var $appendContainer = e.currentTarget.nextElementSibling; for (var i = 1; i <= 8; i++) { (function(i) { var startDate = new Date(); sendAjax(REQUEST_URL + '?t=' + Math.random()).then(function() { logIt(startDate, i, $appendContainer); }); })(i); } }); 

しかし、ログインしているユーザーに関する統計をさらに送信し始めるとどうなりますか？ この結果が得られます（ 例番号2 ）：

ご覧のとおり、統計を送信するための2つのリクエストはサイトの全体的な負荷に影響し、ページをレンダリングするためにこのデータが必要な場合、ユーザーは以前のリクエストの最速の実行時間に等しい遅延を経験します。

ほとんどの場合、統計からの応答を待つことは意味がありませんが、これらの要求は実行の全体的な流れに影響します。 そのような状況を避ける方法は？

データを送信する

すでにHTTP / 2を使用している場合、またはWebSocket接続を介してデータを転送している場合、この問題はまったく問題になりません。 しかし、まだではない場合は、おそらくHTTP / 2に切り替えるだけで役立ちます（そして、悪夢のようなものはすべて忘れてしまいます）。 幸いなことに、すべての最新のブラウザーはこれをサポートしており、このプロトコルのサポートは最も人気のあるWebサーバーですでに登場しています。 発生する可能性がある唯一の問題は、HTTP / 1.1に対して行ったすべてのハッキング、たとえばドメインシャーディング（不要なTCP接続を作成し、優先順位付けを妨げる）、JSおよびCSS連結、およびdataURI埋め込みイメージを削除する必要があることです。 さらに、HTTP / 2に切り替えると、サイト全体をHTTPSに転送する必要があります。これは、特にHTTP経由でサードパーティのリソースから大量のデータをダウンロードする場合、コストがかかる可能性があります。

WebSocket接続を使用すると、サーバーへの永続的な接続も取得され、リクエストの数に制限はありません。 このソリューションには何も問題はありませんが、ソケットサーバーを上げてシステムに接続する必要があるという点を除きます-開発者向けの追加作業。 しかし、最終的には、統計だけでなく、通常のリクエストもソケットを介して送信できます。 そして最も重要なこと-これにより、サーバーから通知を受信し、トラフィックを節約できます。

メソッド番号1

HTTP / 2に切り替える準備ができていないか、WebSocket接続を使用する準備ができていない場合、最も簡単な解決策は、統計情報を別のドメインにリクエストすることです。 その後、問題は消えます（ 例番号3 ）：

もちろん、CORS設定を忘れないでください。そうしないと、そのようなリクエストはブラウザによってブロックされます。

メソッド番号2

Fetch APIの機能を使用して、Cookieを渡さずに6つの追加リクエストを作成できます（ 例番号4 ）。 ただし、これは、リクエストの承認にクッキーが使用されていない場合にのみ役立ちます。 デフォルトでは、Fetchはそれらを渡しません。 これは実装のバグのように見えますが、この動作はChromeとFirefoxの両方で見られます。 バグ機能？ Cookieを送信するには、追加のパラメーターを設定する必要があります。

 fetch(REQUEST_URL + '?t=' + Math.random(), { method: 'POST', credentials: 'include' }).then(function () { // ... }); 

そこで、データをサーバーに転送する方法を決定しました。 ただし、ユーザーのアクションごとにリクエストを送信することはありません。 もちろん、イベントをバッファリングしてから、グループをサーバーに転送することをお勧めします。 ただし、この場合、ユーザーがページを離れると、蓄積されたバッファを失うリスクがあります。 そのような状況を避ける方法は？

バッファリング

デバウンス機能を使用してメッセージのバッファリングを整理できます。これにより、メッセージの送信間の遅延を整理できます。 この作業の小さな例をここで見ることができます （必要に応じて、送信されたデータのサイズまたはキューの最大存続期間を考慮してそれを補足できます）。

デバウンス遅延の使用に加えて、 window.requestIdleCallbackメソッドの使用例がありますが、残念ながら、すべてのブラウザでまだサポートされているわけではありません。 requestIdleCallbackメソッドは、ブラウザーがアイドル状態のときに実行される関数をキューに入れます 。 この機会は、たとえば統計の送信やページ上の遅延負荷要素のロードなど、バックグラウンドタスクを実行するのに適しています。 私の意見では、同期呼び出しを集約するのに適しています。 たとえば、この例を参照してください。

さらに、システムがいつ使用可能になるかを判断してからready（）メソッドを呼び出すと、残りの作業をブロックせずに統計がサーバーに送信され始めます。 そしてその前に、それは単にバッファに入るかもしれません。

イベント配信保証

残念ながら、バッファリングを使用すると、この状況が発生する可能性があります。ユーザーがタブを閉じたため、収集した統計は送信されず、失われません。 これは回避できます。 最初に頭に浮かぶのは、統計送信オブジェクトにforce（）メソッドを作成することです 。これはbeforeunloadのときに実行されます。 ただし、XHRリクエストを使用して統計を送信する場合、タブまたはブラウザーを閉じることも失敗します。

 window.addEventListener('beforeunload', sendData, false); function sendData() { var client = new XMLHttpRequest(); client.open("POST", "/server.php", false); client.send(data); } 

上記の例のように同期リクエストを送信することでこれを修正できます（ただし、これによりブラウザーでユーザーのアクションがブロックされます）、または特別なsendBeaconメソッドを使用して、少量のデータを非同期でサーバーに送信し、ページが閉じられた後でも配信を保証することができます この方法は、SafariとInternet Explorer（Edgeにサポートがあります）を除くすべての最新のブラウザーで機能するため、古い同期XHRを残しておく必要があります。 しかし、主なことは、メソッドが非常にコンパクトでシンプルに見えることです。

 window.addEventListener('beforeunload', sendData, false); function sendData() { var navigator = window.navigator; var url = "/server.php"; if (!navigator.sendBeacon || !navigator.sendBeacon(url, data)) { var t = new XMLHttpRequest(); t.open('POST', url, false); t.setRequestHeader('Content-Type', 'text/plain'); t.send(data); } } 

リクエストを確実に削除するには、Chrome DevToolsの[ネットワーク]タブを開き、[その他]タイプのリクエストでフィルタリングします。 すべてのsendBeaconリクエストがそこにあります。

残念ながら、sendBeaconにはいくつかの欠点があり、すべての送信要求を変換することができません。 まず、メソッドはドメインあたりの接続数の制限（ 例番号5 ）に該当するため、理論的には統計を送信するリクエストがデータを受信するための重要なリクエストをブロックする状況が発生する場合があります（ただし、例外：XHR-を使用する場合Cookieを渡さずに新しいFetch APIを要求すると、sendBeaconは接続制限（ 例番号9 ）に該当しなくなります）。 第二に、sendBeaconではリクエストのサイズに制限がある場合があります。 たとえば、以前のFirefoxおよびEdgeの最大リクエストサイズは64 KBでしたが、Firefoxのデータサイズの制限はなくなりました（ 例8 ）。 Chromeの最大データサイズ（バージョン57が現在関連）を見つけようとしたときに、sendBeaconに問題を引き起こし、統計情報を削除する非常に興味深いバグを見つけました。 例7を実行してページをリロードし、 例8の結果を確認してください。

Chromeでは、バッファーが64 KBに達するまで、残りの要求は送信できません。 バグはすでに修正されており、修正が次のバージョンに含まれることを期待しています。 その後、1つのリクエストの制限も64 KBのデータになります。

そのため、このメソッドを使用してさまざまなコンポーネントから多くの統計情報を取得すると、ほとんどの場合制限が発生します。 この制限を超えた場合、 navigator.sendBeacon()メソッドはfalseを返しfalse 。この場合、通常のXHRリクエストを使用し、ユーザーがページを離れる場合にのみnavigator.sendBeacon()を残すほうが適切です。 また、このメソッドは、インターネット接続が失われた場合にサーバーがデータを受信することを保証しません。そのため、データを送信するときは、 navigator.onLineプロパティを使用することをお勧めします。

原則として、ほとんどの場合、 後者のソリューションで十分と思われます。 別のドメイン（ 例6 ）に統計情報を送信する場合、特にデスクトップWebアプリケーションを検討している場合、一般的にソリューションはほぼ普遍的です。 接続が頻繁に失われるケースや、サーバーへのメッセージの配信を保証する必要があるケースがあるモバイルWebを考慮すると、このソリューションはもはや適切ではなく、通常のXHRリクエストを使用してその実行結果を確認することをお勧めします。

しかし、デスクトップWebとモバイルWebの両方に適合するユニバーサルソリューションはありますか？ 未来を見て、新しい実験技術に目を向けると、そのような機会が本当に存在します。

Service Workerとバックグラウンド同期

Service Workerのバックグラウンド同期は、 Background Sync APIまたは別の実装で定期的な同期として表されます 。 すでに検討した例を取り上げて、Service Workerの機能を使用して書き換えてみましょう。

このリンクで完成したテストケースを表示できます。 そして、ここにソースコードがあります 。

 Statistic.prototype._sendMessageToServiceWorker = function(message) { return new Promise(function(resolve, reject) { var messageChannel = new MessageChannel(); messageChannel.port1.onmessage = function(event) { if (event.data.error) { reject(event.data.error); } else { resolve(event.data); } }; navigator.serviceWorker.controller.postMessage(message, [messageChannel.port2]); }); }; Statistic.prototype._syncData = function() { return navigator.serviceWorker.ready.then(function(registration) { return registration.sync.register('oneTimeStatisticSync'); }); }; 

サービスワーカー：

 self.addEventListener('sync', function(event) { console.info('Sync event executed'); if (event.tag == "oneTimeStatisticSync") { event.waitUntil(sendStatistic()); } }); 

ご覧のとおり、今回はデータをService Workerに直接送信し、PostMessageを介してデータとやり取りしますが、同期のみを遅延させます。 サービスワーカーの大きな利点は、インターネット接続が突然失われた場合、データが表示された後にのみ自動的にデータを送信することです。 以下のビデオをご覧ください。 または自分でやろうとする。 インターネットをオフにして、上の例のリンクをクリックするだけです。 接続が確立された後にのみリクエストが送信されることがわかります。

手動同期に煩わされず、コードを少し簡素化するために、Service Workerで利用可能な定期的な同期を使用できます。 残念ながら、Chrome Canaryでも、これはまだ機能せず、どのように機能するかを推測することしかできません。 しかし、今では誰かがこのために親友を書いています：

 navigator.serviceWorker.register('service-worker.js') .then(function() { return navigator.serviceWorker.ready; }) .then(function(registration) { this.ready(); return registration; }.bind(this)) .then(function(registration) { if (registration.periodicSync) { registration.periodicSync.register({ tag: 'periodicStatisticSync', minPeriod: 1000 * 30, // 30sec powerState: 'auto', networkState: 'online' }); } }); 

定期的な同期の使用により、統計を送信できるだけでなく、アプリケーションが非アクティブのときに新しいデータをダウンロードすることもできます。 これは、たとえばニュースサイトの場合、1時間ごとに新しいデータをダウンロードするのに非常に便利です。 ただし、この機能はまだ利用できないため、定期的な同期とタイマーを使用する必要があります。

Service Workerを使用する場合の短所は、おそらくこの方法がすべてのブラウザーでまだサポートされていないという事実です。 さらに、その実装にはHTTPSプロトコルのみを使用する必要があります。ServiceWorkerはHTTPS経由で接続し、内部のすべてのフェッチ要求もこのプロトコルを使用する必要があります（例外はlocalhost ）。

おわりに

結論として、Webアプリケーションからのデータを監視および送信する機会がますます増えていることに注目したいと思います。Webはこの方向で非常によく発展しています。 したがって、既存のブラウザ機能を使用すると、Webリソースから統計を定性的に収集できます。 また、適切な収集と分析により収集した統計によって、サイトの作業とユーザーとの相互作用をよりよく理解できることを忘れないでください。

データの収集にご成功をお祈りします！