SSR 와 SPA 그리고 New SSR

이번 포스트에서는 SSR 와 SPA 그리고 New SSR에 대해 알아보도록 하겠습니다.

Serve Side Rendering (이하 SSR) 방식은 원래 전통적인 웹 어플리케이션에서 사용하던 방식으로, 최근에는 Single Page Application (이하 SPA) 와 대조하여 MPA (Multi Page Application) 이라고 불립니다.

기본적으로 SSR 어플리케이션은 라우팅이 수행된 후 새로운 페이지가 서버에 요청되면 그때마다 HTML을 렌더한 후 클라이언트에서 전체 페이지를 다시 내려받습니다.

1. 클라이언트가 서버에 xxx.com/main URL 으로 요청을 보낸다.
2. 서버에서는 해당 URL 과 연결되어있는 메소드가 실행되고 알맞는 HTML Template 파일을 찾는다.
3. Database 에서 main 에서 사용하는 데이터를 가져온다.
4. 가져온 데이터와 HTML Template 를 사용해 최종 HTML 을 렌더한다.
5. 클라이언트로 HTML 을 내려준다.
6. 사용자가 뷰를 통해 본다.

SSR 장점

• 서버에서 완성돈 HTML 을 내려주기 때문에 SEO 에 최적화되어 있다.
• 매 페이지에서 필요한 리소스만 로딩하기 때문에 초기 로딩속도를 최적화할 수 있다.
  
  

SSR 단점

• 매 페이지 로딩 시마다 새로운 리소스를 요청해야하므로 전체적인 트래픽이 증가한다
• 페이지 이동 시 마다 새로고침이 되며 전체 페이지를 다시 렌더해 로딩 시간이 길다.
  
  
  

SPA 개념

최근 Javascript 프레임워크중 SPA (Single Page Application) 이 유행입니다. 즉, 서버에서 실제로 다운로드 받는 페이지는 단 1개이고 그 이후 Javascript 를 통해 동적인 렌더링을 실시하는 Application 을 의미합니다.

1. 크라이언트가 서버에 xxx.com/main URL 으로 요청을 보낸다.
2. 서버에서는 xxx.com 도메인으로 시작되면 무조건 index.html 을 찾아 내려준다.
3. 추가로 Javascript Bundle 을 같이 내려준다. (ex: Webpack 빌드시 결과물인 bundle.js)
4. bundle.js 를 실행한 클라이언트가 api.xxx.com/main 으로 사용할 데이터를 서버에 요청한다.
5. 서버는 Database 에서 해당 데이트를 가져온 후 클라이언트에 데이터를 내려준다.
6. 클라이언트는 받아온 데이트를 사용하여 뷰가 렌더한다.
7. 사용자가 뷰를 본다.

보통 Nginx 나 Apache 같은 서버 엔진이 설정에 해당 URL 을 선언하고 조건에 일치하는 URL 로 요청이 들어왔을 경우 index.html 파일을 찾아 보내줍니

어떤 URL 이든 조건에 일치하게 되면 index.html 하나면 보내주기 때문에 Single Page 라 불립니다. 그리고 클라이언트는 현재 main 에서 사용할 데이터를 가지고 있지 않기 때문에 추가적으로 API 를 호출하여 해당 데이터를 받아와야 합니다.

SPA 장점

• 초기 로딩 시 서버로부터 모든 정적 리소스를 내려받은 후에는 페이지 이동 시 필요한 데이터만 내려받으므로 속도가 빨르고 전체적으로 트래픽을 감소시킨다.
• 페이지 이동 시 새로고침이 되지 않으므로 사용자 겸험이 향상된다.
  
  

SPA 단점

• 초기 로딩 시 현재 페이지에서 사용하지 않는 모든 정적 리소스를 내려 받으므로 초기 로딩속도가 느리다.
• SEO 에 취약하다.
  
  
  

SSR vs SPA

SSR 과 SPA 두 방식 모두 로딩 속도 라는 장단점을 가지고 있습니다.

SSR 의 장점은 초기 로딩속도가 빠르다는 것입니다. SPA 는 첫 로딩 시 전체 어플리케이션 에서 사용하는 모든 정적 리소스를 내려받아야 하기 때문에 초기 로딩속도가 느리지만, 그 이후에는 추가적인 리소스를 받을 필요가 없으므로 구동 속도가 빠릅니다. 반면, SSR 은 현재 페이지에서 필요한 리소스만 로딩하면 되기 때문에 초기 로딩속도는 SPA 에 비해 빠를 수 있습니다.

그러나 받아온 정적 리소스를 어딘가에 저장하고 있는게 아니기 때문에 페이지를 이동할때마다 이전에 받아온 정적 리소스들을 다시 내려받아야 합니다. 그래서 어플리케이션 초기화 후 페이지 이동 시 로딩 시간은 SSR 이 느릴 수 있습니다.

하지만 SPA 방식의 큰 단점중 하나는 바로 SEO (검색 엔진 최적화) 입니다. 검색 엔진은 기본적으로 크롤링을 해서 페이지를 수집하는 방식이로 이루어져있는데, 일반적으로 크롤링을 하는 봇들이 Javascript 를 실행할 수 있는 능력이 없다는 것입니다. 최근 구글 크롤러의 경우 Javascript 실행능력이 있다고는 하지만 기타 검색엔진들은 기능이 지원하지 않아 빈페이지를 읽어 제대로 페이지의 정보를 표시해주지 못하는 문제가 있다.

New SSR

최근 SSR 과 SPA 의 장정을 살려 두가지 모두 사용하는 방식이 인기가 있다.

사용자의 첫 요청시에 SSR 을 수행하고, 그 이후는 SPA 처럼 동적인 렌더링을 수행하는 것이다.

장점

• 첫 요청을 SSR 로 완성된 HTML 을 내려줌으로써 SEO 와 초기 렌더링 속도문제를 해결한다.
• 이후 클라이언트에서 렌더링을 수행함으로써 SPA 의 장점인 페이지 이동 시 빠른 렌더 속도를 가져간다.
• 현재 Angular, React, Vue 모두 SSR 방식을 공식으로 지원하기 때문에 Client 와 Server 를 같은 Context 로 묶을 수 있다. 즉 컴포넌트는 클라이언트에서 렌더를 수행하든 서버에서 수행하든 동일하게 수행된다.
  
  

단점

• 코드가 복잡하다. 어플리케이션 구동 순서를 확실하게 파악하고 있지 않다면 헷갈린다.
• 서버에서 렌더링을 수행하므로 단순 리소스 서빙보다 CPU 사용량이 많고 부하가 걸릴 수 있다.
• 서버에 익숙하지 않은 FE 개발자의 경우 클라이언트 개발시 의도하지 않은 버그가 생길 수 있다. (예: 구동 소스가 클라이언트에서 별 문제가 없었지만 서버에서 심각한 오류를 일으킬 수 있음)