「後端 API 回應很慢，你會怎麼協助排查？」這題不是要你把責任推給後端。
它真正想看的是：
- 你能不能把「感覺很慢」拆成可觀測的數據
- 你知不知道 Network timing 怎麼看
- 你能不能分辨 API 慢、資料太大、前端處理慢
- 你會不會用清楚資訊和後端協作
第一步：先拆慢在哪裡
我會先打開 DevTools Network，看這幾件事：
- request 是否重複送出
- TTFB 是否很高
- response payload 是否太大
- download time 是否很長
- 是否多了一次 CORS preflight
- cache header 是否合理
- status code 是否穩定
如果 TTFB 很高，代表 server 開始回應前就花很多時間，可能是後端查 DB、呼叫第三方服務或排隊處理慢。
如果 download time 很長，可能是 response 太大或網路傳輸問題。
如果 API 其實很快，但畫面仍然卡，問題可能在前端 parse JSON、資料計算或 render。
第二步：確認是不是前端造成的慢
API 慢不一定真的是 API 慢。
前端也要檢查：
- 是否同一個 API 被重複呼叫
useEffectdependency 是否導致重複 request- response 回來後是否 render 了大量 DOM
- JSON parse 是否卡住 main thread
- filter / sort 是否在每次 render 都重算
- 是否圖片或子元件太重
如果是列表頁，可以搭配 React Profiler 看 commit time。
第三步：提供可重現資訊給後端
不要只丟一句「這支 API 很慢」。
我會整理：
- endpoint
- request query / payload
- response size
- timing screenshot
- trace id / request id
- 發生環境與時間
- 是否每次都慢，還是特定條件才慢
- 使用者資料量或篩選條件
這樣後端才能接著查：
- DB query 是否慢
- 是否缺 index
- 是否有 N+1 query
- 是否呼叫第三方服務
- 是否可以 cache
- 是否可以 pagination / cursor
- 是否可以只回必要欄位
前端可以先做哪些改善？
即使後端還沒修，前端也能改善體感：
- skeleton / loading state
- request debounce
- abort previous request
- cache 前一次結果
- pagination / infinite scroll
- optimistic UI
- 避免同畫面重複打同個 API
- 錯誤重試與 fallback
但這些是改善使用者體驗，不代表可以掩蓋真正的 API 瓶頸。
常見追問
TTFB 是什麼？
TTFB 是 Time To First Byte，代表瀏覽器發出 request 後，到收到 response 第一個 byte 的時間。
TTFB 高通常代表 server 或 upstream 處理慢，不一定是前端 render 問題。
如果 payload 太大怎麼辦？
可以討論：
- pagination
- cursor pagination
- 只回必要欄位
- 壓縮 response
- cache
- 讓搜尋與排序在後端處理
如果是前端重複 request 呢？
檢查 useEffect dependency、React Strict Mode 行為、component mount/unmount、query key 是否穩定，以及是否需要 request dedupe。
面試回答模板
我會先用 DevTools Network 拆 timing，確認是 TTFB 高、payload 大、download 慢、重複 request，還是 API 回來後前端 render 慢。接著用 Performance 或 React Profiler 看 main thread 和 commit time。如果確認偏後端，我會提供 endpoint、query、payload size、timing screenshot、trace id 和發生條件給後端一起查。若是資料量問題，會討論 pagination、cache、只回必要欄位；若是前端處理問題，就優化 request 次數、資料計算和 render。