タグ
#Astro
Astroに関する記事を公開しています。
Void は import を見て Cloudflare のリソースを作り、作った物は消さない
KV を使う Astro のノートアプリでは、ID を貼る作業が Void で無くなりました。ただ、どのページからも呼ばれていないファイルでも、`void/storage` を import する行があるだけで R2 バケットが作られ、そのファイルを消してもバケットは残りました。Void は作るリソースをファイルの置き場所と import から決めます。作る前に一覧は出さず、作った物を自動では消しません。
Astro の /_astro/ 画像が移行後に 404 で叩かれ続ける原因と対処
WordPress をヘッドレスに使った Astro の静的ビルドから EmDash へ作り直したあと、旧ビルドの /_astro/<名前>-1024x717_<ハッシュ>.jpeg に週 700 回以上の 404 が来ていました。User-Agent は普通のスマートフォンのブラウザで、画像検索からの着地でした。EmDash のリダイレクト表は拡張子付きのパスを引かないため 747 行入れても発火せず、ミドルウェアでファイル名からメディアを引いて 301 する形にして、週 1,640 件の 404 を 156 件に減らしました。残った 1 枚は同じ画像が別名で 2 回アップロードされていたもので、Redirect Rule 1 本で受けた経緯までまとめます。
Astro + Cloudflare で公開した記事が 404 のままになる原因
記事を公開したのに、記事の URL だけが「ページが見つかりません」のままでした。公開前にその URL を一度でも開いていると、404 のレスポンスがエッジに 30 日キャッシュされ、公開しても消えません。Astro の routeRules はリクエストのパスで照合してステータスを見ず、EmDash が公開時に失効させるタグ（コレクション名と記事 ID）は 404 には付いていないためです。purge の仕組みを足す案を作って取り下げ、404.astro で Astro.cache.set({ maxAge: 300, swr: 0 }) を呼んで 5 分に上書きするだけにした経緯と、swr を忘れると起きることを実測で書きます。
Cloudflare にデプロイしたのに反映されないのはブラウザのキャッシュ
デプロイ後にブラウザで開くと古いページのままで、ハードリロードすると新しくなる状態になりました。エッジは正しく更新されていて、原因はレスポンスに Cache-Control が 1 つも無かったことです。指示が無いとブラウザは Last-Modified から有効期限を推測するため、古い記事ほど長く保持されます。エッジ用のヘッダはエッジで取り除かれるので、ブラウザ向けの指示は別に出す必要がありました。
EmDash で記事にタグを付けても本番に反映されない原因
記事にタグを付け直しても、本番のタグ一覧に出てきませんでした。CMS がキャッシュを自動失効させているのはコンテンツの CRUD だけで、タグの割り当て・サイト設定・メニュー・ウィジェットエリアは別のルートで処理され、失効を呼んでいませんでした。エッジキャッシュの保持時間を 30 日に延ばしてから実害が出た問題で、CMS 本体に patch を当てず、アプリ側のミドルウェア 1 か所で失効させるようにした記録です。
Cloudflare の Purge Everything で Workers Cache が消えない理由
ダッシュボードから Purge Everything を実行しても、ページが古いまま返ってきました。age が単調増加していることから消えていないと分かります。原因は消そうとしていたキャッシュがゾーンの CDN キャッシュではなく Workers Caching だったことで、ゾーンレベルの purge はこの層に届きません。あわせて、デプロイ時の purge がそもそも不要である理由も確かめました。
キャッシュを 30 日にしても D1 の読み取りが減らない原因
エッジキャッシュの保持時間を 5 分から 30 日へ延ばしても、データベースの読み取りが目標の 2 倍を超えたままでした。クエリ単位で分解すると 7 割がサイドバーの件数表示のための集計で、しかもサイドバーを消しても止まりませんでした。CMS のミドルウェアが全ページでターム一覧を先読みしていたためです。切り分けに使ったのは 1 起動あたりの読み取り行数と、クエリの実行回数がリクエスト数の何倍かという比率でした。
navigator.share の判定だけでは PC でも共有シートが出る
スマホでシェアボタンを押すとログインを求められるので、共有シートに切り替えたところ、PC でも切り替わりました。Chrome・Safari・Edge はデスクトップでも Web Share API に対応しているためです。日本語で流通している判定方法は navigator.share の存在チェックですが、これは Chrome デスクトップが非対応だった頃の前提で、今はスマホかどうかの判定になりません。(pointer: coarse) と組み合わせてスマホだけに共有シートを出します。
WordPress 移行後に本文に残った旧 URL を Portable Text から数える
WordPress から移行したあとに残る旧画像 URL を片付けようとして、公開 HTML から数えた 21 本とデータベースから数えた 58 本が食い違いました。差の正体は表示されないリンク注釈と、生 HTML ブロックの中の書き換え漏れでした。ついでに 5 記事で画像が 404 になっていたことも見つかりました。
Astro の routeRules から外してもページがキャッシュされる
エッジキャッシュから問い合わせページを外そうとして routeRules に書かずにデプロイしたら、本番では HIT が返ってきました。キャッシュの有効判定は maxAge かタグのどちらかで立ち、CMS のキャッシュヒントはタグだけを持つため、保持時間の指定が無いままキャッシュされます。外すには routeRules ではなくページ側の Astro.cache.set(false) が要ります。
Cloudflare で purge しても age が伸び続けるのは壊れていない
記事を更新してもページが変わらず、age が単調増加する。ここから「失効が壊れている」と結論しましたが、間違いでした。purge はキャッシュを消すだけで、再描画は次のアクセス時です。curl -I での確認はキャッシュから返るためサーバーに届きません。4 回続けて誤診した過程と、キャッシュのデバッグで守るべきことをまとめます。
Cloudflare で HTML がキャッシュされないのは既定の仕様
「Cloudflare を通しているからキャッシュは効いている」は静的ファイルの話でした。HTML には cf-cache-status ヘッダすら付きません。キャッシュミスではなく、判定の対象になっていない状態です。既定が拡張子ベースである理由と、Astro のサーバーレンダリングで HTML をエッジにキャッシュさせる方法を実測とあわせて書きます。
Cloudflare Workers 無料プランで 503 が出る原因は CPU 上限
毎分 10〜31 リクエストという低負荷で 4 回に 1 回が 503。同じサイトが 1 時間 2,516 リクエストをエラーゼロで捌いた実績もあり、負荷では説明が付きません。原因は無料プランの CPU 上限 10ms でしたが、この上限は「1 リクエストで超えたら落ちる」という単純な仕組みにはなっていません。実測ログとあわせて機構を整理します。
Cloudflare Workers 無料プランの 3 MB 上限に数えられるもの
Cloudflare Workers の無料プランには gzip 後 3 MB というバンドルサイズ上限があります。実運用中のサイトの実測値は約 2.1 MB で、残る余裕は 900 KB ほど。画像生成ライブラリを 1 つ足すだけで +680 KB 増えて 3 MB の上限の手前まで届く一方、11 MB ある静的アセットは 1 バイトも数えられません。何が数えられて何が数えられないのかを実測値で整理します。
Astro.rewrite(\"/404\") が 200 を返してソフト 404 になる
Astro SSR の動的ルートでエントリ未検出時に Astro.redirect(\"/404\") すると 302、Astro.rewrite(\"/404\") にしても HTTP ステータスは 200 になりソフト404になります。Astro が rewrite でステータスを 200 にリセットする機構（astro@7.0.7 のソース）と、404.astro 側で Astro.response.status = 404 を立てて正しく 404 を返す方法をまとめます。
WordPress 移行後に記事内の画像が 404 になるときの対処
WordPress をヘッドレス CMS へ移行したあと、本文が旧 /wp-content/uploads/ を参照したままで記事内の画像が 404 になる問題。404 の 9 割超は実体が移行済みで URL だけが古いので、本文を書き換えずキャッチオール動的ルート 1 本でファイル名からメディアを引いて 301 する設計と、WordPress 命名（-WxH サムネイル・-e 編集版）や .gitignore の落とし穴をまとめます。
D1 の無駄なクエリを削ったらクエリ数が増えた原因
エッジ SSR（Cloudflare Workers + D1）ではレイテンシの支配項は CPU ではなく DB への往復回数です。明らかに無駄なクエリを削ったら本数が 19→22 に増えた原因であるリクエスト内キャッシュの重複排除と、推測で書き換えず「表示が変わっていないこと」を HTML のバイト一致で証明しながら最適化するウォーム A/B 計測の手順をまとめます。
Tailwind v3 で node_modules の CSS が @layer エラーになる原因
Tailwind v3 を PostCSS 経由で入れると、node_modules のビルド済み CSS まで処理対象になり、ネイティブの @layer を使う標準準拠の第三者 CSS がエラーになります。管理画面が 500 になった実例から、@tailwindcss/vite（v4）移行による解決と、実際に必要だったクラス名の書き換えをまとめます。
日本語 URL の 301 リダイレクトだけが効かない原因
WordPress 移行のリダイレクトで、英語スラッグは動くのに日本語スラッグだけ 404 になる原因は percent-encoding の大文字・小文字でした。ブラウザは大文字（RFC 3986 の正規形）で送り、WordPress は小文字で保存する。URL API が既エンコード文字列を正規化しない仕様と、decode→encode による正規化をまとめます。
astro dev がエラー表示なしで終了する原因（Astro 7）
Astro 7 は AI エージェントからの起動を検出すると自動でバックグラウンド + JSON モードに切り替わり、起動失敗の本当の原因が「exited before becoming ready」の一行だけになります。ASTRO_DEV_BACKGROUND=1 での調査方法と、隠れていた Node.js 22.15 未満の registerHooks エラー、dev server を管理するサブコマンドをまとめます。