Dev-Tino 1주차(3):: CSR/SSR

글리프에도 사진 사이즈 조절이 있었음 좋겠다

렌더링

웹사이트를 사용자에게 보이기 위해 우리는 렌더링을 거쳐야만 한다. 렌더링이란 일반적으로 컴퓨터 프로그램을 사용하여 2D 또는 3D 모델에서 사실적인 이미지(photorealistic) 또는 사실적이지 않은 이미지(non-photorealistic)를 생성하는 프로세스이다. 이는 위키피디아의 정의로 대다수의 사람들 역시 같은 정의를 떠올릴 것이다.

그러나 HTML에서의 렌더링은 조금 다른 의미를 가진다. HTML에서의 렌더링은 ‘서버로부터 HTML 파일을 받아 화면에 뿌려주는 과정’이다. 우리가 웹사이트에 접근할 때 소스가 로딩되는 데에 시간이 걸릴 때가 있지 않은가? 이 ‘소스가 로딩되는 시간, 과정’이 렌더링 과정이라 이해하면 편하겠다.

이 렌더링에는 두 가지 이상의 방식이 있다. 이 장에서는 그 중 CSR(Client Side Rendering)과 SSR(Server Side Rendering)에 대해 서술한다.

CSR이란?

-Client Side Rendering의 준말

-서버로부터 HTML과 JS 파일을 다운로드, 이후 페이지가 보여짐.

-상호 작용에 따라 필요한 데이터는 서버에 요청함(SPA 프레임워크 실행이 수반됨)

-Page 전체를 요청하지 않고 유저 행동에 따라 변화된 부분만 re-rendering하므로 SSR에 비해 상호작용(interaction)이 빠름

-Lazy loading(페이지 내에서 바료 필요하지 않은 데이터는 로딩하지 않고 필요한 시점에 로딩) 지원

-SEO(Search Engine Optimization, 구글이 얼마나 잘 검색하고 사이트를 띄워줄 수 있는지를 이른다. 요청이 전달되기 전까지 body가 비어있기 때문에 불리하다.)이 낮음

-초기 로딩이 오래걸린다.

렌더링이 클라이언트 쪽에서 일어나는 렌더링, 서버가 요청을 받으면 클라이언트에 HTML과 JS를 보내준다. 클라이언트는 그것을 받아 렌더링을 시작한다.

위 사진은 CSR의 단계를 설명한다.

1. User가 Website 요청을 보냄

2. CDN이 HTML 파일과 JS로 접근할 수 있는 링크를 클라이언트로 보낸다.
CDN : aws의 cloudflare와 같이, 엔드 유저의 요청에 ‘물리적’으로 가까운 서버에서 요청에 응답하는 형식.

3. 클라이언트는 HTML과 JS를 다운로드 받는다. (이 때, SSR과 달리 유저는 아무것도 볼 수 없다.)

4. JS가 실행되고, 데이터를 위한 API가 호출된다.

5. 서버가 API로부터의 요청에 응답한다.

6. API로부터 받아온 data를 placeholder 자리에 넣어준다. 이제 페이지와의 상호작용이 가능해진다.

즉, 서버에서 처리 없이 클라이언트로 보내주기 때문에 자바스크립트가 모두 다운로드되고 실행되기 전까지는 사용자가 볼 수 있는 것이 없다.

SSR이란?

-Server Side Rendering의 준말

-Server에서 html, js를 만들고 렌더링한 뒤 client에 넘겨줌

-SPA 프레임워크 실행 및 상호작용에 따라 필요한 데이터 서버에 요청

-초기 로딩이 빠름

-SEO 높음

-모든 요청에 대해 새로 렌더링

-서버 과부하 가능성 높음

위 사진은 SSR의 단계를 설명한다.

1. User가 Website 요청을 보낸다.

2. Server는 ‘Ready to Render’. 즉, 즉시 렌더링 가능한 html 파일을 만든다. (리소스 체크, 컴파일 후 완성된 HTML 컨텐츠로 만든다.)

3. 클라이언트에 전달되는 순간, 이미 렌더링 준비가 되어있기 때문에 HTML은 즉시 렌더링 된다. 그러나 사이트 자체는 조작 불가능하다. (JavaScript가 읽히기 전이다.)

4. 클라이언트가 자바스크립트를 다운받는다.

