BFCacheを有効化。
再表示に、いちいち再読み込みをかけるのは非合理だし、ユーザビリティを考えれば、それは「かくあるべき」Webブラウザの所作でしょ？と思っていたんだけど、どうも世間の理解は違うらしいんだよね。
こんなものにもいちいち名前がついていて、正式には「Back-Forward Cache」と言うらしい。いわゆる標準規格ではなく、曰く、ブラウザベンダが個別に実装したものであり、その目的とするところはレンダリング速度の向上にあるのだという。したがって、通信環境やCPUリソースに余裕がある状況では有効にならない「こともある」らしい。
この説明がわからない。
なぜ、一度表示したページの再表示にわざわざ再読み込みをかける必要があるのか。DOMツリーとjavascriptの実行状態をそのままキャッシュしておいて、必要に応じて読み戻せばいい。CPUリソースやメモリに余裕がある環境ならなおのことだ。
そもそもユーザーが期待するブラウザバックの機能は、その他一般アプリケーションにおける「元に戻す」であり、つまり、作業状態の回復にほかならないのではないのだろか？
リソースの更新がないことで生じる問題などは、reloadで明示的に対応すべきだと思うんだけど。
そのあたりの議論は知らないけれど、Firefoxは37あたりからこのへんのポリシーが変更されたようで、一部DOMに対してスクリプトで加えられた変更が、BFCacheに反映されなくなった。正確なところはわからないが、どうもDOM構築後、非同期処理で加えられた部分的変更はキャッシュしないことになったらしい。
Greasemonkeyの自作スクリプトが、まさにそういう処理を行っており、かつ、ブラウザバックの使用前提のUIを組んでいるので、この変更には少々困ったわけだが、どうにかならんもんかと試行錯誤しているうち、解決策はあっさり見つけることができた。
理由はわからないが、HTMLの方にscriptタグを使って適当なインラインスクリプトを書くと、非同期の更新に対してもキャッシュが有効になるようなのだ。よかった〜。
…んなわけないだろ。
因果関係の不明瞭な挙動はおしなべてバグである。前掲したサイトにもある、unloadイベントを設定してBFCacheを無効化するハックなども、それを行うことでキャッシュが無効になる合理的な説明がないのだから、それは想定外の動作と考えるべきで、安易な使用は避けるべきだ。まぁ使うけど。
Firefoxは将来的にAdd-onの仕様をすべてChrome Extensionと共通化するというので、いずれGreasemonkeyが使えなくなってしまう可能性もあるかなと思って、自作スクリプトのChrome Extensionへの移植も進めているのだけど、Chromeではこの、インラインスクリプトを書いてBFCacheを有効化するハックは使えないようだ。
Firefoxでしか使えないんじゃなー。
どうしたものかな…。