通常のリロードでは、キャッシュされたアセットが再利用される場合があります。ハード リフレッシュでは、Chrome にそのロードのキャッシュをバイパスするよう要求します。
スケジュールされたタブは、ネットワークが正常であっても「スタック」しているように見えることがよくあります。Service Worker シェル、アグレッシブな CDN、または長期間有効な SPA キャッシュにより、昨日の UI が保持されることがあります。 Auto Refresh Turbo は、通常どおり、またはキャッシュ バイパスを使用してリロードできます。どちらのモードも、単独では Cookie をクリアしません。
通常のリロード
ほとんどの場合、通常の tabs.reload が更新の意味です。 Chrome は、キャッシュ ルールに従って、キャッシュされたスクリプト、スタイル、および一部のドキュメント応答を提供する場合があります。多くのダッシュボードではこれで十分です。データ エンドポイントは新しい JSON を返し、ページには新しい数値が描画されます。
次の場合は通常のリロードを優先します。
- ボードは手動更新できれいに更新されます
- 頻繁にリロードするため、オリジンの負荷を低くしたい
- ハード リフレッシュにより、以前にログアウトされたか、必要なクライアント状態がリセットされました
ハード リフレッシュ (キャッシュ バイパス)
キャッシュ バイパスを使用してハード リフレッシュがリロードされます。通常のリロードでシェルが古いままになる場合、つまりタイルがフリーズしたり、古いビルド バナーが残ったり、DevTools で手動でハード リフレッシュを行わないと回復しない UI が残っている場合に使用します。
重要な制限:
- Cookie をクリアしたり、ログインを消去したりしません
- オリジンへのトラフィックが増加する可能性があります
- 一部のサイトでは、独自の Service Worker が制御を取り戻した場合でも回復が遅い
スケジュールされたタブの選択
<オル>壁のセットアップについては、ダッシュボードの更新をご覧ください。
スケジュール、ランダム、N 後に停止
ハード リフレッシュはセッションごとのオプションです。固定またはランダムな間隔、毎日のウィンドウ、およびN後の停止で機能します。スケジュール ウィンドウの外では、セッションはウィンドウが再び開くまで、ハード リフレッシュ フラグを含む設定が保存された状態で一時停止します。
インタラクションとチャレンジの停止
クリック/タイプ時の停止と疑わしいページの停止は引き続き適用されます。編集中のハードリフレッシュは、通常のリフレッシュと同様に中断を伴います。タブが入力にも使用される場合は、インタラクションストップをオンのままにします。チャレンジ画面には、より長いリロードではなく、より長い間隔が必要です。
N 後の停止実験
バイパスが役立つかどうか不明な場合は、stop-after-N を小さい数に設定してハード リフレッシュを有効にします。これらのサイクルの後にボードを比較し、本番環境ではバイパスを維持するか、負荷を下げるために通常のリロードに戻します。
複数タブのパターン
ハードリフレッシュは頑固なボード上でのみ実行してください。隣接するタブは通常のリロードを維持できるため、すべてのモニター間でキャッシュ バイパス トラフィックが増加することはありません。
コアループの実行方法
通常かハードかに関係なく、タイミングは Chrome アラームを使用して Service Worker 内に存在します。ポップアップはそのスケジュールに従います。オプションのオンページ タイマーは表面的な同期であり、権限ではありません。詳細: タブの自動更新の仕組み。
古い UI のトラブルシューティング
どちらのモードでも問題が解決しない場合は、拡張機能やプロファイルの不具合後にページに別の URL、フィルタのリセット、またはブラウザの完全な再起動が必要かどうかを確認してください。スケジュールの一時停止や「理由なく停止」の場合は、トラブルシューティングを使用してください。
試してみる
Auto Refresh Turbo をインストールし、安全なボード上で 1 つの通常サイクルと 1 つのハードリフレッシュ サイクルを比較し、デフォルトを選択します。