도입 배경

SPA의 시대부터 쭈욱 알아보쟈 ㅎㅎ

SPA의 등장

(single-page-application) 단일 페이지 애플리케이션으로, 현재의 페이지를 동적으로 작성함으로써 사용자와 소통하는 웹 애플리케이션이다. 연속되는 페이지 간의 사용자 경험을 향상시키고, 웹 애플리케이션이 데스크톱 애플리케이션처럼 동작하도록 도와준다.

• 1998년 XMLHTMLRequest의 등장
• HTML문서 전체가 아니라 JSON과 같은 포맷으로 서버에서 원하는 데이터만 받아 오는 것이 가능.
• 이렇게 받아온 데이터를 js를 활용하여 동적으로 html요소를 생성하고 페이지 업데이트

2005년 이같은 방식을 AJAX라는 이름으로 부른다

• 구글의 GMAIL, MAPS가 이러한 AJAX방식을 사용하여 만들어짐.
• 사용자는 한 페이지 내에서 머무르면서 서버에 필요한 데이터를 요청.
• 부분적으로 업데이트 하면서 사용자로 하여금 웹 어플리케이션을 사용하는 듯한 느낌을 들게 해준다.

이러한 SPA 트렌드 + 컴퓨터 성능의 향상 + JS의 표준화(React,Angular,Vue 등장) = CSR의 시대!

CSR

client-side-rendering, 쉽게말해 client단에서 다 한다!

• server에서 index.html파일을 client에 보내줌

• client는 server에 app.js파일을 요청해 다운로드 받게됨

• 이 js파일에 우리가 필요로 하는 라이브러리,로직,프레임워크 소스코드등이 모두 포함

• 추가로 필요한 데이터는 server에 요청해 JSON 형태로 받아옴

• app.js + JSON = 동적으로 html생성해 사용자에게 노출.

CSR의 단점

1. 사용자가 첫 화면을 보기까지 오랜 시간이 걸릴 수 있다. ( js파일을 다운받는데 시간이 오래걸릴 수록...)

2. SEO의 효율이 떨어진다!

   • 구글,네이버 등의 검색엔진들은 웹사이트의 HTML을 훓으면서 검색엔진에 등록.(title, description, link 등)
   • 하지만 CSR 방식의 HTML은 대부분 텅텅 비어있다.(대부분의 정보가 JS파일에 들어있기 때문!)
   • 구글은 많이 개선되었다고 하지만 여전히 비효율적!

3. 요러한 단점이 SSR의 등장을 야기.

SSR

server-side-rendering, 쉽게말해 이번엔 서버단에서 다 할래!!

• 웹사이트 접속

• server는 필요한 정보들을 모두 HTML + 이를 동적으로 제어할 Javascript와 함께 client에 전달.

• client단에서 이를 받아와 바아로 사용자에게 노출 가능.

SSR의 장점

• 페이지 로딩 FAST
• SEO 효율성 UP! (모든 정보가 HTML에 담겨있기 때문)

SSR의 단점

1. 옛날 static 사이트에서 발생했던 blinking 현상 발생
   • 사용자가 'click' 하면 전체 웹사이트를 다시 서버에서 받아옴.
   • 나쁜 사용감!!
2. server 과부하
   • 사용자가 많고, click할때마다 server에 데이터를 요청.
   • server는 요청을 받을 때 마다 이를 html을 만들어야 함 ㅠㅠ
3. TTV와 TTI의 불일치 ( 시간차 )

TTV vs TTI

time-to-view , time-to-interact

CSR의 타임라인

1. 사이트 접속

2. server에게서 index 파일 받아옴 (텅텅 비어서 사용자에게는 노출 x)

3. index 파일에 링크된 javscript 요청( 모든 페이지에 대한 정보가 담겨있음)

4. 동적으로 html을 생성할 수 있는 javascript파일을 받아옴

5. 이 순간부터 사용자에게 보여지게 되고, click도 할 수 있음

즉 CSR은 TTV (사용자가 웹사이트를 볼 수 있음)과 동시에 TTI (사용자가 웹사이트와 상호작용)가 가능하다!

SSR의 타임라인

1. 사이트 접속

2. server로 부터 이미 잘 만들어진 index.html파일을 받아온다.

3. 사용자는 이미 이때 부터 웹사이트 볼 수 있다. TTV

4. 하지만 아직 동적으로 제어 가능한 javscript는 받아오지 않음.

5. TTI (상호작용)이 아직 불가능

6. server에 이를 요청하고, 이를 받아와야만 TTV 가능.

즉 SSR은 TTV와 TTI 사이의 공백기간이 존재!

결론

CSR을 많이 사용한다면??

• server로 부터 받아오는 javscript를 어떻게 효율적으로 받아올 것인가.

• 어떻게 더 잘게 쪼개서 사용자에게 필수적인 요소부터 보내줄 수 있을까 고민

SSR을 많이 사용한다면??

• 사용자가 보고 상호작용 할 수 있는, 즉 TTV와 TTI의 공백을 어떻게 더 줄일 수 있을까?

• 어떻게 사용자에게 더 나은 경험을 제공할 수 있을지. ( UI/UX 측면에서 )

---

CSR과 SSR을 함께 사용하는 SSG(static-site-generation)도 있다는데 이 부분도 공부해서 포스팅 해봐야 겠다. (Gatsby , Next.js) 🧐

참고자료 : [드림코딩],[어서 와, SSR은 처음이지? - 도입편]을 참고하여 정리한 글입니다.