こんにちは。未経験からエンジニアを志望しているkotoです。
今回は私の作成したレシピサイトで発生した、開発環境ではスムーズだった検索結果の表示が本番環境では遅くなってしまうという問題の解決までをご紹介します。

TL;DR

症状：検索ワードなし（一覧大量表示）で 本番だけ 表示が遅い
原因：ActiveStorage の画像配信 302 を出す Rails（Fly.io）が 海外リージョン（syd/cdg 等）で動いていて、毎画像「日本→海外→日本（S3東京）」の遠回りになっていた
対策：Rails を 東京（nrt） に配置し直す（Fly.io の scale count で Machines を移動）
効果：画像の遅延読込（next/image の lazy）と相まって、表示速度が一気に改善

環境

フロント：Next.js（next/image 利用）
サーバー：Ruby on Rails（ActiveStorage）
デプロイ：Fly.io（App 名：back-main）
画像ストレージ：Amazon S3（ap-northeast-1 / 東京）

問題の見え方

検索ワードなしで一覧を出すと重い（画像が多い画面）
検索ワードありでヒットが少ないと速い
開発（ローカル）は快適だが、本番が遅い

まず最初にやったこと

ブラウザの DevTools → Network → 一覧表示時に 画像の1リクエストを選び、Headers を確認。

Request URL が .../rails/active_storage/blobs/redirect/.../xxx.jpg なら ActiveStorage の 302
fly-request-id の末尾をチェック

結論：Rails が海外（例：cdg/syd）で 302 を返していた。
つまり：ユーザー（日本）→ Rails（海外）→ S3（東京）という 遠回りになっていた。

対策

Rails を東京（nrt）で動かす
（Fly.io は昔の regions set ではなく、Machines の台数（count）をリージョンごとに調整します）

手順

1) 現在の配置を確認

fly regions list -a back-main
結果例）Regions [app]: syd, nrt など

2) 東京（nrt）に 1 台追加

fly scale count 1 --region nrt -a back-main
# 対話が出たら y で実行

3) 海外リージョン（例：syd）を 0 台に

fly scale count 0 --region syd -a back-main
# Destroyed ... と出ればOK

4) 状態確認

fly regions list -a back-main
# 例）Regions [app]: nrt


fly status -a back-main
# Machines の STATE が started になっていればOK

直ったかの確認

ブラウザで画像の ActiveStorage 302 のリクエストを再度開く
fly-request-id の末尾が -nrt になっているか
体感：初期表示とスクロール時の読み込みが軽くなっているか

※Vercel/CDN のキャッシュ経由だと一時的に古い経路（-cdg 等）が見えることがあるようですが、順次更新されます。

なぜこうなったか

① ブラウザ（Next.jsのページを表示）
↓ 画像の見える位置で lazy load が作動（next/image）
② Rails（Fly.io）にアクセス：/rails/active_storage/blobs/redirect/...
↓ 302（Found）で S3 の署名付きURLを返す
③ ブラウザが S3（東京）にアクセス
↓ 画像データ（200 OK）を受け取り、描画

遅かった理由：②の Rails が海外にいて毎画像遠回りになっていた
有効だった対策：②を東京（nrt）に置き、距離（遅延）を減らした
さらに効いた要素：next/image による遅延読込（見えるときだけ読み込む）

まとめ

本番だけ遅い場合、**通信経路（リージョン）**をまず疑う
ActiveStorage は毎画像 302 で Rails→S3 を案内するため、Rails の場所が致命的に効く
Fly.io の Machines を東京（nrt）に寄せるだけで、多くのケースは一気に改善する。

終わりに

「海外リージョンで 302 → S3 東京」になっていないかを最初に見るだけで、原因に一直線で辿り着けます。
同じ症状の方の時短になれば幸いです 🙌