Shared Web Workersは、同じサイト（起点）の複数のページが単一のWebワーカーを共有できるように設計されています。共有Webワーカーは、単一のページリロードでリンクを維持し続けますか？
しかし、スペック（または他のチュートリアルや共有ワーカーの情報）から、サイトからのウィンドウ/タブが1つしかなく、同じワーカーの別のページに移動すると共有ワーカーが存続するかどうかはわかりませんサイト。
これは、サイトがナビゲートされるときに接続されている共有ワーカーからのWebSocket接続の場合に最も役立ちます。たとえば、サイトがナビゲートされている間でも（WebSocketに再接続することなく）存続する株式ティッカーやチャットエリアを想像してみてください。
私は実際にこれに対する答えを見つけるためにいくつかのテストを行っています。
FirefoxはWebワーカーからのWebSocket接続の作成をまだサポートしていません：https://bugzilla.mozilla.org/show_bug.cgi?id=504553 Firefoxはそのバグが解決されるまで関連性がありません。
IE 10にはsupport for Shared Web Workersが含まれていないため、関連性もありません。だからクロムは去る。
共有Webワーカーをテストする例です。
まずHTML：
<!DOCTYPE html>
<html>
<body>
<a href="shared.html">reload page</a>
<script>
var worker = new SharedWorker("shared.js");
worker.port.addEventListener("message", function(e) {
console.log("Got message: " + e.data);
}, false);
worker.port.start();
worker.port.postMessage("start");
</script>
</body>
</html>
そしてshared.jsで共有ワーカー自身の実装：クロム20で
var connections = 0;
self.addEventListener("connect", function(e) {
var port = e.ports[0];
connections ++;
port.addEventListener("message", function(e) {
if (e.data === "start") {
var ws = new WebSocket("ws://localhost:6080");
port.postMessage("started connection: " + connections);
}
}, false);
port.start();
}, false);
試験結果（答え）：
ページは2つの別々のタブに同時にロードされ、接続数はページの1つごとに増加しますまたは自己参照のリンクがクリックされた場合
ページのインスタンスが1つだけロードされている場合、ページがリロードされるかリンクがクリックされたときに接続カウントが変更されることはありません。
Chromeの場合20：共有Webワーカーは、ページの再読み込みとリンクのナビゲーションのクリックで持続しません。
+1実験用 – stimms
ページをリロードしたり、新しいページを開くと、SharedWorkerが再作成されますか？私はconsole.log（新しいDate（）。getTime（））を書く。そして、ページリロードの後、コンソールでは常に異なる時刻が表示されます。したがって、ページのリロード後に常に新しいWebSocketインスタンスが作成されました。 –
これは基本的にthe question 'What happens to an HTML5 web worker thread when the tab is closed while it's running?'と同じ問題だと思われます。私は、仕様の重要な部分がthis statementだと思う：
ユーザーエージェントは、例えば任意の時点で 労働者の「労働者を殺す」処理モデルを呼び出すことができますユーザーの要求に応じて、 CPU割り当て管理に応答して、または閉鎖フラグ がtrueに設定された後であってもワーカーが実行を継続している場合に、ワーカーがアクティブな必要なユーザーであることを停止したとき。
労働者は労働者のドキュメントのドキュメントの任意の オブジェクトが完全にアクティブである場合にアクティブに必要な労働者であると言われて、次のよう
アン「active needed workerは」が定義されています。
私が理解しているように、ワーカーを参照するすべてのウィンドウが閉じられている場合、ブラウザはワーカーを終了させるために仕様によって必要ですが、直ちに終了する必要はありません。それに応じて、時折動作するように見えても、持続性は信頼できません。
あなたの例では、Ajaxでサイト全体を読み込む方法があります。ユーザーがJSを無効にしている場合はWeb Workersを実行できないようにしてから、History APIを使用してユーザーのページアドレスを作成します実際のページに対応しています（検索エンジンと非JS互換性を維持します）。
私の質問は、同じサイト*（または同じサイトのリロード）上のあるページから別のページへの遷移（リンククリック）が、ワーカーを非アクティブなそれが殺される原因になるかどうかを判断する必要があります。言い換えれば、アクティブからアクティブに移行するのか、それとも次のページがロードされる前に非アクティブに移行するのですか？これは、実際にブラウザが何をしているのか、その意図が何であるかということに関する質問です。スペックの言葉自体はあいまいで、私はそれを求めています。 – kanaka
@ kanakaはい、ページをアンロードすると、ページをアンロードして殺すべき状態になります（[手順5]を参照してください（http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html）。 ＃run-a-worker））が、この仕様ではすぐに強制終了される必要はありません。私が言ったように、それは時々動作するかもしれませんが、それが信頼できると期待していません。ブラウザが実際に何をしているのか知りたければ、試してみてください。 – robertc
私は次のページに移動したいが、SharedWorkerを維持するために、同じ作業者を作成する（邪魔にならない）ポップアップウィンドウを開いて、アクティブになるのを待つ元のポート/ウィンドウにメッセージを送信してから、新しいページに移動し、そのページが読み込まれるとポップアップを閉じます。この戦略では、少なくとも1つのアクティブな接続が常に維持されるため、ワーカーは決してシャットダウンを決断しません。
この手法はこれまでのところかなり堅牢なようです。ポップアップがいくらか迷惑行為をするのを見ても、ユースケースによっては合理的な妥協案です。
あなたの事例を教えてもらえますか？私はいつもページをリロードした後でも新しいものを作成しています。 –
現在、ストレージイベントはその共有労働者のための最良の選択肢です。 http://stackoverflow.com/questions/19125823/how-is-it-possible-to-share-single-js-resource - between-browser-tabs/19165781＃19165781 – inf3rno