"서버 사이드 렌더링(SSR_Server Side Rendering)" with tutor.엘리

최신 웹 동향 트렌드

 

SPA / CSR / SSR / SSG / TTV / TTI 에 대해서 알아보자

 

📌 Static Sites (1990's 중반)

1990년 중반까지는 모두 다 Static Sites 였다.

서버에 이미 잘 만들어진 html 문서들이 있고, 사용자가 브라우저에서 헬로 닷컴과 같은 주소에 접속하면, 서버에 이미 배포되어져있는 html 문서를 받아와서 보여주는 형식이다.

 

(이미 서버에 html문서 다 존재. 주소 접속시 서버에 있는 html 문서 보여주기) => Static Sites

 

여기에서 한 가지 문제점이 나타나는데, 

 

페이지내에서 다른 링크를 클릭하면, 다시 서버에서 해당 페이지의 html 을 받아와서 페이지 전체가 업데이트 되어야한다. 즉, 사용성이 굉장히 떨어진다.

 

Static Sites

 

📌 iframe (1998년)

 

1996년, 문서 내에서 또 다른 문서를 담을 수 있는 iframe태그가 도입이 되었고, 이제는 페이지 내에서 부분적으로 문서를 받아와서 업데이트할수 있게 되었다.

 

현재도 간간히 쓰이고 있는 태그이다.

 

iframe 태그

 

📌 XmlhHttpRequest API

 

 

1998년, 우리가 많이 쓰고 있는 fetch API의 원조 XmlhHttpRequest API가 개발이 되어서 이제는 HTML 문서 전체가 아니라 JSON과 같은 포맷으로 서버에서 가볍게 필요한 데이터만 받아올 수 있게 되었다.

그 데이터를 자바스크립트를 이용해서 동적으로 HTML요소를 생성해서 페이지에 업데이트하는 방식이다.

 

XmlhHttpRequest API

📌 AJAX

2005년, 이러한 방식이 드디어 공식적인 AJAX라는 이름을 가지게 되었고, 구글에서도 AJAX를 이용해서 Gmail, GoogleMaps와 같이 우리가 많이 쓰고있는 웹 어플리케이션을 만들기 시작한다.

 

이것이 현재 널리 쓰이고 있는 SPA 싱글 페이지 어플리케이션이다.

 

사용자가 한 페이지에 머물르면서 필요한 데이터를 서버에서 받아와서 부분적으로만 업데이트를  하는 것이다.

이런 방식으로 하나의 어플리케이션을 사용하듯 웹 사이트에서도 사용성이 조금씩 좋아지게 된다.

 

AJAX

 

 

이런 SPA 트랜드 그리고 ① 사용자들의 PC성능이 점차 좋아지면서 많은 것들을 무리 없이 처리할 수 있게 되었다.

② 자바스크립트도 표준화가 잘 되어짐에 따라서, ③ 강력한 커뮤니티를 바탕으로 Angular, React, Vue와 같은 프레임워크가 나오게 되었고,  CSR (클라이언트 사이드 렌더링) 시대로 접어들게 되었다.

 

높아지는 사용자들의 PC성능, 자바스크립트 표준화, 다양한 프레임워크

 

⭐️ CSR (Client Side Rendering)

CSR

Client Side Rendering. "클라이언트 사이드 렌더링"이란 쉽게 이야기하면, "클라이언트 측에서 다 해 먹는 것을" 말한다.

 

- 서버에서 index라는 html파일을 클라이언트에 보내준다.

: CSR에서 사용되는 가장 추상적이고 심플한 HTML예제를 보면,  body안에는 아이디 루트만 달랑 하나 들어있고, 어플리케이션에서 필요한 자바스크립트의 링크만 들어가있다.

index.html

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

 

그렇기 때문에 굉장히 사이즈가 커서 다운로드를 받는 데 시간이 소요될 수 있다.

 

추가로 필요한 데이터가 있다면, 서버에 요청해서 데이터를 받아온 다음, 이것들을 기반으로 동적으로 HTML을 생성해 드디어 사용자에게 최종적인 어플리케이션을 보여주게 된다.

 

CSR

 

💥 CSR의 문제점

① 사용자가 첫 화면을 보기까지 시간이 오래 걸릴 수 있다는 점

 

초기화면 보기까지 오래 걸린다.

 

② 썩 좋지 않은 SEO(Search Engine Optimization)

: SEO란, '구글', '네이버'와 같은 검색엔진들은 서버에 등록된 웹 사이트를 하나하나씩 돌아다니면서 웹 사이트의 HTML문서를 분석해서 

 

기계 왈 : "아, 여기 HTML은 이런 타이틀과 디스크립션이 있으니까. 이런 검색어로 찾아줄 수 있는 웹사이트이군. 그리고 여기에 이런 링크들이 있으니까, 이것도 검색엔진에 등록해 놔야겠어." 

 

라고 판단해서 우리가 검색할 때 웹 사이트를 빠르게 검색할 수 있게 도와준다.

 

하지만, CSR에서 사용되어지고 있는 HTML바디는 대부분 텅텅 비어져있기 때문에, 검색엔진들이 CSR로 작성된 웹페이지를 분석하는데 많은 어려움을 겪는다.

구글에서는 조금 개선이 되었지만, 여전히 SEO가 좋지않다.

 

낮은 검색엔진 최적화

 

이러한 CSR의 과도한 문제점들 때문에, 우리가 1990년 중반쯤에 사용했던 Static Sites에서 영감을 받은 SSR. 서버 사이드 렌더링이 도입되게 되었다.

 

⭐️ SSR (Server Side Rendering)

 

이제 클라이언트에서 모든 것을 처리하는 방식(CSR) 과는 다르게 웹 사이트에 접속하면 이제 서버에서 필요한 데이터를 모두 가져와서 HTML파일을 만들게 되고 이렇게 만들어진 HTML파일을 동적으로 조금 제어할 수 있는 소스코드와 함께 클라이언트에게 보내주게 된다.

 

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

 

SSR (Server Side Rendering)

 

🌈 SSR의 장점

 

SSR의 장점으로는,

 

① CSR을 사용했을 때보다 첫 번째 페이지 로딩이 빨라진다는 장점이 있다.

 

첫 번째 페이지 로딩이 빠름

 

② 모든 컨텐츠가 HTML에 담겨져 있기 때문에 조금 더 효율적인 SEO를 할 수 있다.

 

좋은 검색 엔진 최적화

 

그렇다면 SSR이 모든 것에 솔루션이 되는 것인가? 그것 또한 아니다.

SSR도 큰 문제점이 존재한다.

 

💥 SSR의 문제점

 

SSR의 문제점으로는,

① Static Sites에서 발생했던 깜박임 이슈가 여전히 존재한다.

: 사용자가 클릭을 하게 되면, 전체적인 서버에서 받아오는 것과 동일하기 때문에 썩 좋지 않은 User Experience 를 겪을 수 있다.

 

깜빡임 이슈

 

② 서버에 과부하가 걸리기 쉽다. 특히 사용자가 많은 제품일수록, 사용자가 클릭을 할 때마다 서버에 요청해서 서버에서 필요한 데이터를 가지고와서 HTML을 만들어야 하므로 서버에 과부하가 걸리기 쉽다.

 

서버 과부하가 걸리기 쉽다

 

③ 가장 치명적인 단점으로는, 사용자가 빠르게 웹 사이트를 확인할 수는 있지만, 동적으로 데이터를 처리할 수 있는 자

바스크립트를 아직 다운로드 받지 못해서 여기저기 클릭을 했는데, 반응이 없는 경우가 발생할 수 있다.

 

클릭했지만 반응이 없는 오류 발생 (자바스크립트를 아직 다운 x)

 

: 이를 이해하기 위해서는

 

TTV (time to view)

TTI (time to interact)

 

이 두 가지를 잘 살펴봐야한다.

 

⭐️ TTV (time to view) vs TTI (time to interact)

 

CSR과 SSR을 시간이 흘러가는 순서대로 분석해보면

 

(CSR)

CSR 시간순

 

사이트 접속 -> 서버에서 인덱스 파일을 받아옴  -> 이 인덱스 파일을 텅텅 비어있기 때문에 사용자에게는 아무것도 보여주지 않고, 이 html파일에 링크되어져 있는 이 웹 사이트에서 필요한 모든 로직이 담겨져 있는 자바스크립트를 요청하게 된다. -> 그리고 최종적으로 동적으로 html을 생성할 수 있는 우리의 웹 어플리케이션 로직이 담긴 자바스크립트 파일을 받아온다. -> 이 순간부터 웹 사이트가 사용자에게 보여지게 되고, 또 사용자가 클릭이 가능해진다.

 

즉, CSR은 TTV사용자가 웹 사이트를 볼 수 있음과 동시에 TTI 클릭을 하거나 인터랙션이 가능해진다.

 

 

이와 달리,

 

(SSR)

SSR 시간순

 

사이트 접속 -> 서버에서 이미 잘 만들어진 인덱스 파일을 받아오고 사용자가 웹 사이트를 볼 수 있다. (하지만, 아직 동적으로 제어할 수 있는 자바스크립트 파일은 받아오지 않으므로 사용자가 클릭을 해도 아무런 것도 처리할 수 없다.) ->  그래서 최종적으로 자바스크립트 파일을 서버에서 받아와야하지만, 그 때부터 사용자의 클릭을 처리할 수 있는 인터랙션이 가능해진다.

 

즉, SSR은 사용자가 사이트를 볼 수 있는 시간과 실제로 인터랙션할 수 있는 시간의 공백기간이 꽤 긴편이다.

 

 

 

그래서 웹 사이트의 성능을 분석할 때 TTV 와 TTI도 중요한 매트릭으로 사용할 수 있는데,

 

CSR 에서 고민해봐야할 것

 

CSR을 정말 많이 사용하는 사람이라면 우리가 최종적으로 번들링해서 사용자에게 보내주는 자바스크립트 파일을 어떻게 하면 효율적으로 많이 분할해서 첫 번째로 사용자가 보기 위해서 필요한 정말 필수적인 아이만 보낼 수 있을지 고민하면 좋을 것이다.

 

=> "사용자가 봐야할 필수적인 요소들을 담아서 보내야 그나마 시간을 단축시킬 수 있다."

 

SSR에서 고민해봐야할 것

 

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

 

=> "사용자가 보고 자바스크립트를 통해서 상호작용하는 시간을 줄이기 위해서 어떻게 해야할까?"

 

 

⭐️ SSG (Static Site Generation)

 

 

요즘에는 꼭 CSR 또는 SSR만을 고집해서 시용하기보다는 SSG도 있다.

 

SSG. (Static Site Generation)는 리액트의 경우, 클라이언트 사이드 렌더링에 특화된 라이브러리지만, 개츠비라는 라이브러리와 함께 사용하면 리액트로 만든 웹 어플리케이션을 정적으로 웹 페이지 생성을 미리 해두어서 서버에 배포해놓을 수 있다.

 

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

 

 

 

개츠비 다음으로 리액트에서 많이 사용되는 것이 Next.js이다.

Next.js는 강력한 서버 사이드 렌더링을 지원하는 라이브러리였는데, 요즘에는 SSG도 지원을 하고 CSR과 SSR을 잘 섞어서 조금 더 강력하고 유연하게 우리의 목적에 맞게 사용할 수 있도록 지원을 해주고 있다.

 

 

SPA (Single Page Application)

CSR (Clinet Side Rendering)

SSR (Server Side Rendering)

SSG (Static Site Generation)

 

어떤 것이 최고다! 보다는 우리의 사이트는 정적인지, 동적인지 서버에서 동적으로 데이터를 받아 오는지 / 얼마나 자주, 얼마나 많은 사용자가 있는지에 따라서 TTV와 TTI를 고려해서 조금 더 유연하게 개발해 나가면된다.

 

📚 참고

www.youtube.com/watch?v=iZ9csAfU5Os&t=11s

"드림코딩 by 엘리" 님의동영상을 보고서 정리한 글임을 밝힙니다.