SSR(Server Side Rendering) & CSR
많이 듣던 단어인데..
자바스크립트를 처음 공부하고 있을 때, 남들이 리엑트를 쓴다고 하고 또 리엑트를 활용하면 좀 더 쉽게 화면단을 그릴 수 있다고 해서 약간 조급한 마음으로 자바스크립트를 공부했던 기억이 난다.
당시에 리엑트에 대해서 잘 몰랐으니, 사람들이 왜 리엑트를 사용하는지 잘 알 수 없었고, 그냥 전세계 사람들이 가장 많이 사용하는 라이브러리 라는 정보만을 가지고 있었다. 무엇인가 편리한 것이 있게지 싶어 넘어갔었을 때, 이해도 못하고 넘어갔었던 부분이 바로 SPA이다. 물론 지금도 완전히 이해한것은 아니니, 다시 돌아보는 지금 시점에서 한번 더 알아가보자 라는 마음으로 블로그를 작성해야겠다 마음먹었다.
SPA(Single Page Application)
우선 왜 SPA 가 나오게 됬는지 파악을 해볼 필요가 있다. 현대 웹 사이트에서 다루는 데이터의 양은 당연하게도 어마어마하며, 데이터의 양은 늘어났지만, 사용자가 웹 사이트를 이용할 시 항상 쾌적한 환경을 제공할 필요성을 느끼게 된다. 다른 말로 하자면 웹사이트의 반응이 빠르게 이루어져야 한다는 점이다.
예를 들어서 하나의 웹사이트가 있다 가정해보자.
예시는 트위터이지만, 마치 예전의 웹사이트라 가정할 때 여기서 피드 부분에 좋아요 버튼을 클릭할 시 어떠한 일이 벌어졌는지 기억을 되돌아 보자. 화면이 깜빡거리면서 다음 좋아요 숫자가 늘어난 화면이 나타나지 않았는가? 깊게 들어가기 전이라도 눈치를 챌 수 있겠지만, 웹 사이트 내 동적인 변화가 들어가는 순간 서버에서는 기존의 화면을 변경된 요청과 함께 다시 작성하여 html 및 javascript 로 페이지를 구성하여 브라우저에게 전달한다. 즉, 좋아요 숫자가 1씩 증가할 때마다 페이지를 새로 작성하여 브라우저에 전송을 하는것이다. 듣기만 해도 비효율적이지 않는가?
(다행이 이후 ajax 가 나온 이후 http 통신으로 데이터 전송 후 결과물을 받아와서 특정 부분만을 변경하라고 javascript 에 명령을 줄 수 있게 되는 명령형 프로그래밍이 가능해졌지만, 명령형이다 보니 일일히 프로그래밍 해야하는 번거로움이 있다)
이러한 현상에서 누구나 생각할 것이, 변화된 부분만 업데이트된다면 훨씬 효율적이고, 속도면에서도 빠르지 않을까? 상상할 것이다. 다만 문제는 여기서 끝나지 않는다.
시대는 더욱 변화하여 단순히 웹 사이트뿐 아니라 모바일용 웹 사이트 및 안드로이드, ios 같은 환경에서도 페이지를 렌더링 해야 했기에, 각각의 상황에 따른 웹 페이지를 매번 서버가 작성하여 보내주어야 했다. 기존에 pc 용 웹 사이트만을 다루면 되었던 서버에 업무가 훨씬 많이 증가하게 된 상황이 된 것이다.
그나마 안드로이드 및 IOS 의 경우 데이터를 전송받게 되면 자체적으로 화면을 랜더링 할 수 있다. 여기서 사람들은 더 생각하여 만일 다른환경에서도 이와 같은 절차가 가능하다면, 좀 더 효율적으로 페이지를 랜더링 할 수 있지 않을까 고민을 하게 된다.
앞서 좋아요를 클릭하게 되어 데이터를 변경 하라고 서버에 요청을 하였다. 서버는 그 요청을 받아 변경된 데이터를 기반으로 페이지를 생성하였다 하였는데, 만일 서버에서 변경된 데이터만을 전달 할 때, 브라우저에서 화면을 그려낼 수 있다면? 즉, 변화된 부분에 대해 서버에 업데이트 요청을 보내고 서버에서 이를 받아 업데이트 된 데이터를 전달만 하면, 브라우저가 알아서 페이지를 변경시키는 것이다. 페이지를 변경시키는 것은 javascript 이니 이를 활용한 강력한 라이브러리나 프레임워크가 있다면 가능하다 생각하여 만들어진 것들이 우리가 흔히 들었던 React, vue, angular 이다.
위 3가지 프레임워크 혹 라이브러리는 SPA(single page application) 프레임워크라고도 불린다. 사실 개념은 위에서 설명한 것과 동일하다. 요점은 페이지를 새로 리로드 시킬 필요가 없다는 점이다. 그저 처음 화면이 나타날 때 모든 정적 리소스를 단 한번만 다운로드 한 후 새로운 페이지나 혹은 위 좋아요 같이 변경된 데이터를 화면에 반영하고 싶을 때, 서버에 요청하여 데이터만을 JSON 형식으로 전달받아 변경할 부분만 브라우저에서 알아서 랜더링 해주기 때문에 단일 페이지에서 페이지 이동이 없어도 화면은 변경된 데이터를 반영할 수 있게 되는 것이다.
비유를 해보자면, 이전의 전통적인 화면 전환 방식은 음식점에서 손님이 메뉴판에서 음식을 주문하거나 그때그때 매뉴를 추가할 시 주방에서 요리를 열심히 완성해서 제공해준다면, SPA 방식은 마치 삼겹살 집에서 고기를 직접 구워먹는 것이라고 생각하면 이해가 더 잘 될 것이다.
이렇게 작동을 하게 된다면 마치 어플리케이션을 사용하듯이 활용을 하게 된다. 부드럽게 화면이 전환되고 반응성이나 사용성이 당연하게도 크게 증가하게 된다. 이렇듯 SPA 의 핵심 가치라면 사용자 경험(UX) 향상에 있다. 결국은 사용자가 쓰기 편하고 불편함이 없어야 하기에 기존 방식보다 확실히 향상되었다 기대할 수 있겠다.
다만 이러한 SPA 또한 구조적인 단점을 지니고 있다. 대표적인 단점이라 뽑히는 점은 크게 2가지인데,
- 초기 구동 속도
- SEO(검색엔진 최적화)이슈
를 둘 수 있겠다.
첫번째 단점은 향상되는 기능에 비한다면 큰 단점이라고 하기는 어려울 것이다. 다만 두번째 단점은 사실 많은 기업들이 신경을 쓰는 부분인데 어느 기업이나 사이트에서던지 사용자에게 자신의 재화나 서비스가 노출이 잘 되도록 해야하기 때문이다. 이러한 문제가 발생하는 이유들 중에는 우선 SPA 의 경우 페이지의 이동을 자바스크립트가 구현하기 때문에 기존의 크롤러들은 이를 읽지 못한다는 점에 있었다. 즉 URL이 변경이 되질 않아 history를 관리할 수 없다는 문제점이 있었고, 다른 문제로는 단일 페이지이다 보니, meta data 역시 기존방식처럼 html 이 변경되는 것이 아니기 때문에 모든 페이지에 동일한 meta data 를 삽입하게 되는 상황이 발생한다.
물론 역시 개발자들은 이러한 문제를 그대로 놔둘리가 없다. 시대적 흐름에 따라 SPA 는 필요하게 되었고, 이에 대한 단점을 해결하기 위해서 상황에 따른 방법을 제시하였는데,
- SSR(Server Side Rendering)
- 동적 렌더링(Dynamic Rendering)
- history API
3가지 방법을 통해서 SEO문제를 해결하려 하였다.
3번째 history API의 경우 어떠한 상황이던지 적용해야 하는 부분이고, 이는 페이지가 실제로 리로드 되지 않더라도 페이지가 변경되었을 때 URL 주소를 부여해 줄 수 있다. 앞서서 URL 의 변경이 되지 않아 문제가 되던 부분에 대한 해결책이라 생각할 수 있겠다. history 관리를 위해 각 페이지는 브라우저 주소창에서 구별할 수 있는 유일한 URL 을 소유했어야 하는데 이를 해결해주기 때문이다. (라우팅에 대해서는 추후에 좀 더 자세히 살펴봐야겠다..)
나머지 2개의 방법은 SSR, CSR 과 관련이 있는데, 최근 프론트엔드 단에서 언급되어지는 SSR 에 대해서 CSR 과 비교하여 살펴 보겠다.
SSR(Server Side Rendering) & CSR(Client Side Rendering)
위에서 언급하였듯이 사람들은 하나의 이벤트가 웹사이트에서 발생하였을 때, 그 일부분에만 변화를 주고 싶어하였고 그로인하여 기존의 SSR 방식에서 CSR 방식을 선호하게 되었다. 여기서 SSR(Server Side Rendering) 은 예전 웹사이트가 화면을 렌더링 할 때 사용하던 방식으로, 말 그대로 서버에서 각각의 페이지를 랜더링해서 보내주는 형식이다. (요즘의 기술로 착각을 하고 있었다..)
사람들이 느끼는 SSR 방식에서의 고민거리는 결국 앞에서 언급하였듯이 사용자 경험에 있다. 더 빠른 사용과 부드러운 반응을 주기 위해, 효율적으로 변화하는 부분만 서버에 요청하여 업데이트를 하기 원하였고, 그로 인해 jqeury 를 통한 CSR(Client Side Rendering)이 도입되게 된다.
말 그대로다. 클라이언트 단에서 화면을 렌더링 하겠다는 것이다. 자바스크립트를 기반으로 말이다.
CSR 에선 화면이 처음으로 렌더링 되어질 때, 클라이언트가 화면을 렌더링 할 수 있도록 기본 HTML 을 포함 모든 javascript 파일을 받아오게 된다. 이후 이를 바탕으로 화면을 렌더링 하게 되며, 만일 화면내에 이벤트가 발생할 시 javascript 를 기반으로(AJAX) 화면을 업데이트 하게 된다.
왜 CSR 방식은 한계점이 있는것일까?
자바스크립트로 일부분만 업데이트 시켜 화면을 렌더링 하는 방식의 CSR로 인해 사람들은 앞에서 설명한 SPA 에 관심을 가지기 시작한다. 하나의 페이지에서 마치 다른페이지를 이동하는 것 처럼(리엑트에서는 Routing) 표현하면서 마치 어플리케이션 환경의 경험을 선사하기때문에 속도면에서 훨씬 빨라졌기에, 당연히 사람들은 만족하였다.
허나 어느 기술에서나 장단점은 존재하기에, 위 SPA 에서 언급하였듯이 SEO 최적화에서도 문제점을 보이기도 하였으며, 그 외 데이터 캐싱문제, 초기 화면 로딩속도가 길다는 단점들이 존재한다. 위에서 검색최적화에 대한 설명을 하였고, 초기 화면 로딩 속도에 관하여 살펴보자면, 위 삽도에서 알 수 있듯이 첫 화면의 렌더링 되는대까지의 시간이 오래걸리게 되는데, 이는 화면을 구동하기에 필요한 모든 javascript 로직 및 프레임워크, 라이브러리를 일단 전부를 다 받아오기 때문이다. 이후 작동하는 이벤트들은 받아온 로직들을 통해서 빠른 속도의 반응을 보여주지만, 어찌되었던 첫 화면의 로딩이 길어지기에 사용자 경험에 있어서 약점으로 작용할 수 있다. 사실.. 어찌보면 정말로 이 단점만 있다고 한다면 큰것이 아닐수도 있겠지만, 다른 단점들까지 존재를 하게되니 이쯤되면 개발자들은 고민을 하기 시작하게 될 만하다.
그렇다고 SSR 을 그대로 사용하자니..
서버에서 화면 하나하나를 다 렌더링 시켜서 보내주는 방식에서는 사실 첫 로딩때 모든 화면을 전송할 필요가 없다. 즉, 클라이언트에서 요청한 화면만 그대로 랜더시켜서 보내주면 되기에 위 첫 화면 로딩시간의 문제점은 발생하지 않는다. 또한 SEO 문제 역시 완성된 HTML 을 전송시켜 화면에 랜더 하는것이니 역시나 문제점을 보여주지 않는다. 허나 사용자가 늘어날 수록 서버의 과부하가 심해질 가능성이 있다는 점, 그리고 무엇보다 이미 경험해버린 CSR 의 빠른 반응속도는 포기하기에는 너무 아쉽다.
추가로 TTV(Time To Viewable), TTI(Time To Interactable) 를 따져보더라도 CSR 과 달리 SSR 방식은 첫 화면이 잘 렌더링 된 시간과(TTV) 이후 화면에서의 동작성,이벤트 반응(TTI)에는 시간차가 발생하게 된다. 왜냐하면 화면을 서버에서 전송받을 때는 HTML 을 받게 되고 이후 Javascript 파일을 받게 되기에, 그 전에 화면을 동작시키려 한다면 당연히 반응하지 않는다.
두 가지 방식에 장단점이 존재하기에, 이를 해결하는 방식을 고민한 끝에, 저마다의 방식들을 찾아가게 되었다.
CSR + SSR
두 가지 장점을 모두 가지고 온다면...
가장 좋은 방법이라 한다면, 결국 2가지 방식의 장점을 취하고 이를 통해 단점을 없애는 과정을 따라간다면, 정답에 가까워질 것이다. 과거로 그대로 돌아가기에는 현 시점에서는 분명 과거의 방식이 한계점이 있기에 새로운 방식을 개발하고 연구했던 것 아니겠는가?
우리가 알 수 있듯이 React 는 CSR 을 기반으로 하는 SPA 라이브러리 이다. 기존 CSR 의 문제점인 첫 화면의 로딩시간, SEO 최적화의 문제점을 개선하기 위해서는, 즉, 모든 문제점을 만족시키기 위해서는 기본적으로 첫 화면이 렌더링 될 때 SSR 의 방식을 따른다면, 위 2가지의 문제점을 해결할 수 있게 된다.
이후 만일 웹 사이트내에 동작 이벤트가 발생할 시 기존의 CSR 방식을 사용하게 된다면 이전부터 기대해왔던 빠른 반응속도를 함께 얻을 수 있게 된다. 이를 도와주는 프레임워크가 바로 Next.js 다. (추후에 설치방법 및 실제 사용기를 적어볼 예정)
이 외에도 Gatsby.js 와 React 를 연동하여도 SSR 을 도입할 수 있으며, 추후 이보다 더 좋은 방식들도 나타날 것이라 생각이 든다.
참고문헌 및 출처
https://www.ascentkorea.com/seo-for-spa/
SPA의 SEO, 어떻게 해야할까?
SPA란 서버로부터 새로운 페이지를 불러오지 않고 현재의 페이지를 동적으로 다시 작성함으로써 사용자와 소통하는 웹 애플리케이션이나 웹사이트를 말합니다. SPA를 SEO하기 위해서는 다음과 같
www.ascentkorea.com
SPA & Routing | PoiemaWeb
단일 페이지 애플리케이션(Single Page Application, SPA)는 모던 웹의 패러다임이다. SPA는 기본적으로 단일 페이지로 구성되며 기존의 서버 사이드 렌더링과 비교할 때, 배포가 간단하며 네이티브 앱과
poiemaweb.com
https://www.youtube.com/watch?v=hy3mji0XuMw
https://www.youtube.com/watch?v=5W72UHb-9iI&t=95s
https://www.youtube.com/watch?v=iZ9csAfU5Os