犯人は、ブラウザではなかった
またまた1週間ぶりのご無沙汰です。
最近ちょっと急ぎでHTMLファイルを書いているのですが（先週書きました自分の用件とは別口で）、昨日も今日も、1時間ずつくらい頭をかかえてしまいました。いくら新しいファイルを載せても変更が反映されず、てっきりブラウザのキャッシュ（とくにHTML文法チェックのため頻繁に使っているChrome）が、犯人だと思っていたのです。
ところが犯人(?)は…
顛末は、こんな感じでした。HTMLとCSSをひとつずつ、どちらかが気になって変更するたびに、だいたい5分に1回くらい載せに行っていたのです。FTPクライアントのFileZillaにも、きちんと「上書き」を指定していましたし、FileZilla上では、たしかに該当するタイムスタンプとファイルサイズのものが、サーバに載ったはずでした。
というわけで、ファイルは確かに新しいものを載せていたのですが、Chromeでリロードをクリックしても、シフト+リロードを押しても、コマンド+リロードを押しても、まったく関係なく、ときには前々回くらいの変更で削除したはずの行を「この行はタグが閉じていない」とエラーを出します。そのときChromeが見ているファイルのソースには、わたしが何回か前の作業で消したはずの行が残っている。
Chromeのキャッシュだけの問題ではないのかもという思いも、ようやく頭に浮かんできました。同じ時間帯に別ブラウザや別デバイス（たとえばスマホやタブレット）でも、表示が古くなったり新しくなったりするのです。
ローカルでだいたいの表示確認が済んでいたため、最後にねんのためネットに載った状態でChromeのプラグインでHTML文法チェックをする、というのが本来の目的でした。ですので、最初はあまりChrome以外を真剣に見ておらず、Chromeのキャッシュのことばかり考えていました。
原因がわからず、仕方ないのでChromeやFilezillaを立ち上げ直しては「載せる→見る」をやっていますと（ブラウザのキャッシュをそのたびに消すのは生産的ではないとの判断で）、何回かに一度は、うまく表示されました。するとほかのブラウザやデバイスでも、調子よくなるのです。
そこで、もしや…と、ロリポップの設定欄を見に行きますと。
どうもわたしがこの数ヶ月で作成したサブドメインは「ロリポップ! アクセラレータ」というものが自動でオンになっていたらしく、だいたい10分間くらいは、キャッシュが残っているとのこと。これが、犯人（←失礼ですが）でした。
このキャッシュは動的なコンテンツのあるサイトに有効ということでしたが、わたしがロリポップで設定を見ると、肝心のWordPressがある場所は設定をしておらず、それ以外のものがオンになっていたようです。速度が上がるならと、さっそくオンにしました。
それにしても、たかだかHTMLとCSSが数ファイルずつ置いてある小さな場所に、まさかのキャッシュ。驚きましたが、これからは、うまく活用していこうと思います。