개발자
next.js getServerSideProps 관련해서 질문드립니다.
1. getServersideProps(serverless function)는 동적인 컨텐츠를 제공해야하기 때문에 정적인 콘텐츠를 전달해주는 cdn를 거칠 수 없다고 알고 있습니다. 그래서 vercel origin 서버까지 통신을 거쳐서 콘텐츠를 전달 받기 때문에 TTFB가 느릴 것 같다고 생각했는데 여기까지 맞는 생각인가요? 2. next.js v13에서 edge(cdn)에서 동적인 콘텐츠를 받아올 수 있게 하기 위해 세그먼트 런타임 옵션(https://beta.nextjs.org/docs/rendering/edge-and-nodejs-runtimes#segment-runtime-option)을 통해 nodejs 대신 edge runtime으로 설정해주면 serverless function이 edge function이 되는건가요? 3. 커리어리 홈화면을 보니 getServersideProps를 사용하고 있고 pre-rendering는 간단한 골격만 하고 pre-fetch는 안해주고 있는것 같은데, 새로고침 했을때 TTFB를 300ms 정도로 유지할 수 있는건지가 궁금합니다! 저는 프로젝트 규모가 크지않은데도 불구하고 가끔씩 새로고침을 하면 TTFB가 1초이상 걸릴 때도 있거든요.. 어떻게 적용했는지 알려주신다면 큰 도움이 될 것 같습니다! 🙇🏻♂️
답변 2
안녕하세요! 1번 - 넵! 일반적으로 보면 맞습니다. 다만 vercel로 next 서버를 호스팅하고 있다면 serverless node.js runtime으로 돌아가고 최적화도 되어있을거에요. 말씀하신 edge 런타임 옵션을 사용하면 더 빠르지 않을까 생각됩니다. 커리어리는 vercel 안쓰고있습니다. 공식 문서에서 말하는 node.js runtime인 셈입니다. (serverless node.js도 edge도 아님) - https://beta.nextjs.org/docs/rendering/edge-and-nodejs-runtimes 2번 - 넵, 그렇게 알고 있습니다. pages 파일 (getServerSideProps가 있는)에서 edge runtime으로 변경을 해줄 수 있어요. - https://nextjs.org/docs/advanced-features/react-18/switchable-runtime#page-runtime-option 3번 - 피드 쪽은 제가 작업 안한지 오래되어서 기억나는것만 말씀드리면 홈 피드는 캐싱하고 있고 피드 조회는 람다 기반입니다!
박상범
작성자
프론트엔드 개발자 • 2023년 04월 28일
정현님 답변 감사합니다! 혹시 3번 답변에 '홈 피드는 캐싱하고 있고 피드 조회는 람다 기반' 이라는 말씀이 홈 피드는 서비스 워커로 http 캐싱을 하고 있고 조회는 람다로 캐싱을 확인하고 있다는 말씀이신가요? 그리고 궁금한 내용이 하나 더 있습니다! 저는 vercel 플랫폼을 통해 배포하고 있고 serverless function region을 icn1(인천) 으로 설정했습니다. 이 설정이 오리진 서버가 iad1(워싱턴, default 값)에서 icn1(인천)으로 변경됐다는 말인가요? 아니면 오리진 서버는 여러개고 serverless function 실행을 사용자의 위치와 가까운 오리진 서버랑 한다는 건가요? 아니면.. 오리진 서버는 하나이고 serverless function region을 설정하면 오리진 서버에서 동적 컨텐츠를 주고받지 않고 설정한 region에서 serverless function을 실행하는건가요?
손정현
엔지니어 • 2023년 04월 29일
"홈 피드는 캐싱하고 있고 피드 조회는 람다 기반" 피드를 접근하게되면 람다기반 http API로 요청합니다. 거기서 동적으로 피드에 필요한 데이터를 조합해주고 있어요. 요청마다 매번 피드를 조합해주는건 좀 힘들어서 백엔드 쪽에서 redis를 캐시로 사용하고 있습니다. 서비스 워커로 http 캐싱을 하는건 아닙니다. vercel이 자체적으로 물리적인 서버를 운영하는건 아닌걸로 알고 있습니다 (edge 컴퓨팅 쪽은 잘 모르겠네요. 직접 운영하고 있을수도 있구요). 일반적으로 vercel에 호스팅하시면 vercel도 아마 AWS나 GCP 같은 클라우드 서비스를 쓰고 있을거에요. 그래서 오리진 서버를 icn1로 바꾸신거면 icn1에 질문자님의 서버가 올라간다는 뜻입니다. 그럼 국내 사용자는 icn1이 물리적으로 가까우니 응답속도가 빠르겠지만, 미국 같은 곳에서 icn1으로 접속하려고하면 상대적으로 응답속도가 느리긴하겠죠. 디폴트 region이 icn1이면 serverless function도 다 icn1로 올라갈겁니다. 한가지 더 첨언하자면 서버가 icn1이어도 서버에서 접근하는 DB 서버가 다른 region이라면 icn1에 올라간 서버와 DB서버의 물리적인 거리 때문에 응답속도가 느릴 수 있습니다. 요거 참고하시면 좋을것 같아요 :) - https://vercel.com/docs/concepts/functions/serverless-functions/regions
박상범
작성자
프론트엔드 개발자 • 2023년 04월 29일
이해하는데 많은 도움이 되었습니다! 친절한 답변 감사합니다 :)
손정현
엔지니어 • 2023년 04월 29일
추가로 edge network는 사용자 기준에서 가까운 region에 있는 서버로 요청을 하네요. 즉, vercel로 서버를 호스팅한다면 edge function이랑 정적 파일들은 vercel이 제공하는 모든 edge 서버에 복제되는것 같습니다. - https://vercel.com/docs/concepts/edge-network/regions#routing 코드 상으로 edge region을 제한해 줄수도 있네요 - https://vercel.com/docs/concepts/functions/edge-functions#edge-function-regions serverless function region은 일반 계정이면 1개로 고정이고 enterprise 계정이면 여러 region에 호스팅할 수 있는 것 같습니다. - https://vercel.com/guides/choosing-deployment-regions
박상범
작성자
프론트엔드 개발자 • 2023년 04월 29일
추가 정보 감사합니다 👍🏼
1. ' getServerSideProps ' 함수가 실행되기 위해서는 먼저 요청이 Vercel의 origin 서버로 전송되어야 하기 때문에 CDN을 거칠 수 없습니다. 따라서 TTFB가 일반적인 정적인 콘텐츠를 전송하는 경우보다 더 느릴 수 있습니다. 그러나, Vercel은 SSR을 최적화하고 빠르게 처리하기 위해 최신 기술을 사용하므로, TTFB가 굉장히 빠르게 나올 수 있습니다. 2. ' next.js ' v13에서 세그먼트 런타임 옵션을 통해 Node.js 대신 Edge runtime으로 설정하면, ' getServerSideProps ' 함수가 Edge Function으로 변환됩니다. 이렇게 함으로써, 동적 콘텐츠를 CDN을 통해 전송할 수 있으며, 빠른 TTFB를 보장할 수 있습니다. 3. ' getServerSideProps ' 함수를 사용하면 SSR을 할 수 있기 때문에, 페이지가 로드될 때마다 서버에서 데이터를 가져와 렌더링을 수행합니다. 이를 통해, 새로고침을 했을 때에도 빠른 TTFB를 유지할 수 있습니다. ' getServerSideProps ' 함수를 최적화하고, 데이터를 적절하게 캐싱하면, TTFB를 300ms 정도로 유지할 수 있을 것입니다. 또한, ' prefetch ' 나 ' useSWR ' 등을 사용하여 데이터를 프리로드하면, 더 빠른 페이지 로딩이 가능합니다. 그러나, 페이지 로딩 속도는 여러 가지 요인에 따라 달라질 수 있습니다. 예를 들어, 데이터를 가져오는 데 걸리는 시간, 서버의 성능, 클라이언트의 네트워크 상태 등이 영향을 미칩니다. 따라서, TTFB를 최적화하는 것 이외에도, 데이터를 최적화하고, 코드를 최적화하고, 리소스를 최적화하는 등의 작업을 수행하여, 페이지 로딩 속도를 개선할 수 있습니다.
커리어리 AI 봇의 답변을 평가해 주세요!
지금 가입하면 모든 질문의 답변을 볼 수 있어요!
현직자들의 명쾌한 답변을 얻을 수 있어요.
이미 회원이신가요?
지금 가입하면 모든 질문의 답변을 볼 수 있어요!