프론트엔드 개발을 하면서 pre-rendering에 대해서 고민해본 적이 있으시겠죠..!

화면을 어디서 그리는지, 인터렉션의 횟수가 많은지, SEO를 고려해야할지 등등 여러 문서를 찾아봐도 저는 잘 모르겠더라구요..! 다들 비슷한 문장들을 조합해서 적은 듯한 기분이라 같은 말만 되풀이되풀이되풀이 되는 것이 답답했습니다. 여전히 풀리지 않은 의문들이 있어 이곳에 정리해보고 피드백을 받아보고 싶습니다. :)

1. 사전 지식 정리

너무 깊지 않게, 필요한 내용만 한 번 짚어보죠!

1-1. pre-rendering?

말그대로 페이지를 미리 렌더링한다는 말입니다. 일반적인 리액트를 예시로 들어보자면, 사용자가 페이지로 접속하고 화면을 그릴 때까지의 시간이 조금 깁니다. 이 로딩 속도를 개선하고 사용자 경험을 더 좋게 하기 위해서 많은 노력들이 있었죠!

1-2. TTV & TTI

• TTV = Time To View: 유저가 사이트를 볼 수 있는 타이밍
• TTI = Time To Interact: 유저가 인터렉트할 수 있는 타이밍

화면이 그려지고 유저가 확인할 수 있는 상태가 되는 시간을 TTV라고 말하며, 클릭을 비롯한 각종 인터렉션이 가능해지는 시간을 TTI라고 말합니다.
TTV보다 TTI가 늦다면 화면이 그려졌어도 유저는 페이지 내에서 아무런 활동을 할 수가 없습니다.

1-3. SEO

Search Engine Oprimization: 검색엔진최적화

홈페이지 제작시 검색엔진에 더 잘 노출되어 더 많은 유저가 접속할 수 있도록 하는 것은 서비스 성장에서 중요합니다. 웹크롤러는 웹을 돌아다니면서 html 문서들을 점검하면서 어떤 내용이 담겨있고, 어떤 것이 더 노출되면 좋을지에 대해서 검사합니다.

2. 렌더링 방식의 종류

가장 유명한 3가지 CSR과 SSG와 SSR에 대해서 알아보겠습니다!

본 게시물은 CSR, SSG, SSR의 차이를 구분하고 기준을 정하는 것에 초점을 맞추고 있습니다. 더 깊은 이야기가 궁금하신 분들 위해 역사의 흐름에 따라 잘 정리한 블로그가 있어 공유합니다 :)
[WEB] Client Side Rendering과 Server Side Rendering

2-1. CSR: Client Side Rendering

유저와의 티키타가가 잦은 경우 적합합니다.

유저가 사이트를 접속했을 때 처음 화면은 완전히 비어있는 상태입니다.CSR은 유저가 접속함과 동시에 해당 코드를 그제서야 들고오기 때문입니다. JS파일을 서버로부터 다운로드 받은 다음 필요한 데이터가 있으면 요청을 보내 가져옵니다. 그리고 동적 html을 생성해 사용자에게 화면을 보여줍니다.

그래서 CSR방식의 경우, 초기 로딩 속도는 느릴 수 있지만 렌더링 후에는 부드러운 사용자 경험을 제공할 수 있습니다. url이 바뀌어도 html을 생성하는 것이 아니라 클라이언트에서 처리해 보여주기 때문입니다. 또한, JS 사용이 가능한 동적 html을 생성해 보여주기 때문에 화면이 보여지고 사용자는 바로 인터렉션이 가능해집니다. 하지만, 번들사이즈가 커지면 로딩 속도가 현저히 느려질 수 있어 tree-shaking과 code-splitting을 신경써야합니다. 그리고 미리 html을 만들어두는 것이 아니라 요청이 들어온 다음 html을 생성하는 방식이기 때문에 검색엔진최적화(이하 SEO) 대응이 어렵습니다.

CSR 체크 리스트

• 검색엔진에 노출되지 않아도되는(않아야하는) 페이지인가?
• 유저와의 인터렉션이 잦은가?
• 화면 업데이트/렌더링이 잦은가?
• 초기 로딩이 조금 느리더라도 부드러운 사용자 경험이 중요한가?

2-2. SSR: Server Side Rendering

비교적 인터렉션이 적고 데이터가 요청마다 한 번만 처리되어도 충분한 경우에 적합합니다.

