HTMLの変更がブラウザに反映されないとき

一度、これに十分ほど持っていかれたことがあります。ダウンロードフォルダの中のファイルを保存しては、同じページを開いたタブを更新していた——でもそのタブは、デスクトップから開いたほうだったんです。名前も同じ、中身も同じ、けれど別々のファイル。私はずっと、誰も見ていないコピーのほうを律儀に編集していました。だいたいこういうオチです。HTMLの変更が反映されないとき、原因はまずコードではありません——古いキャッシュ、ちゃんと保存できていないファイル、.html.txt という拡張子、DevTools に取り残された編集、あるいはブラウザが、あなたの変えたのとは別のコピーを読んでいる。私がいつも上から順に見ていくチェックリストを、いちばん早く捕まえられるものから並べます。

六十秒でできるチェックリスト

何かをいじる前に、このリストを上から下まで読んでください。たいてい、答えはもうこの中にあります。

• 保存していない。 変更はまだエディタの中で、ディスクには一度も書かれていません。
• 別のコピーを見ている。 タブが別のフォルダ、あるいはホスティングされた版を指していて——編集したファイルではありません。
• ブラウザがキャッシュしている。 ファイルを読み直さず、古いページや古い CSS をメモリから出しています。
• ファイルの拡張子が違う。 index.html.txt は正しく見えて、ただのテキストとして振る舞います。
• DevTools の中だけで変えた。 その編集はタブの中に住んでいて、更新すると消えます。
• 別の CSS ルールが、あなたのを上書きしている。 変更はちゃんとある——ただカスケードで負けているだけ。

では修正を、私が実際に確かめる順で。

そもそも保存できていない

いちばん間抜けな可能性から始めましょう。それがいちばん多いからです。エディタのタブを見てください——点かアスタリスクが付いていたら、それが「未保存」の印で、変更がディスクに届く前にブラウザを更新したということ。Ctrl+S。おしまい。

同じ問題の、もっと静かな版もあります。保存する場所を間違えるやつです。エディタが思わぬ場所に「コピーを保存」していたり、ファイルを二つ開いていたりして、ブラウザは一度も変えていない元のほうを読んでいる。これがそのまま、次の話につながります。

編集しているファイルと、見ているファイルが違う

これは一つ前の双子で、もっとうまく隠れます。ファイルが二か所で開いている——たとえば別々のフォルダ、あるいはローカルのコピーとホスティングされた版——そして、あなたが片方をせっせと編集する横で、ブラウザはもう片方を見せている。

アドレスバーを見てください。ローカルファイルなら file:/// から始まるフルパスが出ていて、それがいま編集したファイルと、一文字たがわず一致しているはずです。もし実際に配信されているサイト——localhost で動いている、あるいはもうどこかにデプロイ済み——を触っているなら、そこにもう一層あります。ローカルファイルを更新してもサーバー側の変更は見えないし、公開URLを更新してもローカルの変更は見えません。自分がどのコピーを変えているのかを見きわめて、ブラウザをそのコピーにぴたりと向けましょう。

ブラウザが見せているのは、昨日のページ

ブラウザは、ページや画像、とりわけ CSS のコピーを手元に持っておいて、訪れるたびに全部を落とし直さずに済ませます。ふだんはありがたい話。でも編集している最中は、それが面と向かって嘘をつく相手になります——ただ更新しただけだと、ファイルを読み直さずにキャッシュ版を渡してくることがあるんです。

直し方はスーパーリロード。ブラウザに「そのコピーは捨てて、全部取り直せ」と伝えます。Windows と Linux では Ctrl+Shift+R、Mac では Cmd+Shift+R。Windows なら Ctrl+F5 でも効きます。ここでいちばん厄介なのが CSS です——HTML の文字は更新されるのにスタイルは動かない、リンクされたスタイルシートが単独でキャッシュされているせいで。スーパーリロードは両方まとめて片づけます。それでもまだ手放さないなら、DevTools を開き、開いたまま更新ボタンを右クリックして「キャッシュの消去とハード再読み込み」を選んでください。これでページには何も残りません。

