[Next.js] CSR과 비교하여 pre-rendering 쉽게 이해하기

이 글에서는 Next.js에서 중요한 개념인 Pre-Rendering에 대해서 알아보고자 합니다.

 

Rendering 과정

먼저, 사전 렌더링(pre-rendering)을 하지 않았을 때, 브라우저가 어떻게 화면을 렌더링 하는지에 대해 대략적으로 설명을 하고 사전 렌더링과의 차이점에 대해 정리해보고자 합니다. 만약, CSR방식에 대해 이미 익숙하다면 아래 CSR파트는 생략하셔도 무관합니다.

 

---

 

[ CSR ]

[[ 1 - React의 기본 동작 방식 ]]

일반적인 react Application은 CSR(Client Side Rendering) 방식으로 화면을 렌더링 합니다. 

 

CSR 방식에 대해 간단히 설명하자면, 아래 그림과 같습니다.

Client Side Rendering 방식

쉽게 말해서,

1. 가장 먼저 뼈대만 있는 HTML 파일을 서버로 부터 다운받고(이 HTML 파일에는 JS파일 링크가 포함되어 있습니다.),

2. JS파일을 다운 받은 뒤,

3. 브라우저에서 JS 파일을 실행시켜 필요한 데이터를 받아온 후(Fetch), 화면에 렌더해주는 방식입니다.

 

사실, 위 설명을 들었을 때, 뼈대만 있는 HTML이 무엇인지... 어떤 JS 파일을 실행 시킨다는 건지 잘 이해가 되지 않았습니다.

 

첨부된 아래 사진을 보며 천천히 설명 드리도록 하겠습니다. 

기본 리액트 앱 실행 화면 / 소스코드

 

위 첨부된 사진은 우리가 일반적으로 npx create-react-app 을 통해 실행 시켰을 때 가장 처음 볼 수 있는 매우 친숙한 화면입니다. 
즉, CSR 방식으로 렌더된 화면입니다.

 

여기서 보여 드리고 싶은 것은 화면의 소스코드 입니다.

body 태그안에 root id를 가진 div태그 하나만 존재한다는 것을 볼 수 있습니다.

이 점은 CSR이 SEO가 힘든 이유이기도 합니다. 구글과 같은 검색엔진에서는 이 처음 렌더되는 HTML을 기준으로 Search 결과를 제공하게 되는데, CSR에서는 안에 컨텐츠가 텅 비어 있기에 검색엔진에 탐지 되지 않게 됩니다.
( 소스코드가 사전 렌더링 방식과는 어떻게 다른지 아래 사진에서 살펴 봅시다.)

 

이게 바로 뼈대만 있는 HTML파일을 의미합니다. 

 

CSR 방식은 브라우저(Client Side)에서 JS파일을 실행시켜 이 뼈대만 있는 HTML 파일에 유저들에게 보여주고 싶은 컨텐트들을 넣어주는 방식으로 동작합니다.

 

---

 

[[ 2- JS 없는 CSR 방식 ]]

아직 JS파일을 실행시켜 안에 있는 컨텐츠들을 받아온다는게 와닿지 않는 분들이 있을 수 있습니다. 
그럼 chrome에서 JS를 disable 시킨 상태에서 해당 페이지에 접근해보도록 하겠습니다. 

 

JS없이 렌더링된 리액트 앱

참고로, Chrome에서 JS를 disable하는 것은

Settings > Preferences > Debugger > Disable javaScript 항목을 체크하여 적용 할 수 있습니다.

 

자, 똑같은 코드임에도 불구하고 에러 메시지가 나오는 페이지가 출력되는 것을 볼 수 있습니다. 
이는 뼈대 HTML소스코드를 받아 왔음에도, JS파일을 실행시키지 못해 안에 넣을 내용을 받아오지 못했기 때문입니다. 

 

자, 이제 리액트앱의 기본 렌더링 방식인 CSR방식이 어떻게 작동하는지 대략적으로 이해 했을 것입니다. 

 

그럼 사전 레더링 방식은 어떻게 다른지 알아보도록 하겠습니다.

 

---

 

[ Pre-Rendering ]

[[ 1. 사전 렌더링 방식 원리 && CSR과의 차이 ]]

사전 렌더링 방식의 원리는 간단합니다.

1. 뼈대만 있는 HTML이 아닌, 서버로부터 말그대로 사전에 렌더링된 HTML 파일을 받아와서 화면을 먼저 출력하고,

