[Next.js] SSR 이해하기

Next.js 과제를 하다가 서버의 개념도 헷갈리고, 각 기능을 어떤 상황에서 왜 사용해야하는지 이해가 부족하다는 생각이 들었다.

과제 안내사항을 따라 필수 요소들을 구현하긴 했지만, 여전히 스스로 생각해서 구현하기는 어려울 것 같아 도전과제는 우선 미뤄두고 넥스트에서 이해가 안되는 부분을 공부해보기로했다.. 🥹

 

 

SSR이란?

✅ 개념

서버에서 웹페이지를 미리 만들어서 사용자에게 보내는 방식, CSR보다 향상된 SEO와 첫 화면 로딩 속도를 위해 사용된다.

 

✅ 렌더링 과정

 

1) 사용자가 서비스에 접속

2) 브라우저가 해당 페이지를 보내달라고 접속한 도메인으로 HTTP GET request

- 이 때 도메인이 바로 페이지를 렌더링해 보내줄 서버의 주소

- 서버는 클라이언트에서 request를 받아 데이터 페치 혹은 비즈니스 로직 등을 처리하고 response를 반환해주는 컴퓨터다

3) 서버는 필요에따라 database에 데이터를 요청하고, 그 데이터로 react를 실행해 html을 생성

4) react(라이브러리)의 동작으로 완성된 html을 클라이언트로 전송(GET 요청에대한 응답)

- 컴포넌트들의 return 문에 포함된 jsx, tsx 부분을 js -> html로 변환(string)

- return 문 외의 로직은 상호작용을 위해 js로 동작하는 부분으로 이 때 활성화되지 않음

5) 브라우저가 html을 받아 브라우저의 렌더링 과정을 거침

- 아직 사용자는 상호작용할 수 없음

6) 브라우저가 html을 파싱하며 필요한 script를 발견하면 서버에 이 js 번들 파일을 보내달라 요청

- 이 파일을 받아 hydration 과정을 거침

- 미리 렌더링된 html과 js 번들의 상태를 동기화하여 동적 상호작용을 활성화

- 페이지가 보여지는 시간 TTV, js까지 다 로딩해와서 인터렉션까지 걸리는 시간 TTI

 

✅ CSR 과정과 비교

CSR과 SSR은 렌더링 환경의 차이이고, 렌더링은 결국 라이브러리인 리액트의 함수를 실행하는 것

리액트를 이용해 html 결과물을 만들어내는 환경이 서버인지, 브라우저인지에서 차이가 있는 것이다

 

1) 브라우저가 서버로 요청을 보내고, 서버로부터 <div id='root'>가 있는 html 파일과 이 html 파일을 채우기 위한 js 번들 파일을 받는다

2) 브라우저가 js 파일을 받아 실행하며 #root 요소에 동적으로 컴포넌트들이 추가

3) 페이지가 화면에 렌더링되며 사용자는 상호작용이 가능

 

✅ 서버에서 렌더링된 페이지는 정적 페이지인가?

SSR로 생성된 페이지와 정적 페이지는 차이가 있다.

1) SSR로 생성된 페이지

- 서버에서 실시간으로 데이터를 가져와 구성하는 요구사항을 반영할 수 있으므로, 정적 콘텐츠를 포함해 동적 데이터도 포함 가능

 

2) 정적 페이지

- 빌드 시점에 미리 생성된 html 파일로, 별도의 렌더링 과정을 거치지 않고 html 파일이 그대로 사용자에게 제공됨

 

 

CSR과 SSR은 어떤 기준에 따라 결정해야할까?

next.js를 사용해도 모든 페이지가 서버에서 렌더링되는 것은 아니다.

'use client'를 명시하면 CSR을 사용할 수 있다.

도대체 어떨 때 클라이언트 컴포넌트를 사용해야하고, 어떨 때 서버 컴포넌트를 사용해야하는건지 의문이었는데 조금 정리가 된 것 같다

우선 두 방식 중 절대적인 방법은 없으며, 요구사항에 따라 결정하면 된다.

 

✅ 초기 페이지 로딩 속도가 중요한 경우

1) SSR

- 미리 렌더링된 html을 브라우저에 전달하므로 초기 로딩 속도가 빠르다

- 사용자가 완성된 콘텐츠를 빠르게 확인해야하는 경우 선택할 수 있다

- 초기 로딩시 빈 화면을 보며 기다려야하는 문제를 해결해 더 나은 사용자 경험을 제공할 수 있다

 

2) CSR

- 클라이언트에 js가 다운->실행 되어야 화면이 렌더링되기 때문에 초기 로딩속도가 느려질 수 있다

- 초기 로딩 시간이 조금 길어지더라도, 이후 페이지가 더 빠르게 동작하는 것이 중요한 경우 선택할 수 있다

 

✅ SEO를 고려해야하는 경우

1) SSR

- 서버에서 완성된 html을 전달하기 때문에, 검색엔진 크롤러가 완전한 html 페이지를 인덱싱할 수 있고 SEO에 유리하다

- 블로그, 쇼핑몰, 뉴스 등 빠른 검색 노출이 필요할 때 선택할 수 있다

 

2) CSR
- 브라우저에서 js가 실행된 후에 콘텐츠가 로드되기 때문에 검색엔진크롤러가 정상적으로 페이지를 인덱싱하지 못할 가능성이 높다

- 일부 최신 검색 엔진은 js를 처리할 수 있지만, 모든 검색 엔진이 js를 처리하지는 못함

 

✅ 동적 상호작용과 복잡한 클라이언트 로직이 필요한 경우

1) SSR

- 서버에서 동적 데이터를 제공하고, 페이지 로딩 후 상호작용을 위한 hydration이 필요

- hydration 완료 전까지는 상호작용이 불가능하기 때문에 복잡한 UI 상호작용이 있는 경우 다소 불편할 수 있다

- 상호작용이 간단하고, 초기 로딩이 더 중요한 서비스에서 사용할 수 있다 (블로그, 뉴스, 쇼핑몰 등)

 

2) CSR

- 복잡한 상호작용과 동적 UI를 실시간으로 처리하기에 적합

- 브라우저가 js로 UI를 관리하므로, 사용자의 동작에 더 빠르게 반응할 수 있다

- 대시보드, 채팅, 소셜 네트워크 등 복잡한 UI와 즉각적인 상호작용이 필요한 서비스에서 사용할 수 있다

 

✅ 데이터 최신화가 필요한 경우

1) SSR

- SSR도 실시간 데이터를 요청할 수 있지만, 서버 요청은 결국 비용이 필요한 일이므로 서버 요청이 많아지는 경우 성능에 부담이 있을 수 있다

- 서버에서 데이터를 미리 렌더링하므로, 페이지 로딩 시점의 최신 데이터를 받을 수 있지만 그 이후로는 클라이언트에서 다시 요청을 보내야 최신 데이터를 받을 수 있다

- 페이지 로딩 시점에 최신 데이터여야하고, 이후 큰 변동이 없는 경우 선택할 수 있다

 

2) CSR
- 실시간 데이터 반영에 적합하다

- API 요청을 클라이언트에서 직접 처리하고, 필요한 시점에 데이터를 다시 불러올 수 있다

- 페이지 로드 후 클라이언트 측에서 다시 실시간 데이터로 UI를 업데이트 할 수 있다

- 실시간으로 데이터가 자주 변동되는 서비스에서 선택할 수 있다 (실시간 대시보드, 주식, 채팅 등)

 

 

당장 과제가 눈앞에 있을 때는 구현에 급급했는데 한번 사용 목적과 과정을 정리해보니 훨씬 나은 것 같다!!!