[TIL]2022.11.19 서버사이드 랜더링 (SPA? CSR? SSR?)

1990년대중반까지

Static Sites

서버에 잘 만들어진 HTML이 있음.

사용자가 접속하면 HTML을 받아와서 보여주는 형식.

페이지에서 다른 링크를 클릭하면 HTML을 다시 처음부터 다 받아와야하기에 사용성이 떨어짐

 

1996 <iframe> 등장. 문서내에 또다른 문서를 담을 수 있음.

페이지내에서 부분적으로 문서를 받아와서 업데이트 할 수 있게끔 가능. 지금도 간혹 쓰임.

 

1998년~ <XMLHttpRequest> API가 개발됨.

HTML 전체가 아니라 JSON과 같은 포멧으로 서버에서 가볍게 필요한 데이터만 받아올 수 있게됨.

JS를 이용해서 동적으로 HTML요소를 생성해서 페이지에 업데이트하는 방식.

↓ 이러한 방식이 공식적인 이름을 가지게 됨.

2005년 AJAX

GOOGLE에서도 Gmail, GoogleMap과 같은 웹 어플리케이션을 만들어냄.

이것이 바로 지금 널리 쓰이는 SPA!! (Single Page Application)

사용자가 한 페이지에 머무르면서 필요한 데이터만 서버에서 받아와 부분적으로 업데이트 하게됨.

하나의 어플리케이션을 사용하듯이 웹 사이트에서도 사용성이 조금씩 좋아지게됨!

SPA트랜드붐과 사용자들의 PC성능의 상향평준화로 많은 것들을 무리 없이 처리할 수 있게되고,

JS도 표준화가 잘 되어짐에 따라 강력한 커뮤니티를 바탕으로 Angular, React, Vue와 같은 프레임 워크들이 등장하며 CSR! Client Side Rendering ! 탄생 !

클라이언트측에서 모든 걸 다 처리하는 걸 말함.

 

서버에서 인덱스라는 html파일을 클라이언트에 보내주면 csr에서 사용되는 가장 추상적이고 심플한 html 예제를 보면 body안에는 아이디 루트만 달랑 하나만 들어 있고 어플리케이션에 필요한 자바스크립트의 링크만 들어 있음.

html 은 텅텅 비어있기 때문에 빈 화면만 보이고 다시 링크된 어플리케이션 자바스크립트를 서버로부터 다운로드 받게 되는데 이 자바스크립트에는 우리 어플리케이션에서 필요한 로직들 뿐만 아니라 어플리케이션에서 구동하는 프레임워크와  라이브러리의 소스코드들도 다 포함이 되어 있음.

 

그렇기 때문에 굉장히 사이즈가 커서 다운로드 받는 데도 시간이 필요함. 추가로 필요한 것이 있다면 서버에 요청해서 데이터를 받아온 다음에 이것들을 기반으로 해서 동적으로 html을 생성해서 드디어 사용자에게 최종적인 어플리케이션을 보여주게됨.

이런 클라이언트 사이드 랜더링(CSR)의 큰 문제점으로는 사용자가 첫 화면을 보기까지 시간이 오래 걸릴 수 있다는 것과 썩 좋지 않은 SEO를 꼽을 수 있음

 

 

 SEO란 Search Engine Optimization !

구글 네이버와 같은 검색엔진들(Web crawlers)은 서버에 등록된 웹사이트를 하나하나 돌아다니면서(크롤링) 웹 사이트의 HTML문서를 분석해서 검색엔진에 등록해두게 되고, 사용자가 검색할 때 웹사이트를 빠르게 검색할 수 있게 도와주는데, CSR에서 사용되어지고 있는 HTML의 바디는 텅텅 비어져있기 때문에 검색엔진들이 CSR로 작성된 웹페이지를 분석하는 데 많은 어려움을 겪고 있고 점차 개선이 되고 있긴 하지만 아직도 SEO가 좋지 않은 상황임.

 

이러한 CSR의 과도한 문제점들 때문에 1990년 중반즈음에 Static Sites에서 영감을 받은 SSR(Server Side Rendering)이 도입되게됨 !

 

SSR은 클라이언트에서 모든 것을 처리하던 방식과는 다르게,

사용자가 웹 사이트에 접속하면 서버에서 필요한 데이터를 모두 가져와서 HTML파일을 만들게 되고 이렇게 만들어진 HTML파일을 동적으로 어느 정도 제어할 수 있는 소스코드와 함께 클라이언트에게 보내 주게 됨.

그러면 클라이언트측에서는 잘 만들어진 HTML문서를 받아 와서 바로 사용자에게 보여줄 수 있게 되는 것 !

 

이런 SSR을 이용하게 되면 CSR을 사용했을 때 보다 첫 번째 페이지로딩이 빨라지는 장점이 있고, 두 번째로는 모든 컨텐츠가 HTML에 담겨 있기 때문에 조금 더 효율적인 SEO를 할 수 있다 !

 

 

