시작하게 된 이유
현재 하고 있는 프로젝트는 Next.js와 TypeScript를 사용한 프로젝트다.
그러던 와중에 SSR의 개념에 대해서 얘기가 나왔다.
팀원 의견 : getserversideprops 를 사용해야 SSR이다.
내 의견 : Next.js 자체로 SSR이 지원되니까 SSR을 하고 있는 것이다.
CSR vs SSR
CSR과 SSR에 대해서는 해당 POST에 정리해두었다.
넥스트 공식 홈페이지에서 설명
https://nextjs.org/docs/basic-features/pages
Next.js는 기본으로는 정적 페이지를 생성해주는 프레임워크이다.
SSR은 개발자의 선택사항으로 정하면 된다.
hydration
Pre-Rendering된 웹 페이지를 클라이언트에게 먼저 보내고, 번들링 된 자바스크립트 코드들을 클라이언트에게 전송함.
자바스크립트 요소들이 렌더링 될 때는 먼저 받아진 document의 DOM 요소에 자바스크립트 속성이 매칭 되는 것이기 때문에 웹 페이지를 다시 그리는 과정은 일어나지가 않습니다.
페이지가 브라우저에 의해 로드되면 해당 JavaScript 코드가 실행되어 페이지가 완전히 상호 작용하도록 합니다
Hydrate는 Next.js에서만 일어나는 과정이 아니고, 사실 ReactDOM의 함수이다.
SSG
Static Site Generator : 정적 페이지 생성기
Pre-Rendering : Next.js에서는 build를 진행할 때 작성한 각 페이지들에 대해 각각의 HTML을 생성해서 static한 파일로 생성을 한다
해당 페이지에 대한 요청이 발생하면 페이지를 재생성하는 것이 아닌 이미 생성된 페이지를 반환하는 형태로 동작한다.
- 성능상의 이유로 서버 측 렌더링보다 정적 생성을 사용하는 것이 좋습니다 .
장점
Pre-Rendering된 Document는 자바스크립트 요소가 빠진 가벼운 상태이기 때문에 초기 렌더링 속도가 우월하다.
Next.js가 제공하는 SSG와 SSR 함수
getStaticProps
Next.js에서 SSG를 사용하려면 getStaticProps를 사용하면 됩니다.
getStaticProps는 클라이언트에선 실행되지 않고 서버에서만 실행되는 함수
빌드 시에 딱 한 번만 호출된다.
getStaticPaths
동적 라우팅으로 페이지를 동적으로 생성할 때 특정 페이지를 정적으로 생성하고 싶을 때 사용한다.
ex) /pages/boards/[id].jsx
- 특정 게시물만 생성하는 게 좋다.
- ex) 공지사항
getServerSideProps
- Next.js는 에서 반환된 데이터를 사용하여 각 요청에서 이 페이지를 미리 렌더링 합니다
- 서버 측 렌더링은 정적 생성보다 성능이 느리기 때문에 절대적으로 필요한 경우에만 사용하십시오.
어떨 때 SSR을 쓰는지
- SSR : 항상 최신 상태를 유지해야 하는 경우 (요청에 따라 응답해야 할 내용이 시시각각 변함)
- 매 요청마다 달라지는 화면이면서 서버에서 미리 렌더링 시키고자 한다면 사용
- SSG : 제품의 상세 페이지같은 변할일이 거의 없는 문서
- 정적 문서로 충분한 화면이면서 빠른 HTML 문서 반환이 필요하다면 사용
- 따라서 SSR. 즉, 서버 측에서 미리 렌더링 해주는 것은 맞지만
- Build Time때 할 것인지, (ssg)
- Runtime때 할 것인지(SSR)
- 결정짓는 것은 개발자가 정해야 한다.
자문자답
Q. 그렇다면 지금 하고 있는 프로젝트는 SSR을 하는가
A. No, 서버에서 SSG로 빌드시의 생성된 페이지를 제공하는 것이지 SSR 기능을 사용한 것은 아니다,
서버에서 HTML을 만들어주는 것은 모두 SSR이라고 착각해서 했던 고민이다.
따지자면 페이지를 SSG방식으로 생성한 것이다.
Q. getServerSideProps만 사용한 게 SSR인가?
A. hmm... SSG는 서버가 이미 생성된 것을 반환해주는 것이니까 큰 범위에서는 SSR이라고는 할 수 있을 것 같다 하지만 Next.js에서 제공하는 getServerSideProps을 사용했을 때가 SSR방식을 사용했다이고 SSG는 SSG라고 말해야할 것 같다.
Q. getSeverSideProps를 사용하지 않는데 해당 프로젝트를 Next.js로 선정한 이유는?
A.
- 프레임워크인 Next.js를 경험하고 싶었다.
- 자동으로 라우팅 하는 기능이 좋다.
- page를 정적으로 생성해줘 SEO에 좋다
- SSG로 사전에 렌더링 된 page를 반환해주니 초기 렌더링 속도가 빠르다.
결론
- Next.js는 기본으로 정적 페이지를 생성해주는 프레임워크
- pre-render의 의미와 SSG, SSR의 차이를 알게 되었다, 그냥 서버에서 생성해주니까 SSR인 줄 알았는데 엄밀히 말하면 SSG였다는 것을…
- SSG와 SSR 모두 서버 측에서 미리 렌더링 해주는 것은 맞지만 Build Time때 할 것인지(ssg), Runtime때 할 것인지(SSR) 결정짓는 것은 개발자가 정해야 한다.
- SSR과 SSG 모두 SEO와 초기 렌더링 성능에 대한 장점이 있다.
- 자주 업데이트되고 SEO를 원한다면 SSR로 페이지를 사전 렌더링 하는 것이 맞다
- 정적이고 SEO를 원한다면 SSG로 페이지를 사전 렌더링 하는 것이 맞다.
- 팀원의 의견인 “getServerSideProps를 사용하지 않으니 SSR을 하고 있는 것은 아니다.”라는 말이 정답이다. 현재 프로젝트는 SSG기능 만 사용한 것이다.
역시나 알면 알수록 알게 많아지는 웹 개발
ref
https://watermelonlike.tistory.com/entry/Nextjs-나는-그저-SSR인줄만-알고-있었다#새로-알게된-것
https://tsh.io/blog/ssr-vs-ssg-in-nextjs/
'Frontend' 카테고리의 다른 글
| styled-component로 GlobalStyle 정의하기 (0) | 2023.04.04 |
|---|---|
| 디바운싱과 쓰로틀링 (0) | 2022.11.26 |
| 프론트엔드 면접 경험 (0) | 2022.11.16 |
| [JS] this란? (0) | 2022.08.23 |
| [JS] 화살표 함수를 사용하는 이유 (0) | 2022.08.16 |
