📝 들어가기에 앞서
오늘은 몇 번이나 시도했지만 매번 마무리 짓지 못했던 SSR와 CSR을 정리하는 날이다!
솔직히 말하면 기저에서 작동하는 방식까지 모두 완벽하게 이해한 것은 아니다 🙄
그래서 아직 명료하지 않은 부분들이 많다.
또 내가 알고 있는 것들 중에 틀린 내용이 있지는 않을까 걱정스럽다.
하지만!
일단 지금 현재 내가 이해하고 있는 것들부터
하나씩하나씩 블로그에 적다보면 머릿속이 정리가 좀 될 것 같아서 이번 포스팅을 준비했다.
(물론 부족한 부분들은 나중에 다시 찾아와서 계속 채워나갈 예정이다.)
이번 시리즈 전체 구성은 시간의 흐름에 따른 웹 개발 트렌드(?)의 변화이다.
SSR -> Ajax의 등장 -> CSR -> SSG
이번 포스팅에서는 'SSR'과 'Ajax의 등장'에 대해서 다룰 것이고 목차는 아래와 같다.
0. Intro
1. SSR이란 무엇인가
2. SSR의 장점
3. SSR의 단점
4. XMLHttpRequest API와 ajax의 등장
자, 그럼 시작해보자!
0. Intro
(상상력이 조금 필요하다)
1990년대 중반까지 만들어진 웹 사이트들은 대부분 정적인(static) 웹 사이트들이었다.
요즘의 쇼핑몰이나 포탈 사이트를 상상하면 안되고 오직 정보만 쭈욱- 나열해 놓은 사이트들을 상상하면 된다.
이 당시에는 SSR 방식을 이용해서 페이지들을 렌더링했다.
1. SSR이란 무엇인가?
SSR은 Sever Side Redering의 약자이다.
(간단히 설명하자면)
서버에서 알아서 다 해주는 방식이다.😋
서버에 이미 잘~ 만들어진 HTML 문서들이 있다.
사용자가 사이트에 접속하면
브라우저는 서버에 있는 이 HTML 문서들을 받아와서 사용자에게 보여주기만 하면 된다.
아래와 같은 네비게이션이 있다고 생각해보자.
<nav>
<ul>
<li>
<a href="index.html">Home</a>
</li>
<li>
<a href="about.html">About</a>
</li>
<li>
<a href="services.html">Services</a>
</li>
<li>
<a href="login.html">Log in</a>
</li>
</ul>
</nav>
웹 사이트의 About 페이지에 있던 사용자가 Log in 페이지로 가기를 원해서 링크를 클릭하면?
href 어트리뷰트 값인 리소스의 경로가 URL의 path에 추가되어 브라우저 주소창에 나타난다.
그러면 브라우저가 해당 필요한 리소스(가령, login.html파일)를 서버에 요청한다.
이때 서버는 HTML로 화면을 표시하는데 부족함이 없는 완전한 리소스를 브라우저에게 보내준다.
브라우저는 서버가 보내준 HTML을 받아 렌더링한다.
이 과정에서 전체 페이지를 다시 렌더링하게 되므로 새로고침이 발생한다.
위의 그림을 이용해서 다시 설명해보자.
처음 사용자가 웹 사이트에 들어오면 브라우저가 서버한테 "리소스 보내줘~"하고 요청을 보낸다.
그러면 서버는 이미 완성된 리소스들을 브라우저에게 넘겨준다.
브라우저는 그 리소스들을 이용해서 사용자에게 보여주기만 하면 된다.
만약에 사용자가 로그인 페이지로 가길 원하면
서버로부터 로그인 페이지에 필요한 리소스들을 모두 받아와서
페이지를 다시 리로드한다.
그러면 페이지가 새로고침이 되면서 로그인 페이지로 이동한다.
2. SSR 방식의 장점
- 초기 뷰(view) 로딩 속도
뷰(View)를 이미 서버에서 렌더링해서 가져오기 때문에 처음 페이지를 로딩할 때 시간이 오래 걸리지 않는다.
- 검색 엔진 최적화(SEO)
각 페이지마다 고유의 URL이 존재하므로 history 관리나 SEO 대응이 어렵지 않다.
3. SSR 방식의 단점
사실 단점은 이미 위에서 다 나왔다.
사용자가 페이지를 이동할 때마다 매번 리소스를 다운로드 받아서 페이지를 다시 렌더링 해야하는데
이 과정에서 물론 변경된 부분도 있겠지만 변경이 필요 없는 부분까지도 포함해서 페이지 전체를 업데이트 해야한다.
너무나 비효율적이다!
그리고 이 때마다 새로고침이 발생하여 화면이 깜빡이니(blinking) 사용자 경험에도 좋지 않다.
서버 입장에서도 매번 요청이 있을 때마다 모든 뷰를 준비해야 하니 사용자가 몰리면 과부하되기 쉽다.
4. XMLHttpRequest와 Ajax의 등장
이렇게 SSR이 지배적이던 와중에...
1998년 XMLHttpRequest라는 API가 개발되었다!
이 API를 이용하면 HTML 문서 전체가 아니라
JSON과 같은 포맷으로 서버에서 필요한 데이터만! 가볍게! 서버에서 받아올 수 있다.
(받아온 데이터는 자바스크립트를 이용해서 동적으로 HTML요소 생성 후 페이지에서 필요한 부분만 업데이트.)
그런데 이 당시에는 이 기술에 대해 특별히 주목하는 사람도 없고 조용히 지나갔는데...
약 8년이 지난 2006년...
위에서 말했던 기술이 Ajax(Asynchronous Javascript and XML)라는 공식적인 이름을 가지게 되고
구글에서 이 Ajax를 이용해 Gmail과 GoogleMaps와 같은 웹 애플리케이션을 만들어 세상에 보이기 시작했다.
과거에는 업데이트가 필요한 부분뿐만 아니라 업데이트가 필요하지 않은 부분까지 모두!!! 그러니까 페이지 전체가!! 리렌더링 되었다.
하지만 AJAX를 사용하여 서버에 필요한 리소스를 요청하면
브라우저에서 그 부분만 갱신해서 HTML을 완성해서 사용자에게 보여주게 된 것이다.
Ajax 덕분에 불필요한 리소스를 중복해서 받는 비효율성을 극복할 수 있게 되어 퍼포먼스 향상뿐만 아니라
새로고침이 필요 없는 부드러운 화면 전환으로 사용자 경험도 향상되었다.
이것이 현재 널리 쓰이고 있는 SPA의 시초라고 할 수 있겠다.
그럼 이제 다음 포스트에서 CSR을 이용한 SPA에 대해 더 자세히 알아보도록 하자!
참고한 사이트들
https://goodgid.github.io/Server-Side-Rendering-and-Client-Side-Rendering/
https://asfirstalways.tistory.com/244
https://d2.naver.com/helloworld/7804182
'웹개발상식' 카테고리의 다른 글
| SPA(Single Page Application)와 CSR(Client-Side Rendering) (0) | 2021.05.26 |
|---|