2. JS파일을 받아오는 과정(hydration)을 거치게 됩니다.

 

사전 렌더링 방식

 

아까 설명한 CSR방식을 생각해보면서 좀 더 이해해 봅시다.

정상적으로 작동하는 React 앱소스를 열어 봤을 때에도, CSR방식의 소스코드에는 root div 태그 하나만 존재 했습니다. 

이 부분을 기억하면서 아래 사진을 살펴 봅시다.

사전 렌더링 방식

위 사진은 Next.js 앱을 실행 시킨 뒤, 살펴 본 소스코드 입니다.

뼈대 HTML만 있는 것이 아닌, 화면을 보여주는 여러가지 태그들이 소스코드에 포함되어 있는 것을 볼 수 있습니다. 

이 점이 사전 렌더링 방식을 이용하게 될 경우, SEO가 용이한 이유 입니다. 

 

구글과 같은 검색엔진은 처음 렌더되는 HTML을 기준으로 탐색결과를 제공하게 되는데, CSR은 텅 비어 있는 것에 비해, 사전 렌더링 방식은 위 사진처럼 렌더링 되는 내용을 소스코드에 표시해주기 때문입니다.

 

그리고 이렇게 화면에 보여줄 내용들이 포함되어 있는 HTML파일을 우린 사전 렌더링된 HTML 파일이라고 부릅니다.

물론, 사전렌더링된 HTML역시 단순한 HTML 파일이기 때문에 단순히 이 파일만으로는 유저와의 상호작용(버튼 클릭, 데이터 요청, etc)이 불가능합니다. 

 

일단, 렌더링된 화면을 유저에게 보내 준 후, Next.js는 JS파일을 받아오고 실행시켜 유저와 상호작용이 가능한 상태가 됩니다. 

그리고 우리는 이렇게 유저와 상호작용이 가능한 상태가 되는 과정을 hydration 이라고 부릅니다.

 

hydration을 번역하면수화 즉, 수분이 공급되는 것을 의미합니다.
유저와 Interaction이 불가능한, 단순히 화면만 보여주던 메말라 있던 사전 렌더링된 HTML 파일에 
JS라는 수분이 공급되고, 비로소 유저와 상호작용을 가능하게 하는 과정이라고 이해하면 편할 것 같습니다.

 

여기까지 CSR과 Pre-rendering방식의 작동 방식의 차이에 대해 이해가 되었다면 좋겠습니다.

 

결론적으로, CSR방식과 Pre-rendring방식은 Server로 부터 처음에 뼈대 HTML만 받아 올지, 아니면 사전에 렌더링된 HTML파일을 받아올지에 그 차이가 있습니다. 

 

---

 

[[ 2. Pre-rendering 종류 ]]

Next.js에서는 이런 사전 렌더링 방식으로 다음과 같은 2가지 방식을 제공하고 있으며, 두가지 방식을 섞어서 사용도 가능합니다.

 

1. Static Generation(정적생성):
   추천되는 방식으로 build타임(npx build)에 HTML파일을 미리 생성해 놓고, 이를 요청이 있을 때마다 재사용 하는 방식입니다.
   빌드시, 미리 생성된 HTML파일을 CDN에 캐시해놓고, 유저의 요청이 있을 때마다 재사용 할 수 있어 성능적으로 매우 유리합니다.
   
   
2. Server-side Rendering(서버 사이드 렌더링): 
   요청이 있을 때마다, 필요한 HTML파일을 생성하는 방식입니다. 

참고로, 위에 언급한 것처럼 Next.js에서는 가능하다면 정적생성방식을 추천하고 있습니다. 
하지만, development환경에서 실행하는 경우(npm run dev), 항상 SSR방식으로 동작하게 됩니다. 

---

 

[[ 3. Pre-rendering의 장점 ]]

이미 장점에 대해 다 설명했지만, 마지막으로 정리해보도록 하겠습니다.

1. 기능적으로 작동하기 전에 미리 유저에게 화면을 보여 줄 수 있기에 UX를 향상 시킬 수 있다.
2. SEO(Search Engine Optimization)가 가능하다.
3. Next.js에서 정적생성 방식을 이용하는 경우, 매우 빠른 성능을 보여줄 수 있다.

 

이해하기 어렵거나, 잘못된 내용이 있다면 언제든지 댓글로 문의 남겨주시면 감사하겠습니다!