[TIL] 07/01 :: CSR&SSR

yeseul·2024년 7월 1일

<TIL>

목록 보기

29/43

* MPA / SPA

✔️ MPA(Multiple Page Application)

: 탭을 이동할 때마다 서버로부터 새로운 HTML을 새로 받아와서 페이지 전체를 렌더링 하는 전통적인 웹 페이지 구성 방식

페이지 이동, 새로고침시 전체 페이지를 다시 렌더링한다.
일반적으로 MPA는 SSR(Server Side Rendering) 방식으로 렌더링한다.

✔️ SPA (Single Page Application)

: 하나의 페이지로 구성된 웹 애플리케이션

웹 에플리케이션에 필요한 모든 정적 리소스를 최초 접근 시 단 한번만 다운로드한다.
이후 새로운 페이지 요청 시, 페이지 갱신에 필요한 데이터만을 JSON으로 전달받아 페이지를 갱신한다. 기존 페이지의 내부를 수정해서 보여주는 방식이다.
일반적으로 SPA는 CSR(Client Side Rendering) 방식으로 렌더링한다.

* 렌더링 방법

어느 side 에서 렌더링을 준비하느냐에 따라 개념이 나뉜다.

💠 CSR (client side rendering)

: 클라이언트(브라우저) 에서 javascript를 사용하여 페이지를 렌더링하는 방식.

빈 뼈대의 HTML 만 주고 이후에 다운받는 리액트 소스코드를 가지고 화면에 그려주는 방법
초기 페이지 로드시 HTML, CSS, javascript 파일이 전송되며, 이후 필요한 데이터는 Ajax 요청을 통해 가져온다.
브라우저가 JavaScript 파일을 다운로드하고, 동적으로 DOM을 생성하는 시간을 기다려야 하기 때문에 초기 로딩 속도가 느리다는 것이 단점이다.
-> 초기 로딩 이후에 페이지 일부를 변경할 때는 서버에서 해당 데이터만 요청하면 되기 때문에 이후 구동 속도는 빠르다는 장점이 있다.
클라이언트에서 렌더링되므로 서버 부하가 적고, 사용자 경험이 부드러워진다.
브라우저들이 가지는 웹 크롤러는 HTML을 읽어 검색 가능한 색인을 만들어 내는데, 웹 크롤러 봇 입장에서는 HTML이 텅텅 비어 있는 것처럼 보여서 색인할만한 콘텐츠가 존재하지 않기에, SEO(검색엔진 최적화)에 불리하다.

✔️ 동작과정

유저가 웹사이트에 방문하면, 브라우저가 서버에 콘텐츠를 요청한다.

이에 서버는 빈 뼈대만 있는 HTML을 응답으로 보내준다.

브라우저가 연결된 JavaScript 링크를 통해 서버로부터 다시 JavaScript 파일을 다운로드한다.

JavaScript를 통해 동적으로 페이지를 만들어 브라우저에 띄워준다.

💠 SSR (server side rendering)

: 서버에서 페이지를 렌더링하고 완성된 HTML 을 클라이언트에 전송하는 방식.

초기 페이지 로드시, 완성된 HTML이 전송되므로 빠른 초기 페이지 로드가 가능하다.
전통적인 웹 애플리케이션의 방법
서버사이드렌더링을 통해 MPA (멀티 페이지 애플리케이션) 구축.
사용자가 요청할때마다 페이지를 제공하는 방식으로 동작.
-> 문제점 : 화면 깜빡거림..
사용자가 버튼을 클릭하거나 이동하려고 할 때 아무 반응이 없을 수 있다.
-> interaction이 가능한 페이지처럼 보이지만, 실제로는 내용과 스타일이 입혀진 껍데기에 불과하고 클라이언트 측 JavaScript가 실행되고 이벤트 핸들러가 첨부된 JavaScript 로직이 모두 연결될 때까지 사용자의 입력에 응답할 수 없기 때문이다.

이렇듯, SSR에는 TTV(Time to View)와 TTI(Time to Interact) 간의 시간 간격이 존재한다는 것이 단점이다. 반면에 CSR은 JavaScript가 동적으로 DOM을 생성하기 때문에 HTML은 JavaScript 로직이 모두 완전히 연결된 상태라 사용자가 보는 시점과 이용할 수 있는 시점이 동일하다.

✔️ 동작과정

유저가 웹사이트에 방문하면, 브라우저가 서버에 콘텐츠를 요청한다.

