Q. 웹 페이지 렌더링 방식 CSR, SSR, SSG 각각의 특징과 각 방식을 어떤 상황에 사용하면 좋을지 설명해 주세요.
SSR(Server Side Rendering)
웹 페이지를 제공하는 가장 흔한 방법이다. SSR의 장점은 다음과 같다.
1. 더 안전한 웹 애플리케이션
페이지를 서버에서 렌더링한다는 것은 쿠키 관리, 주요 API, 데이터 검증 등과 같은 작업을 서버에서 처리한다는 뜻이며, 중요한 데이터를 클라이언트에 노출할 필요가 없기 때문에 더 안전하다.
2. 더 뛰어난 웹 사이트 호환성
클라이언트 환경이 자바스크립트를 사용하지 못하거나 오래된 브라우저를 사용하더라도 웹 페이지를 제공할 수 있다.
3. 더 뛰어난 SEO
클라이언트에서 서버가 렌더링한 HTML 콘텐츠를 받기 때문에 봇이나 웹 크롤러 같은 검색 엔진 웹 문서 수집기가 페이지를 렌더링할 필요가 없다. 그 결과로 SEO 점수가 높아진다.
이러한 장점에도 있음에도 SSR이 늘 최적의 렌더링 전략이 아닌 경우가 있다. SSR을 사용하면 클라이너트가 요청할 때마다 페이지를 다시 렌더링할 수 있는 서버가 필요하기 때문이다. 또한 웹 앱을 서버에 배포한다면 다른 방식보다 SSR 애플리케이션이 더 많은 자원을 소모하고 더 많은 부하를 보이며 유지 보수 비용도 증가한다.
SSR을 사용할 경우 페이지에 대한 요청을 처리하는 시간이 길어진다는 문제도 있다. 페이지가 외부 API 또는 데이터 소스에 접근해야 한다면 해당 페이지를 렌더링할 때마다 API나 데이터 소스를 다시 요청하게 되기 때문이다. 또한, 브라우저 전용 API를 사용해야 하는 컴포넌트가 있다면 해당 컴포넌트를 반드시 브라우저에서 렌더링하도록 명시적으로 지정해줘야 한다.
CSR(Client Side Rendering)
CSR은 동적 웹 페이지를 만들 때 SSR보다 더 좋은 선택이다. 검색 엔진에 노출될 필요가 없는 페이지를 만드는 경우에는 웹 애플리케이션의 자바스크립트 코드를 먼저 다운로드한 다음 클라이언트에서 필요한 데이터를 직접 가져가도록 만든다. 서버 부하를 줄이고 애플리케이션을 더 쉽게 확장할 수 있다. 주요 이점은 다음과 같다.
1. 네이티브 애플리케이션처럼 느껴지는 웹 애플리케이션
전체 자바스크립트 번들을 다운로드한다는 것은 웹 애플리케이션이 렌더링할 모든 페이지가 이미 브라우저에 다운로드되어 있다는 뜻이다. 다른 페이지로 이동하면 서버에서 그 페이지에 해당하는 새로운 콘텐츠를 다운로드하지 않고 그냥 페이지의 콘텐츠를 새로운 것으로 바꾼다. 콘텐츠를 바꾸기 위해 페이지를 새로 고칠 필요가 없다는 의미이다.
2. 쉬운 페이지 전환
다른 페이지로의 이동이 가능하기에 페이지 간 전환에 멋진 효과를 쉽게 넣을 수 있다. 애니메이션을 방해할 요소가 없기 때문에 가능하다.
3. 지연된 로딩(lazy loading)과 성능
CSR을 사용하면 웹 앱에서는 최소로 필요한 HTML 마크업만 렌더링한다. 동적으로 요소를 생성하는 방식으로 동작한다.
4. 서버 부하 감소
전체 렌더링 과정이 브라우저에서 일어나기 때문에 서버가 할 일은 아주 간단한 HTML 페이지를 클라이언트에 전송하는 것뿐이다. 덕분에 서버리스 환경에서도 웹 앱을 제공할 수 있다.
하지만 이런 장점이 단점이 될 수도 있다. 서버는 간단한 HTML 페이지만 보내기 때문에 네트워크가 느린 환경에서는 전체 자바스크립트 코드와 CSS 파일을 받는 것에만 많은 시간이 소요될 수 있다. 그러는 동안 사용자들은 빈 페이지를 바라봐야한다. 또한 SEO에 좋지 않은 영향을 준다. 검색 엔진 봇들이 웹 앱의 페이지에 대한 정보를 수집하려 해도 빈 페이지로 보이기 때문이다.
SSG(Static Site Generate)
SSG는 일부 또는 전체 페이지를 빌드 시점에 미리 렌더링한다. 내용이 거의 변하지 않는 페이지는 정적 페이지 형태로 만들어서 제공하는 것이 더 좋다. 또한 리액트 라이드레이션 덕분에, 정적 페이지에서도 사용자와 웹 페이지 간의 상호 작용이 가능하다. SSG는 SSR 및 CSR과 비교했을 때 다음과 같은 이점이 있다.
1. 쉬운 확장
정적 페이지는 단순 HTML 파일이므로 CDN을 통해 파일을 제공하거나 캐시에 저장하기 쉽다. 직접 웹 서버에서 웹 애플리케이션을 제공하는 경우에도 정적 페이지는 별도의 연산없이 정적 자원 형태로 제공되기 때문에 서버에 부하를 거의 주지 않는다.
2. 뛰어난 성능
빌드 시점에 HTML 페이지를 미리 렌더링하기 때문에 페이지를 요청해도 클라이언트나 서버가 무언가를 처리할 필요가 없다. 웹 서버는 정적 파일을 보내기만 하고 클라이언트 브라우저는 파일을 받아서 표시만 하면 된다. 따라서 각 요청별로 발생할 수 있는 지연 시간을 최소화할 수 있다.
3. 더 안전한 API 요청
페이지 렌더링을 위해 웹 서버가 민감하고 중요한 데이터를 클라이언트로 보낼 필요가 없다. 외부 API를 호출하거나, 데이터 베이스에 접근하거나, 보호해야 할 데이터에 접근할 일이 없다. 필요한 모든 정보가 빌드 시점에 미리 페이지로 렌더링되어 있기 때문이다.
이처럼 SSG는 높은 확장성과 뛰어난 성능을 보이는 애플리케이션을 만들고 싶을 때 가장 좋은 방법이다. 하지만, 일단 웹 페이지를 만들고 나면 다음 배포 전까지 내용이 변하지 않는다는 문제도 있다. 정적으로 생성한 페이지는 빌드 시점에 미리 렌더링되어 정적 자원처럼 제공되기 때문에 작은 수정에도 필요한 데이터를 가져오고 정적 페이지를 다시 생성하는 과정을 반복해야 한다.
참고 글
https://young-taek.tistory.com/126
'프론트엔드 > Next.JS' 카테고리의 다른 글
Next.js 프로젝트 만들기 (0) | 2024.05.25 |
---|---|
Next.JS 타입 (0) | 2024.05.24 |
React 와 Next.js 비교 (0) | 2023.08.09 |
Next JS 오류 해결 (0) | 2023.08.02 |
미들웨어(middleware) (0) | 2023.07.24 |
댓글