5. 유저가 컨텐츠를 볼 수 있게 되고 상호작용은 저장된다. 유저는 컨텐츠를 볼 수 있지만 사이트를 조작할 수 없다.

6. 브라우저가 JavaScript 프레임워크를 실행한다.

7. JS가 성공적으로 컴파일되었기 때문에 기억하고 있던 사용자 조작(상호작용)이 실행된다. 웹페이지는 상호작용이 가능해진다.

즉, 서버에서 이미 ‘렌더 가능한’ 상태로 클라이언트에 전달되기 때문에, JS가 다운로드 되는 동안 사용자는 무언가를 보고 있을 수 있다.

CSR과 SSR의 차이

1. 웹페이지를 로딩하는 시간
CSR의 경우 HTML과 CSS를 비롯한 모든 스크립트를 한 번에 불러오기에 SSR에 비해 많은 시간을 소비한다. 반면 SSR은 필요한 부분의 HTML과 스크립트만을 불러오기에 평균적으로 SSR이 더 빠르다.
그러나 ‘첫 페이지를 로딩한 후 사이트의 다른 곳으로 이동하는 동작’을 가정했을 때에는 CSR이 더 빠르다. CSR은 ‘한 번에 모든 코드를 받아오며’ 첫 페이지를 로딩할 때 나머지 페이지를 로딩하는 데에 쓰이는 코드도 받아오나 SSR은 다시 한 번 필요한 부분의 HTML, CSS 코드를 받아오기 때문이다.

2. SEO 대응
검색 엔진은 자동화된 로봇 ‘크롤러’로 웹사이트들을 읽는다. CSR은 자바스크립트를 실행시켜 동적으로 컨텐츠가 생성되기 때문에, 자바스크립트가 실행된 뒤에야 metadata를 바꾼다. SSR은 애초에 서버 사이드에서 컴파일되어 클라이언트로 넘어오기 때문에 크롤러에 대응하기 용이하다.

3. 서버 자원 사용
SSR은 매번 서버에 요청하기 때문에 서버 자원을 더 많이 사용한다. 반면 CSR은 클라이언트 쪽에서 작업을 수행하기에 서버의 부하가 적다.

(이 때 SPA란 Single Page Application의 준말로 한 번 페이지 전체를 로딩한 뒤부터는 데이터만 변경하여 사용할 수 있는 웹 어플리케이션을 이야기한다. 단 하나의 html 파일로 동작하며 CSR 방식이다.)

현재 대부분의 앱이 CSR을 사용하고 있다. 몇몇 사이즈의 초기 로딩 속도가 지나치게 느리다면 아마 CSR을 쓰는데다가+사용하는 소스의 용량이 너무 큰 탓일테다. 이를 개선하기 위해 code splitting(리액트와 같은 SPA개발 프로젝트 빌드시 하나의 JS 파일로 빌드됨. 이를 개선하기 위한 방법. import() 문을 이용하여 실제 사용시 필요한 스크립트 파일을 따로따로 불러옴.), tree-shaking(자바 스크립트에서 dead-code를 제거하기 위한 방법. 정적인 구조- import와 export에 의존한다.), chunk 분리 등을 사용할 수 있다.

그러나 SSR을 이용하는 것 역시 좋은 방법이 될테다. 좋은 웹페이지를 만들기 위해서는 둘 모두를 알고 상황에 따라 적절한 방식을 채택할 필요가 있다.

[자료 출처]

-https://betterprogramming.pub/why-you-should-use-islands-architecture-b4f291708a02

-https://velog.io/@aseungbo/CSR-SSR

-https://velog.io/@ru_bryunak/%EB%A0%8C%EB%8D%94%EB%A7%81%EC%9D%B4%EB%9E%80

-https://ko.wikipedia.org/wiki/%EB%A0%8C%EB%8D%94%EB%A7%81

-https://searchengineland.com/guide/what-is-seo

-https://velog.io/@haileyself/SPA-Client-Side-Rendering-%EA%B7%B8%EB%A6%AC%EA%B3%A0-Server-Side-Rendering-90k4ar8is1 (SPA 정의와 정리)

-https://velog.io/@haileyself/SPA-Client-Side-Rendering-%EA%B7%B8%EB%A6%AC%EA%B3%A0-Server-Side-Rendering-90k4ar8is1

-https://www.nextree.io/code-splitting/ (code splitting)

-https://webpack.js.org/guides/tree-shaking/ (tree-shaking)

-https://hahahoho5915.tistory.com/52