이에 서버는 페이지에 필요한 데이터를 즉시 얻어와 모두 삽입하고, CSS까지 모두 적용해 렌더링 준비를 마친 HTML과 JavaScript코드를 브라우저에 응답으로 전달한다.

브라우저에서는 JavaScript코드를 다운로드하고 HTML에 JavaScript로직을 연결한다.

✔️ 비교

💭그렇다면 어떤 방식을 언제 사용해야하나?

💡개발에 정답이 없듯, 서비스 성격에 따라 달라진다.

-> 초기페이지 로드 속도와 SEO 가 중요한 경우에는 SSR, 사용자 경험이 중요한 경우에는 CSR 을 선택하는게 좋은것 같다.

ex1. 사용자와의 상호작용이 많고, 대부분 페이지가 고객의 개인정보 데이터를 기준으로 구성되는 서비스라면 검색포털 상위 노출 되는 것보다 오히려 고객의 데이터를 보호하는 것이 더 중요할 수 있다.
🌟모든 서비스에 SEO가 필요하지는 않다는 의미!
이런 서비스의 경우 SSR 보다 CSR이 더 적합하다.

ex2. 회사 홈페이지이기 때문에 홍보나 상위노출이 되어야하고 만약 그 페이지의 데이터가 자주 바뀐다면 SSR이 더 적합할 것이고, 내용을 업데이트 하는 일이 거의 없다면 SSG가 더 적합할 것이다.

ex3. 사용자에 따라 페이지 내용도 달라지고 빠른 인터랙션도 중요하고 검색엔진 최적화도 포기할 수 없다면 그때는 CSR + SSR 즉 유니버셜 렌더링을 고려해보면 좋을 것이다.
-> 초기렌더링으로는 SSR + 이후 CSR

* 코드스플리팅

Next.js는 코드스플리팅을 default로 지원
Next.js의 코드 스플리팅 구현
- 각 컴포넌트를 별도 Javascript 번들로 분리
- 사용자가 어떤 페이지에 방문할 때(어떤 컴포넌트를 볼 때) 필요한 부분만 로드하도록 보장한다.
- ‘프레임워크’인 Next.js는 이런 부분을 개발자가 신경쓰지 않아도 알아서 다 해준다. 그래서 우리는 더욱 애플리케이션 자체의 구조설계와 비즈니스 로직 구현에 집중할 수 있다.

💭 코드스플리팅을 제공한다면, 스켈레톤 같은 라이브러리는 사용하지 않나?

* Hydration

✔️ TTV (Time To View)

: 사용자가 최초 view 를 볼 수 있을때까지의 시간

✔️ TTI

: 사용자가 웹사이트와 소통할 수 있는, 인터랙션 할 수 있는 시간

자바스크립트 소스코드가 들어가기 시작하니까 버튼들이 동작하기 시작한다.
자바스크립트가 하이드레이션 되는걸 통해서 측정 가능하다.
TTV 와 TTI 사이의 간극을 줄이는걸 하이드레이션이 하는 것이다.

✔️ 6가지 원칙을 기반으로 개발

out-of-the-box functionality requiring no setup

JavaScript everywhere + all functions are written in JavaScript

automatic code-splitting and server-rendering

configurable data-fetching

anticipating requests
-> 사용자가 원하는 것이 무엇인지를 먼저 예측 = 요구사항 예측

simplifying deployment

APP 폴더를 기준으로 페이지들이 라우팅 된다. (app 폴더 밑에 폴더명을 기반으로 자동 라우팅) -> 앱 라우터
page 를 기준으로 라우팅 된다.(pages 폴더에 원하는 페이지의 파일 이름을 둔다.) -> 페이지 라우터

1. CSR(Client Side Rendering)

특징
- 순수 리액트 사용했을 때 100%
- 브라우저에서 JavaScript를 이용해 동적으로 페이지를 렌더링하는 방식
- 렌더링의 주체 : 클라이언트
장점
- (최초 한번 로드가 끝나면) 사용자와의 상호작용이 빠르고 부드럽다.
- 서버에게 추가적인 요청을 보낼 필요가 없기 때문에, 사용자 경험이 좋다.
- 서버 부하가 적음
단점
- 첫 페이지 로딩 시간(Time To View)이 길 수 있다.
- JavaScript가 로딩되고 실행될 때까지 페이지가 비어있어 검색 엔진 최적화(SEO)에 불리하다.

2. SSG(Static Site Generation)

