Next.js 이미지 최적화가 느려졌을 때 캐시 헤더부터 확인한 과정

처음에는 파일 크기를 의심했다

상품 카드 이미지가 운영에서만 늦게 나타났다. 원본을 300KB 아래로 줄였는데도 첫 응답이 1초를 넘겨서, 용량보다 응답 헤더를 비교하기로 했다. 로컬은 두 번째 요청이 빨라졌지만 운영은 같은 URL도 매번 변환하는 듯했다.

헤더에서 보인 차이

curl -I "https://example.com/_next/image?url=%2Fimages%2Fitem.jpg&w=640&q=75"
curl -I "https://example.com/images/item.jpg"

운영 응답의 Cache-Control이 짧았고 프록시는 private로 판단하고 있었다. 사용자별 데이터가 아닌 변환 이미지는 공개 캐시를 허용하고, 업로드 API 응답은 캐시하지 않는 기준을 세웠다.

// next.config.mjs
const nextConfig = { images: { formats: ['image/avif', 'image/webp'], minimumCacheTTL: 3600 } };
export default nextConfig;

다시 측정한 방법

첫 요청 하나만 보고 성공 처리하지 않았다. 같은 URL을 세 번 호출해 Age, ETag, Cache-Control을 비교했고, 공통 이미지 컴포넌트에 unoptimized가 남아 있지 않은지도 검색했다. 캐시 적중 요청과 변환 요청의 시간을 따로 기록했다.

다음에 확인할 목록

• 원본 크기와 최적화 응답 시간을 분리한다.
• 애플리케이션과 CDN의 헤더를 각각 본다.
• 공개 이미지와 인증 이미지의 정책을 나누고 첫 요청과 재요청을 비교한다.

이미지를 줄이는 일과 다시 만들지 않는 일은 달랐다. 이번에는 화질보다 캐시 경계를 먼저 확인해 수정 범위를 줄였다.