간편함 때문에 Vercel(이하 버셀)을 이용하여 블로그를 배포하고 있다.
(현재 기준으로 블로그는 NextJs 프레임워크 16버전 으로 개발되어 있다)
처음 포스트 페이지에 접속하면 클라이언트에게 컨텐츠를 보여주기 위해
서버 사이드에서 데이터베이스에서 데이터를 조회하여 사용자에게 보여줄 HTML 문서, 리소스를 만들어 클라이언트에게 전송한다. 이때 만들어진 HTML 문서, 리소스들은 NextJs의 캐싱전략에 따라 캐싱한다.
이 과정에서 클라이언트에게 리소스를 전달하는 데 시간이 걸린다.
이후, 포스트에 다시 접근하면 처음 페이지에 접속했을 때 만들어진 캐시 데이터를 사용하여 즉시 클라이언트에게 응답을 준다.
그런데, 아래 이미지를 보면 처음 로드 시간이 3.97초가 걸리고, 이후 캐싱 된 데이터를 받기까지 1.33초가 걸리는 것을 확인하였다.

1초가 넘어가는 이 상황.. 문제가 있다.
처음에는 NextJs 에서 서버 사이드에서 HTML,JS와 같은 리소스를 만들 때, 오래 걸리는 로직이 있는지 생각했었다. 하지만, 로컬 환경에서 테스트해 보니 아주 빨랐다.
리소스 응답 데이터를 내려주는 시간이 오래 걸리기 때문에 인프라(서버) 쪽에 문제가 있지 않을까 생각하게 되었다. 그러다가 버셀에서 Serverless Function로 리소스를 서빙하는데, 지역(Region) 이 큰 영향을 미친다는 것을 알게되었다.

요청에 대한 응답 헤더(맨 아래)에 X-Vercel-Id 값이 icn1::iad1::~ 고되어 있다.
해당 값은 사용자의 요청이 어떤 경로를 거쳤는지를 나타낸다.
icn1 과 iad1은 Region의 Code 값이며, 이는 요청이 icn1 에서 iad1 로 거쳐갔다는 뜻이다.icn1는 서울이며, iad1는 워싱턴DC이다.
즉, 나의 요청이 워싱턴DC까지 전달되고, 응답도 워싱턴DC로부터 전달한다는 것을 뜻한다.
물리적으로 거리가 멀면 속도도 당연히 느릴 수밖에 없다.
그럼 물리적 거리를 줄여보자.
Function Region 설정은 Project Settings에서 Functions 메뉴에서 가능하다.
내 블로그는 Washington, D.C., USA (East) - us-east-1 - iad1 로 설정되어 있었다.

한국에서 워싱턴 DC까지의 거리는 항공 거리 기준으로만 봐도 약 11,000KM 정도 되고 비행 소요 시간만 13~15시간 정도 걸린다.
리전을 서울로 변경했다.

처음 페이지 요청 시, 196ms 가 걸렸고, 이후 요청 시 113ms 의 시간이 걸렸다.
워싱턴DC였을 때와 비교해 보면 다음과 같다.
초기 요청) 3.9s → 0.196s (약 20배)
이후 요청) 1.33s → 0.113s (약 11배)
