일반적으로 웹의 렌더링 방식은 크게 CSR(Client Side Rendering)과 SSR(Server Side Rendering)으로 나뉘고 이는 페이지를 클라이언트 사이드에서 그리는지, 서버에서 그리는지에 따라 정해진다.
하지만, Next.js의 렌더링 방식에 대해 학습을 하다보면 렌더링방식을 단순히 CSR과 SSR 두 가지 방식으로만 나누는 것이 아니라, 프로젝트에서 코드를 어떻게 짜는지에 따라 좀 더 세부적으로 나누어서 설명한다.
특히, SSR과 관련된 부분이 그러한데, App router 방식을 기준으로 Next.js에서 렌더링 방식이 어떻게 구분되고 어떻게 사용되는지, 그리고 일반적인 의미의 렌더링 방식과 비교하여 어떻게 다른지 등에 대해 학습하고 고민해보고자 글을 작성하게 되었다.
또한, Next.js 렌더링&배포&아키텍처 관련해서도 궁금한게 많았기 때문에 여러 궁금한 점들을 자세히 알아보면서 학습한 내용을 담았다.
*이 글의 내용은 대부분 App router를 기준으로 한다. 다만, Page router의 내용과 관련이 있는 부분만은 가볍게 짚고 넘어갈 예정.
일반적인 의미에서의 CSR과 SSR에 대해 알아보기에 앞서 주의할 점은, 이 CSR과 SSR 개념은 ‘렌더링’을 어디서하냐가 아니라 HTML이 어느시점에서 작성되고, 완성되어 있냐에서 차이가 난다는 것이다.
왜냐하면 ‘렌더링’이라는 용어는 실제로 브라우저가 웹사이트를 그리는 작업을 의미하므로, 이 용어의 본래 의미에 따르면 CSR이나 SSR이나 둘 다 브라우저가 렌더링을 담당하기 때문이다.
여기서 주의할 점은, 이 CSR과 SSR 개념은 ‘렌더링’을 어디서하냐가 아니라 HTML이 어느시점에서 작성되고, 완성되어 있냐에서 차이가 난다는 것이다.
왜냐하면 ‘렌더링’이라는 용어는 실제로 브라우저가 웹사이트를 그리는 작업을 의미하므로, 이 용어의 본래 의미에 따르면 CSR이나 SSR이나 둘 다 브라우저가 렌더링을 담당하기 때문이다.
사용자가 웹사이트에 접속하면, 서버는 거의 빈 HTML 파일과(리액트에서 사용하는 index.html을 생각하면 된다. js파일이 적용되지 않으면 그냥 뼈대만 존재한다.) 나머지 웹 리소스를 클라이언트로 보낸다.(JS, CSS 등)
그리고 브라우저는 js를 이 빈 HTML에 적용하면서 HTML을 채운다.
이 HTML을 채우는 시간은 SSR과 비교해서 초기로드를 느리게 만드는 원인이 된다.
이때 HTML을 채우는 동시에 웹사이트의 기능 관련 모든 것들이 적용되기에 웹사이트가 처음으로 사용자에게 보이는 시점부터 웹사이트는 바로 상호작용이 가능하다.(클릭, 여러 기능들)
이 또한 처음에 HTML만 있는 SSR이 눈으로 컨텐츠를 보이게 만들긴하지만 상호작용이 불가능한 것과 비교해서 차이점이라 볼 수 있다.