SSR, CSR, SSG

드림코딩 Elly 님 SSR, CSR, SSG

 

👍 완전 흐름에 맞게 잘 정리되어 있는 유튜브 🚀 여기 나온 내용만 우선 쭉 정리해보겠다 💡

 

 

✔  Static Site

- 최초의 웹 사이트는 모두 Static Site. 서버에 이미 만들어져, 배포되어 있는 HTML 문서를 받아와서 보여준다. 다시 서버에서 HTML 문서를 받아와서 페이지 전체가 업데이트 되어야 한다

 

✔  IFrame

- Document 내에 또 다른 Document 를 담을 수 있는 <iframe> 태그가 도입되어, 페이지 내에서 부분적으로 문서를 받아와서 업데이트 할 수 있게 된다

 

✔  AJAX

- XMLHttpRequest API (fetchAPI 의 원조) 가 개발되어서 HTML 문서 전체가 아니라 JSON 과 같은 format 으로 서버에서 가볍게 필요한 data 만 받아올 수 있게 된다

- 그 data 를 JS 를 이용해서 동적으로 HTML 요소를 생성해서 page 에 업데이트하는 방식 → 공식적인 AJAX

 

✔  SPA

- 사용자가 한 페이지 내에서 머무르면서 필요한 데이터를 서버에서 받아와서 부분적으로만 업데이트 한다. 웹사이트에서도 사용성이 좋아지게 된다

 

✔  CSR

- JS 도 표준화가 잘 되어짐에 따라 CSR 시대, Client 측에서 다 해먹는 것

- 서버에서 index.html 을 Client 에 보내주면, HTML 은 텅 비어있기 때문에 처음에 접속하면 빈 화면만 보이고, 링크된 JS 파일을 다운로드 받는다

• JS 파일에는 App 에서 필요한 로직들, App 을 구동하는 프레임워크 / 라이브러리 소스코드들도 다 포함돼 있다
• 사이즈가 굉장히 커서 다운로드 받는데 시간이 소요된다

 

- 추가적으로 필요한 데이터가 있다면 서버에 요청해서 받아온 후 이걸 기반으로 동적으로 HTML 을 생성해서 사용자에게 최종 어플리케이션을 보여준다

 

🎈  CSR 의 단점

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

 

 

✔  SEO

- 검색 엔진들은 서버에 등록된 웹사이트들을 돌아다니면서, 웹사이트의 HTML 문서를 분석해서

• title, description 이 이렇게 있으니까 이런 검색어로 검색될 수 있는 웹사이트구나
• 이런 링크들이 있으니까 이것도 검색엔진에 등록해야 겠어

 

라고 판단하면서 검색할 때 웹사이트를 빠르게 검색할 수 있게 도와준다

- CSR 로 작성된 HTML body 는 대부분 텅 비어있으므로 검색엔진들이 CSR 로 작성된 webpage 를 분석하기 어렵다

- 이런 문제점 때문에 SSR 이 도입된다

 

 

✔  SSR

- 웹 사이트에 접속하면 서버에서 필요한 데이터를 모두 가져와서 HTML 파일을 만들고, 잘 만들어진 HTML 파일을 동적으로 제어할 수 있는 소스코드와 함께 Client 에 보내준다

- Client 에서는 HTML 문서를 받아와서 바로 사용자에게 보여줄 수 있게 되는 것이다

 

 

🎈  SSR 사용 시, CSR 보다 장점

1. 첫 페이지 로딩이 빨라진다
2. 모든 컨텐츠가 Html 에 담겨있으므로 효율적인 SEO 를 할 수 있다

 

🎈  단점

1. Static site 에 존재했던 Blinking issue 가 존재한다. 썩 좋지않은 User experience
2. 서버에 과부하가 걸리기 쉽다. 사용자가 많은 제품일수록 사용자가 클릭할 때마다 서버에 요청해서 필요한 데이터를 가져와서 HTML 을 만들어야 하므로
3. need to wait before interacting 사용자가 빠르게 웹사이트를 확인할 수는 있지만, 동적으로 data 를 처리하는 JS 를 아직 download 받지 못해서 여기저기 클릭했는데 반응이 없는 경우가 발생할 수 있다

 

 

✔  TTV (Time To View) & TTI (Time To Interact)

 

- 웹사이트의 성능을 분석할 때 TTV, TTI 도 중요한 메트릭으로 사용할 수 있다

 

🎈  CSR

- 최초로 index.html 파일을 받아오고, 이 HTML 파일이 JS 파일을 요청해서, 모든 로직이 담긴 JS 파일을 받아온다

- 이 순간부터 웹 사이트가 사용자에게 보여지고, 클릭이 가능하다

- viewable / interactable 이 동시에 일어난다. TTV TTI 가 동시에

 

🎈  SSR
- 사이트에 접속하면 서버에서 이미 잘 만들어진 index 파일을 받아오고, 사용자가 웹사이트를 볼 수 있다 (viewable)

- 동적으로 제어할 수 있는 JS 파일은 받아오지 않았으므로 클릭해도 아무것도 처리할 수 없게 된다. JS 요청, JS 파일을 서버에서 받아와야지만 상호작용이 가능해진다 (interactable)

- 그래서 TTV 와 TTI 에 차이가 있다

 

 

고민해볼 지점

 

🎈  CSR

- 최종적으로 번들링해서 사용자에게 보내주는 JS 파일을 어떻게 하면 효율적으로 많이 분할해서 첫번째로 사용자가 보기위해서 필요한 정말 필수적인 아이만 보낼 수 있을지, Code Splitting 을 고민

 

🎈  SSR

- 사용자가 보고, interaction 하는 시간의 단차를 줄이기 위해 어떤 노력을 할 수 있을지

- 어떻게 조금 더 매끄러운 UI 와 UX 를 제공할 수 있을지 고민

 

 

✔  SSG

- React 는 Client Side Rendering 에 특화됐지만 Gatsby 와 함께 사용하면 React Web app 을 정적으로, 웹페이지 생성을 미리 해둬서 서버에 배포해놓을 수 있다

- 모두 다 정적이지는 않다

- 추가적으로 data 를 서버에서 받아오거나 동적으로 처리해야 되는 로직이 있다면, JS 파일을 함께 가지고 있을 수 있으므로 동적인 요소도 충분히 추가할 수 있다 

- React + Next.js 는 강력한 SSR 를 지원하는 라이브러리 였는데, 요즘에는 Static generation 도 지원하고 CSR 과 SSR 을 잘 섞어서 조금 더 강력하고 유연하게 목적에 맞게 사용하도록 지원하고 있다

- static generation, no pre-rendering, pre-rendering 

 

 

✔  Conclusion

- 우리 사이트는 정적인지 / 동적인지

- 서버에서 동적으로 data 를 받아오는지

- 얼마나 자주 / 얼마나 많은 사용자가 있는지에 따라 TTV / TTI 를 고려해 좀 더 유연하게 섞으면서 개발하도록~