그럼 이런 SSR이 모든 것에 솔루션이 될 수 있느냐? 그건 아니다 !

SSR에도 큰 문제점이 존재한다 !

첫번째로는 Static Sites에서도 발생했든 blinking(깜빡임) 이슈가 여전히 존재함 !

사용자가 링크를 클릭하게 되면 전체 웹사이트를 다시 서버에서 받아오는 것과 동일하기 때문에 썩 좋지 않은 User Experience를 겪을 수 있고 서버에 과부하가 걸리기 쉽다.

특히 사용자가 많은 제품일수록 사용자가 클릭을 할 때마다 서버에 요청해서 서버에서 필요한 데이터를 가지고 와서 HTML을 만들어야 하므로 서버에 과부하가 걸리기 쉽다. 가장 치명적인 세번째 단점 ! 사용자가 빠르게 웹사이트를 확인할 수는 있지만 동적으로 데이터를 처리하는 자바스크립트를 아직 다운로드 받지 못해서 여기 저기 클릭했는데 반응이 없는 경우가 발생할 수 있다 ! TTV (Time To View), TTI(Time To Interact) 정말 중요함 !

 

 CSR과 SSR을 시간이 흘러가는 대로 분석해 보면 CSR은 사이트에 접속하게 되면 서버에게서 인덱스 파일을 받아오고 이 인덱스 파일은 텅텅 비어져 있기 때문에 사용자에게는 아무것도 보여주지 않고, 이 HTML파일에 링크되어 있는 웹사이트에서 필요한 모든 로직이 담겨 있는 자바스크립트를 요청하게 된다.

그리고 최종적으로 동적으로 HTML을 생성할 수 있는 웹어플리케이션 로직이 담긴 자바스크립트 파일을 받아오게 됨. 이 순간부터 웹사이트가 사용자에게 보여지게 되고 또 사용자가 클릭이 가능하게 됨.

즉, CSR은 TTV 사용자가 웹사이트를 볼 수 있음과 동시에 TTI 클릭을 하거나 Interaction이 가능하게 됨 !

 

반대로 SSR은 사이트에 접속을 하게 되면 서버에서 이미 잘 만들어진 인덱스 파일을 받아 오게 되고 사용자가 웹사이트를 볼 수 있음. 하지만 동적으로 제어할 수 있는 자바스크립트 파일을 받아 오지 않았으므로 사용자가 클릭을 해도 아무런 것도 처리를 할 수 없는 상태임. 그래서 최종적으로 자바스크립트 파일을 서버에서 받아 와야지만 그 때부터 사용자의 클릭을 처리할 수 있는 Interaction이 가능해진다 ! 그래서 Server Side Rendering은 사용자가 사이트를 볼 수 있는 시간과 실제로 일터렉션 할 수 있는 시간까지의 공백기간이 제법 길어지게 됨.

 

그래서 웹사이트의 성능을 분석할 때 TTV와 TTI도 중요한 매트릭으로 사용할 수 있는데, CSR을 정말 많이 사용하는 사람들이라면 우리가 최종적으로 번들링해서 사용자에게 보내주는 이 자바스크립트 파일을 어떻게 하면 효율적으로 많이 분할해서 첫 번째로 사용자가 보기 위해서 필요한 정말 필수적인 요소들만 보낼 수 있을지 고민해 보면 좋을 것!

 

SSR같은 경우에는 사용자가 보고 인터렉션하는 시간의 단차를 줄이기 위해 어떤 노력을 할 수 있을지, 우리가 어떻게 조금 더 매끄러운 UI와 UX를 제공할 수 있을지 고민해 보면 좋다 !

 

요즘에는 CSR 또는 SSR만을 고집해서 사용하기 보다는 SSG(Static Site Generation)도 있다 !

React 같은 경우에는 CSR에 특화된 라이브러리이지만 Gatsby라는 라이브러리와 함께 사용하면 리액트로 만든 웹어플리케이션을 정적으로 웹페이지 생성을 미리 해두어 서버에 배포해 놓을 수 있음.

이렇게 만들어진 웹사이트들은 모두 정적인 것도 아니다 ! 추가적으로 데이터를 서버에서 받아오거나 동적으로 처리해야 하는 로직이 있다면 자바스크립트 파일을 함께 가지고 있을 수 있기 때문에 동적인 요소도 충분히 추가 할 수 있다 !

 

개츠비 다음으로 NEXT.JS 많이 사용됨!

Next.JS는 강력한 SSR을 지원하는 라이브러리였는데 요즈음에는 SSG도 지원을 하고 CSR과 SSR을 잘 섞어서 조금 더 강력하고 유연하게 우리의 목적에 맞게 상요할 수 있도록 지원하고 있다 !

 

 

 

출처 : https://youtu.be/iZ9csAfU5Os