ファイルがいつのまにか .txt になっていた

先に直し方、それから理由を。保存する前に「ファイルの種類」を「すべてのファイル」にする、あるいは名前を引用符でくくる——"index.html"——そして本当の末尾が見えるように、拡張子の表示をオンにします。引っかけてくるのは、メモ帳の初期設定です。index.html を編集して「名前を付けて保存」を押すと、ダイアログはただのテキスト文書だと思い込み、.txt を末尾に足す。そうしてあなたは index.html.txt を抱えて帰ることになる——ブラウザはそれをテキストとして読み、すぐ隣にある本物の .html は、ぴくりとも動きません。このリストのどれよりも多くの人を捕まえる罠で、HTMLファイルを編集する方法でもっと掘り下げています。

DevTools の中だけで変えていた

ページを右クリックして「検証」を選び、要素パネルやスタイルパネルに変更を打ち込んできたのなら——その変更は本物ではありません。少なくとも、意味のある本物ではない。DevTools の編集は、タブのメモリに住んでいます。ライブのページで何かを試すには最高ですが、ディスク上のファイルには一切触れず、更新した瞬間に消えます。

だから変更が消えるのは当たり前。更新こそが、それを捨てる操作なんです。残したいなら、うまくいったものを DevTools から取り出して、本物のファイルに貼り付け、保存する。DevTools は、見え方を確かめるために落書きするスケッチブック。ファイルが本文です。書いたものを取っておいてくれるのは、二つのうち片方だけ。

別のルールが勝っている

たまに、変更はまちがいなくファイルの中にあって、保存もされ、キャッシュも通っていない——なのに、うんともすんとも言わない。十中八九、CSS が CSS を上書きしています。段落に色を付けたのに、スタイルシートのもっと下にある、より具体的なセレクタ、あるいは要素に直付けされたインラインスタイル、あるいは誰かの置き忘れた !important が、あなたに勝っている。まず効くのは詳細度です——より的を絞ったセレクタは、ファイルのどこにあろうと勝ち、二つのルールの詳細度が同じときにかぎって、後に書かれたほうが取る。カスケードが仕事をしているだけ——ただし、あなたの思っていた仕事ではない。

DevTools が、それをはっきり見せてくれます。要素を検証してスタイルパネルを開くと、負けたルールがそこに、取り消し線を引かれて並んでいる。あなたのルールに線を引いている当のものが、変えるべき相手——あるいは、それより具体的に書くべき相手です。あてずっぽうより、いつだって確実。

ライブエディタなら、この大半を素通りできる

さっきのリストを見返して、その大半が共有しているものに気づいてください。保存、ブラウザへの切り替え、更新——編集と、目にすることのあいだにあるあの小さな隙間。そこがキャッシュの忍び込む場所であり、まちがったファイルの紛れ込む場所であり、.txt の隠れる場所です。隙間を閉じてしまえば、この大半はそもそも起こりようがない。

それが、私の作った HTML Tweak というツールの発想です。自分の .html ファイルを開き、レンダリングされたページとコードを横に並べ、同期させたまま編集する——片方を変えれば、もう片方も一緒に動く。あいだに「保存してから更新」のダンスはありません。戦うべきキャッシュのコピーもない、見ているのはファイルそのものだから。打ち込んだものが、更新で忘れるパネルに取り残されることもない。Chrome や Edge なら、そのままファイルに保存し直します。ほかのブラウザは、編集済みのコピーをダウンロードします。複数ファイルの React や Next のプロジェクトは動かせません——一枚のページを仕上げるために作ったものなので——けれど、その用途でなら、「なぜ反映されないのか」という問いは、ほぼ出てこなくなります。

だから次にページが動いてくれないときは、チェックリストを上から回してください——ほぼいつもキャッシュのせいで、あなたの目のせいではまずない。そして、「保存して更新」のルーレットを、そもそも回したくないのなら——HTML Tweak は、打つそばからファイルが変わっていくのを、ただ見せてくれます。