Next.js - SSG , SSR
SSR Next의 핵심요소 중 하나인 Search Engine Optimization은 웹페이지가
검색 상위 노출이 될 수 구현하는 하나의 전략 기술이다.
주로 Next에서는 SSG(Static Stie Generation) , SSR(Server Side Rendering) 를 이용하여 SEO를 최적화 시킨다.
아무리 React 기반의 프레임워크라 하여도 React 처럼 클라이언트에서 useEffect를 사용하여 서버데이터를 가져오면 Next.js의 장점중 하나인 SSR에 불리함을 갖게된다.
SSR은 서버에서 랜더링 한 이후 클라이언트에게 전달되게 되는데 useEffect는 CSR형식으로 서버에버 빈페이지가 넘어온 이후에 랜더링 되는 형식이다.
useEffect로 데이터를 불러오는데 왜 SEO가 없냐고 물어본다면
1. 서버 페이지 빌드 후 클라이언트 전달
2. 클라이언트 랜더링 useEffect실행 <--이시점에서 데이터를 불러오게된다
Next.js에서 useEffect를 사용한다면 서버 페이지 빌드 이후에 클라이언트에서 데이터를 불러오게 됨으로써 서버 랜더링 시에 데이터가 없는 상태로 전달되게 된다.
빈 페이지로 빌드 되기 때문에 React의 경우 Root div만 존재하기에 콘텐츠가 비어있는 페이지가 전달되기 때문에 당연하게
SEO에 불리 할 수 밖에 없다.
이로써 발생되는 사이드 이펙트는 SEO의 이점이 사라진다는 것이다.
Next.js를 사용하는 이유 중 하나가 SSR방식으로 검색 엔진 최적화가 주 목적인데 핵심이 사라지게 되는
아주 큰 패널티가 주어진다.
SEO가 유리한 방식은 무조건 서버에서 페이지가 만들어져야 하는 것이 조건이다.
이렇게 SEO에는 SSG(Static Stie Generation) , SSR(Server Side Rendering) 방식이 유리하다.
SSG은 2가지의 방식으로 나눌수 있는데 동적생성이아닌 하드코딩된 웹페이지와 getStaticProps 함수를 사용한 페이지로
나눌 수 있다.
Next의 getStaticProps는 웹페이지 빌드 타임에 서버에서 요청을 하고 해당 데이터를 먼저 불러온 이후 불러온 데이터를 컴포넌트 props로 전달하여 페이지를 빌드한 이후 클라이언트에 전송한다.
실행 방식에는 차이가 있지만 최종 결과적으로는 동일하다.
둘다 정적으로 페이지가 서버에서 완성이 되기에 미리 준비된 상태가 되는 것이다.
getServerSideProps은 SSR 방식으로 사용자가 페이지를 요청 할 때마다 서버는 실시간으로 랜더링 하여 클라이언트에게 전달한다.
전부 좋아보이지만 SSG 방식의 단점 중하나는 정적 데이터라는 것이다.
SSG는 서버에 변경되지 않도록 배포된 페이지이다. 이는 사용자가 페이지 이동 간에 DB의 데이터가 변경되거나 하여도 빌드된 시점의 페이지를 전달해주게 된다.
SSR과 비교하자면 SSR은 사용자가 요청이 있을때마다 서버에 데이터로 다시 페이지를 갱신하여 전달한다.
즉, 늘 최신상태로 유지한다는 것, SSG는 다시 강조하지만 변경되지 않는 페이지를 말하는 것이다.
초기 빌드시에 지정된 데이터가 재 배포 되지 않으면 변경되지 않는다.
이 점을 보완하려면 revalidate 프로퍼티를 사용하여 주기적 데이터 갱신을 할 수 있다.
revalidate 프로퍼티는는 주기적으로 갱신 시간을 지정할 수있는데
예로 revalidate : 10 이라고 한다면 10초 마다 페이지를 빌드한다.
사용자가 이용을 하고있는데 갱신해버리는 것이 아닌 서버에 배포되어있는 페이지의 데이터 내용을 갱신하여 SSG페이지로 새로 빌드한다는 것이다.
이로써 사용자는 현재 페이지에서 작업 이후 다른 페이지로 이동하거나
새로고침하면 최근에 갱신된 페이지를 볼 수 있게 된다.
Udemy React with Reduxt, next.js, typescript 를 듣고 생각대로 정리한 포스팅 입니다.
