SE0(Search Engine Optimization) 문제
아무래도 리액트나 뷰를 사용하면서, CSR을 할 지 SSR을 할 지 고민하게 되는 이유는 SEO때문이다. 물론 회사에서만 사용하는 CMS라면 신경쓸 필요가 없지만 공식 홈페이지와 같이 일반 사용자에게 검색되어야 하는 사이트라면 SEO 때문에 SSR에 대해 생각하게 된다.
사실 Google은 크롤러 안에 자바스크립트 엔진이 들어있어서 크게 문제될게 없지만, 네이버나 다음은 다르다. 왜냐면...그들은 자바스크립트를 해석할 수 있는 엔진이 없어서 빈 페이지로 인식할테니까!
렌더링 퍼포먼스 외적인 측면도 다루었다. 흔히 많이들 하는 오해가 CSR은 SEO가 잘 되지 않는다라는 것인데, 많은 크롤러들이 JavaScript를 지원하지 않기 때문에 발생한 오해다. Google Bot(크롤러)은 JavaScript를 지원하기 때문에 CSR 사이트도 SEO가 잘 된다. 특히, 최신 버전의 Google Bot은 ES2015 이상의 최신 JavaScript도 지원한다. 또한 Full SSR 없이도 메타 태그들을 잘 활용하면 SEO를 잘 지원할 수 있다.
https://hyunseob.github.io/2019/05/26/google-io-2019-day-3/
이를 해결하기 위해 SSR with Hydration 기법이 나왔는데, 대표적으로 React 진영의 Next.js와 Vue 진영의 Nuxt.js가 위 기법을 구현한 프레임 워크다.
즉 처음엔 서버사이드 렌더링을 하고, 그 후 다른 페이지들에선 클라이언트 사이드 렌더링을 이요하는 방식이다.
직접 SSR 구현? Next.js 사용?
현재 사이드 프로젝트로 진행 중인 서비스의 CMS 구현을 어느정도 마치고, 공식 홈페이지를 개발해야 하는 상황이다. 유명한 개발 블로거들은 직접 SSR을 구현하는게 낫다고 하는데, 세부설정이 불편하기 때문이라고... 그 세부설정이 뭔지 모르겠는데, 오늘 아침 개발자 카톡방에서 SSR 이야기가 나와서 살짝 운을 띄웠더니 버전 업 되면서 세부 설정이 없어도 된다고 하더라.
도대체 세부 설정이 뭐지?
여튼, 회서 공식홈페이지도 Next.js로 했었는데 잘 모른채로 사용했던지라 이번에는 꼼꼼히 세팅해 볼 생각이다.
간단하게 Next.js가 제공해주는 기능을 보고 넘어가자면
- 페이지 기반 라우팅 시스템 (동적 라우팅 지원)
- pre-rendering, 페이지별 정적파일 생성과 서버사이드 렌더링 지원
- 코드스플리팅
- prefetch(필요한 데이터를 미리 요청) 기능을 갖춘 클라이언트 사이드 라우팅
- CSS, Sass 기본 지원 및 다른 CSS-in-JS 라이브러리 지원
- HMR(Hot Module Replacement 지원
- API routes to build API endpoints with Serverless Funtions
- Fully extendable
음... 마지막 두개는 어떻게 이해하기 쉽게 해석 해야할 지 모르겠어서, 원문 그대로 남겨둔다.
여튼, 위와 같이 편한 기능을 제공하기에 특별한 이유가 ㅇ벗다면 사용하는게 나을 것 같다.
한가지 부련한 점이 있다면, 선택적 핫로딩이 안된다는 점...
