웹 페이지 렌더링 방식은 크게 아래 세가지와 같다.
- 정적 컨텐츠
- MVC와 템플릿 엔진: 동적인 요소가 서버사이드에서 완료되어 클라이언트에는 완성된 페이지가 전달
- API: json 데이터를 서버에서 클라이언트로 내려주고, 클라이언트에서 페이지 완성 (CSR)
세 가지 방식의 장단점을 따지기 위해서는 아래의 개념을 숙지하고 있어야한다.
SEO: Search Engine Optimization
SSR: Server Side Rendering
- 장점
- 빠른 페이지 로딩 속도
- SEO 가능
- 단점
- Blinking Issue: 갱신시 페이지 전체 받아와야됨
- 서버 과부하
- TTV와 TTI의 갭
*Time to view, Time to interact
CSR: Client Side Rendering
- 장점
- TTV와 TTI의 갭이 짧음 (거의 보는 즉시 사용 가능)
- 단점
- 사용자가 페이지를 완성해야하므로 시간이 걸린다.
- SEO 불가
서치엔진 옵티마이제이션을 위해서는 서버에서 클라이언트로 온전한 html 페이지를 내려줘야한다.
이를 위해 Spring에서는 템플릿 변환 엔진으로 Thymeleaf, Freemarker, Mustache, Groovy 등을 사용해주고 있다.
하지만 SEO이 굳이 필요한 상황이 아니라면, CSR을 활용하여 컴포넌트 기반 라이브러리 프레임워크를 쓰는 것이 자유도가 높고, UI개발할 때에도 편하며 유지보수도 하기 좋다.
개발할 때 CSR과 SSR의 개념 없이 무작정 개발을 진행한다면 캐시같은 것들을 적용할 때 문제가 생길 수 있으며, 최신 개발 트랜드는 SSR을 적용한 클라이언트 서버를 별도로 두는 것이다.
또한 정적페이지를 클라이언트에 보내주며, 동적인 요소도 추가해서 보내주는 개념이 있다. 이것을 SSG(Static Site Generation)이라고 한다.
SSG의 예로는 다음과 같은 것들이 있다.
Gatsby
React는 CSR에 최적화되어 있는 라이브러리지만 Gatsby 라이브러리와 함께 사용하면 리액트로 만든 웹앱을 정적으로 웹페이지를 미리 생성해두고 서버에 배포할 수 있다.
이렇게 만들어진 페이지들은 정적으로 보이지만, 추가적으로 서버에서 데이터를 받아오거나 동적인 로직들을 자바스크립트 파일을 통해 충분히 추가할 수 있다.
Next.js
Next.js는 강력한 서버 사이드 렌더링을 지원하는 라이브러리였는데, 요즘은 SSG도 지원하고 CSR과 SSR을 섞어서 더 강력하고 유연하게 목적에 맞게 사용할 수 있게 지원해준다.
참고 블로그: https://ctdlog.tistory.com/46
