CSR, SSR 그리고 SPA 정리

SPA(Single Page Application)에 대해 대략적으로만 알던 내용들을 정리해보고자 한다. SPA와 함께 CSR(Client Side Rendering), SSR(Server Side Rendering) 도 정리하겠다.

SPA :

기존의 웹은 서버사이드 렌더링 방식(SSR)으로 서버로부터 새로운 페이지를 불러왔었다. 하지만 점점 웹에서 더 많은 정보를 제공하고, 모바일 기기를 통한 웹 애플리케이션 접속도 증가하면서 속도 저하로 이어지게 되었다. 그래서 SPA가 등장하는데 SPA는 최초 한 번 페이지 전체를 로드한 후 동적으로 필요한 데이터만을 변경해서 사용할 수 있는 웹 애플리케이션으로 기본적으로 클라이언트 사이드 렌더링 방식(CSR)이다. (하지만 SPA가 무조건 CSR인 것은 아니다.)

SPA 라우팅:

기본적인 SPA는 CSR 방식을 사용하여 필요한 부분만 새로 보여주기 때문에 URL이 바뀌지 않아 히스토리 관리가 어려워질 수 있다.

기존의 웹은 html의 link태그의 href를 통해 주소를 바꾸고 해당 리소스를 서버에 요청한 후 서버로부터 완전한 리소스를 응답으로 받는다. 이때에는 각 페이지마다 고유의 URL이 존재하여 history관리 및 SEO (검색엔진 최적화) 대응에 문제가 없다. 하지만 SPA에서는 주소가 바뀌지 않는다. 그래서 SPA에서는 location.hash와 HTML5의 history API를 통해서 히스토리를 관리할 수 있다. (더 자세한 내용은 여기로)

CSR(Client Side Rendering) :

클라이언트 사이드 렌더링에서는 HTML을 그리는 역할은 클라이언트 측의 자바스크립트가 수행한다. 즉, 서버는 클라이언트가 요청한 부분에 대해 JSON 데이터를 응답으로 보내주고, 클라이언트는 이 데이터를 받아 동적으로 렌더링 하여 사용자들에게 보여주게 된다.

[ 장점 ]

서버에서 필요한 부분만 요청하기 때문에 서버의 부담이 덜하다.
첫 로딩만 기다리면 동적으로 빠르게 렌더링 되기 때문에 사용자 경험(UX)이 좋다.

[ 단점 ]

초기 구동 속도가 느리다.
-> 초기에 모든 리소스를 받아오기 때문이다. (페이지를 읽는 시간+ js를 읽는 시간 + js가 화면을 그리는 시간)
검색엔진 최적화 (SEO)에 약하다.
-> 대부분의 검색엔진 크롤러, 봇들이 자바스크립트 파일을 실행시키지 못하기 때문이다. (구글의 검색엔진은 자바스크립트 엔진이 내장되어서 가능하다.) 그래서 HTML에서만 콘텐츠를 수집하게 되어 클라이언트 사이드로 렌더링 되는 페이지를 빈 페이지로 인식하게 되기 때문이다. (이를 보완할 수 있는 방법들이 있다고 하여 좀 더 찾아보고 정리하여 추가할 예정이다.)

SSR(Server Side Rendering) :

서버 사이드 렌더링에서는 사용자가 페이지를 요청할 때마다 서버에서 렌더링을 하여 완성된 HTML을 가져온다. 그래서 새로운 페이지를 요청할 때마다 새로고침을 하게 된다.