특징
- 서버에서 페이지를 렌더링하여 클라이언트에게 HTML을 전달하는 방식.
- SSG의 정적(Static)은 SSR 처럼 전체 프로세스가 각 사용자 요청에 수행되는 것이 아닌 빌드 시간에 수행된다.
  -> 그렇기 때문에 SSG가 서버 사이드 렌더링보다 훨씬 더 빠르다.
- 최초 빌드시에만 생성이 됨
- ‘빌드’
  - 지금까지 yarn build, npm run build 등의 명령어를 통해 빌드 파일을 직접 생성해본 적이 없었음.
  - vercel을 이용할 때 알아서 build를 해주기 때문에 우리는 Local 환경에서 빌드를 할 필요가 없었기 때문.
- 사전에 미리 정적페이지를 여러개 만들어놓음 → 클라이언트가 홈페이지 요청을 하면, 서버에서는 이미 만들어져있는 사이트를 바로 제공! → 클라이언트는 표기만 함
장점
- 첫 페이지 로딩 시간이 매우 짧아(TTV) 사용자가 빠르게 페이지를 볼 수 있다. 또한, SEO에 유리하다.
- CDN(Content Delivery Network) 캐싱 가능
  -> 컨텐츠를 중간에서 관리해주는 네트워크 서비스
단점
- 정적인 데이터에만 사용할 수 있음
- 사용자와의 상호작용이 서버와의 통신에 의존하므로, 클라이언트 사이드 렌더링보다 상호작용이 느릴 수 있다. 또한, 서버 부하가 클 수 있다.
- 마이페이지 처럼 데이터에 의존하여 화면을 그려주는 경우 사용 불가

3. ISR(Incremental Static Regeneration)

특징
- SSG처럼 정적 페이지를 제공
- 설정한 주기만큼 페이지를 계속 생성해 줌
- ex : 주기가 10분이라면? → 10분마다 데이터베이스 또는 외부 영향 때문에 변경된 사항을 반영하는 역할
  -> SSG 인데, 가끔씩은 다시 만들어 주는것.
- 정적 페이지를 먼저 보여주고, 필요에 따라 서버에서 페이지를 재생성하는 방식.
장점
- 정적 페이지를 먼저 제공하므로 사용자 경험이 좋으며, 콘텐츠가 변경되었을 때 서버에서 페이지를 재생성하므로 최신 상태를 (그나마) 유지할 수 있다.
- CDN 캐싱 가능
단점
- 동적인 콘텐츠를 다루기에 한계가 있을 수 있다. 실시간 페이지 아님
- 마이페이지 처럼 데이터에 의존하여 화면을 그려주는 경우 사용 불가

4. SSR

특징
- 빌드 시점에 모든 페이지를 미리 생성하여 서버 부하를 줄이는 방식.
- SSG, ISR처럼 렌더링 주체가 서버!
- 클라이언트의 요청 시 렌더링
  - C → S : 이 페이지 줘!
  - S → C : (데이터베이스 읽고 등등 한 후) html 파일을 제공
장점
- 빠른 로딩 속도(TTV)와 높은 보안성을 제공한다.
- SEO 최적화 좋음
- 실시간 데이터를 사용
- 마이페이지 처럼 데이터에 의존한 페이지 구성 가능
- CDN 캐싱 불가
단점
- 사이트의 콘텐츠가 변경되면 전체 사이트를 다시 빌드해야 하는데, 이 과정이 시간이 오래 걸릴 수 있다. → 서버 과부하
- 요청할 때 마다 페이지를 만들어야 함

yeseul

이전 포스트

[TIL] 6/27 :: tsc 권한문제 / CRLF error

다음 포스트

[TIL] 07/01 :: CSR&SSR

<TIL>

* MPA / SPA

✔️ MPA(Multiple Page Application)

✔️ SPA (Single Page Application)

* 렌더링 방법

💠 CSR (client side rendering)

✔️ 동작과정

💠 SSR (server side rendering)

✔️ 동작과정

✔️ 비교

💭그렇다면 어떤 방식을 언제 사용해야하나?

💡개발에 정답이 없듯, 서비스 성격에 따라 달라진다.

* 코드스플리팅

💭 코드스플리팅을 제공한다면, 스켈레톤 같은 라이브러리는 사용하지 않나?

* Hydration

✔️ TTV (Time To View)

✔️ TTI

✔️ 6가지 원칙을 기반으로 개발

1. CSR(Client Side Rendering)

2. SSG(Static Site Generation)

3. ISR(Incremental Static Regeneration)

4. SSR

[TIL] 6/27 :: tsc 권한문제 / CRLF error

라이브러리 vs 프레임워크

0개의 댓글