CSR이 가진 문제점(초기 로딩속도, 번들 사이즈, SEO)을 개선할 방법을 찾던 중, 과거의 static site으로 다시 돌아간 SSR 방식이 등장했습니다. 프론트엔드 개발자로서 최근에는 CSR보다 더 자주 듣는 단어일지도 모르겠습니다. 클라이언트에서 화면을 구성하는 CSR과 달리 SSR은 서버에서 html을 만들어 제공합니다. 유저가 사이트에 접속하면, 서버에서 필요한 데이터를 모두 가져와 html을 만들어 제공합니다. 하지만 데이터가 채워진 html 문서를 화면에 띄운 다음 JS를 다운받기 때문에 렌더링과 동시에 인터렉션할 수는 없습니다. 요청마다 서버로부터 문서를 받아오기 때문에 상대적으로 과부하에 걸리기 쉽습니다. 하지만 모든 내용이 html에 담겨져있으므로 SEO 대응이 가능합니다.

SSR 체크 리스트

• 검색엔진 노출이 필요한 페이지인가?
• 사용자의 요청에 따라 고정되지 않은 데이터를 불러와야하는가?
  (= 화면 구성에 유저마다 다른 데이터 패치가 필요한가)
• 렌더링 후 사용자와의 즉각 인터렉션보다 화면 구성을 보여주는 것이 우선되는가?
• 너무 잦은 인터렉션은 없는가?

2-3. SSG: Static Site Generation

업데이트가 적거나 고정된 데이터를 사용하는 페이지에 적합합니다.

build 시 고정된 데이터들을 모두 담은 정적 html 파일을 생성하여 재활용합니다. pre-render에 필요한 페이지의 개수만큼 정적파일이 생성됩니다. 가령, 블로그의 게시물이 10개가 있고, 그 페이지를 모두 SSG로 렌더링하게 되면, build 시 10개의 html 파일이 생성됩니다. 때문에, 너무 많은 수의 페이지가 생성되어야하거나, 데이터가 자주 업데이트되는 페이지에는 적합하지 않습니다.

react framework인 Next.js의 공식문서에서는 SSG 방식을 권장하고 있습니다. CSR & SSR과 비교했을 때 렌딩 속도도 빠르고, 굳이 업데이트가 잦지 않은 페이지에 대해서 불필요한 통신과 리렌더링을 줄여주기 때문입니다. 웹사이트 생성의 근본방식으로 돌아간듯한 방법..!

SSG 체크 리스트

• 업데이트가 없거나 현저히 적은가?
• 생성되는 정적파일의 개수가 너무 많지는 않은가?

2-4. ISR: Incremental Static Regeneration

SSG의 단점을 보완한 방식으로, revalidate가 필요한 SSG 페이지에 적합합니다.

SSG는 정적 페이지를 생성하여 보여줍니다. 그래서 데이터의 변화가 적거나 없는 페이지에 적합한 방식입니다. ISR도 SSG처럼 build 시 구성된 데이터를 기반으로 페이지를 작성하고 보여줍니다. 하지만 직접 build를 하지 않으면 변함이 없는 SSG와는 달리, ISR은 설정된 시간이 지나면 자동으로 re-build하고, 데이터를 업데이트(revalidate)합니다. SSG와 마찬가지로 getStaticProps를 가질 수 있는데, revalidate 옵션으로 시간을 설정하면 그 주기에 맞추어 서버 사이드 데이터를 업데이트합니다. 페이지 방문자가 없으면 업데이트는 진행하지 않습니다만, 누구든 방문하면 데이터가 업데이트됩니다. 따라서 A 방문자가 페이지를 방문했다가 이탈하고 B가 다녀간 후 A가 다시 돌아왔을 때, A 방문자는 B의 방문으로 인해 변화된 페이지를 보게 됩니다.

ISR 체크 리스트

• 페이지의 방문자의 수요에 맞추어 업데이트가 필요한가?
• revalidate에서 업데이트 되는 데이터의 양이 너무 많지는 않은가?

3. 맺는말

하나의 프로젝트 내에서도 페이지마다의 특성을 이해하고 올바른 방식으로 렌더링하는 것이 매우 중요하다고 생각합니다. "요즈음 SSR이 대세래!" 라는 식의 이유로 도입하기에는 각각의 장단점이 너무 명확하기 때문에 주의해야합니다. 또한, CSR에서 SSR방식으로 변경할 때, 어떤 리스크를 지게 될지, 그것을 감당할 만큼 가치있는 변경일지에 대해서 생각해보아야합니다.

렌더링 3대장 CSR, SSR, SSG에 대해서 저처럼 삽질하시는 분들에게 도움이 되었으면 좋겠습니다. 또한, 제가 잘못된 내용을 기재했거나, 오해의 소지가 다분한 워딩이 있다면 댓글로 알려주시면 감사하겠습니다!