search

QueenCards / ProjectAnalysis

플젝뿌셔
1 stars 0 forks source link

[03] CSR과 SSR의 차이점이 뭔가요? #3

Closed hyeyoonS closed 5 months ago

hyeyoonS commented 5 months ago

📎 질문

[03] CSR과 SSR의 차이점이 뭔가요?

✏ 구술 답변 키워드


✏ 답변

CSR과 SSR 렌더링 설명

CSR과 SSR은 대표적인 웹 렌더링 방식입니다. 두 방식은 렌더링을 담당하는 주요 축이 다릅니다. CSR은 Client Side Rendering(클라이언트 사이드 렌더링)의 약자로 클라이언트 측에서 렌더링 하는 방식이고, SSR은 Server Side Rendering (서버 사이드 렌더링)의 약자로 서버 측에서 렌더링 하는 방식입니다.

먼저, CSR은 클라이언트 측의 역할 비중이 큰 렌더링 방식입니다. 유저가 웹 사이트에 접속하면, 브라우저가 웹 애플리케이션에 필요한 HTML 기초 뼈대와 모든 페이지 필요한 정적 자원(CSS, js, 이미지)들을 서버에 요청합니다. 그리고 브라우저는 HTML을 해석하여 DOM을 생성하고 자원들을 다운로드 합니다. 이후, 브라우저의 자바스크립트 엔진이 페이지에 필요한 JS 파일을 실행하여 새로운 컴포넌트를 동적으로 렌더링하고 화면을 업데이트 합니다.

이렇게, 하나의 간단한 HTML 파일 내에서, 필요한 컴포넌트만 동적으로 렌더링하여 교체하는 방식으로 작동하는 웹 애플리케이션을 SPA(Single Page Application) 이라고 합니다.

반면, SSR은 서버 측에서 URL마다 필요한 내용들을 모두 미리 결정해둡니다. 사용자가 접속 시에, 서버는 사용자가 접속한 URL에 대응하는 페이지를 렌더링 엔진을 이용해 렌더하고, 완성된 형태의 HTML과 함께 js파일 등을 브라우저에 응답합니다. 이후 브라우저에서 HTML을 해석하여 DOM을 생성하고 Hydration을 진행합니다.

페이지마다 서버로부터 새로운 HTML을 받아와서 페이지 전체를 렌더링하는 전통적인 웹 어플리케이션을 MPA(Multi page Application)이라고 합니다.

CSR과 SSR 장단점 및 사용 사례

프로그래밍 시, 각 렌더링 방식이 가진 서로 다른 이점을 잘 고려하여 서비스의 특징과 목적에 따라 알맞은 렌더링 방식을 선택해야 합니다. 렌더링 기법은 사용자 경험을 크게 좌우할 수 있기 때문입니다.

CSR은 최초에 웹 어플리케이션에 필요한 모든 파일을 다운로드 받기 때문에 최초 로딩 속도가 늦지만 라우팅 시에 필요한 부분만 동적으로 갱신하여 보여주기 때문에 화면 전환이 자연스럽습니다. 그렇기에, CSR은 유저 상호작용이 빈번하게 일어나는 웹 어플리케이션에서 좋은 선택지가 될 수 있습니다.

SSR은 검색 엔진 최적화에 유리하여 검색 엔진 상위 노출이 필요한 페이지에 적합할 수 있습니다. 초기 렌더링 시에 필요한 정보들을 모두 가지고 있어 검색엔진의 web crawler에게 많은 정보를 제공할 수 있기 때문입니다. 또한, SSR은 초기에 HTML을 먼저 받아와, 즉각적으로 사용자에게 화면을 서빙하고 이후 하이드레이션 과정이 실행됩니다. 이를 볼 때, 초기 진입 경험이 중요한 곳에서 SSR 방식을 선택하면 좋습니다. 하지만, TTV(Time To View)와 TTI(Time To Interact)간의 시간 간격이 존재하는데 이 간극 길면 사용자 경험에 좋지 않아 단점으로 작동하기도 한다. (하지만 상호작용을 기억해놓고 있다가 나중에 작동하긴 한다.) 그러나 페이지 이동 시마다 서버에서 페이지를 생성해야 하기 때문에 TTFB(서버 요청을 받아서 HTML 파일이 처음 도달하는 시간)가 느리고, 서버와 클라이언트 간의 데이터 통신이 실패하면 화면에 아무 것도 보여지지 않을 수 있으며, 서버 부담과 비용이 증가할 수 있습니다.

(* 부연 설명: HTML이 먼저 보여지고, 이후 JS 코드를 실행하면서 이벤트 핸들러를 붙이는 인터랙티브하게 하는 하이드레이션(hydration) 과정이 있음)

Jyophie commented 5 months ago

CSR과 SSR을 이해하기에 앞서, SPA와 MPA의 차이점부터 짚어보겠습니다.

  1. SPA & MPA (웹 애플리케이션의 페이지 수를 기준으로 나뉘는 개념)
  1. CSR & SSR (렌더링을 어디서 하는지에 따라 나뉘는 개념)

CSR(Client Side Rendering): 클라이언트(브라우저)에서 웹 페이지를 렌더링하는 방식. 동작 과정: 유저가 웹사이트에 방문해 브라우저가 서버에 콘텐츠를 요청하면, 서버는 빈 뼈대만 있는 HTML을 응답으로 제공하고, 브라우저가 연결된 JS 링크를 통해 서버로부터 다시 JS 파일을 다운로드하고, 동적으로 페이지를 만들어 브라우저에 띄워주는 방식입니다.

SSR(Server Side Rendering): 서버에서 웹 페이지를 렌더링하여 클라이언트에게 전달하는 방식. 동작 과정: 유저가 웹 사이트에 방문해 브라우저가 서버에 콘텐츠를 요청하면, 서버는 페이지에 필요한 데이터를 즉시 얻어와 삽입하고, CSS까지 모두 적용해 렌더링 준비를 마친 HTML과 JS 코드를 브라우저에 응답으로 제공합니다. 브라우저는 JS 코드를 다운로드하고 HTML에 JS로직을 연결합니다.

olseul commented 5 months ago

CSR 브라우저에서 웹 페이지를 렌더링하는 방식입니다. CSR은 첫 페이지 로딩 시 모든 스크립트와 데이터를 로드해야 하기 때문에 초기 로딩 속도가 느릴 수 있습니다. 하지만 한 번의 초기 로딩으로 모든 필요한 스크립트와 데이터를 불러오고, 이후의 페이지 내 이동이나 상호작용이 매우 빠르게 처리됩니다.

SSR 서버 사이드 렌더링은 서버에서 HTML을 미리 생성하여 브라우저로 전송하는 방식입니다. 브라우저는 서버로부터 완성된 HTML 페이지를 받아 사용자에게 바로 보여줍니다. 초기 페이지 로딩 시간이 빠르지만, 모든 페이지 요청에 대해 서버에서 HTML을 생성해야 하기 때문에 서버의 부하가 증가할 수 있습니다.

wise-Ag commented 5 months ago

CSR (Client-side Rendering) CSR은 웹 브라우저에서 자바스크립트로 HTML을 만들어 렌더링하는 방식을 말합니다.

장점 ▪️ 페이지의 전환 속도가 SSR에 비해 빠르고, 깜빡임 없이 부드럽게 페이지가 바뀝니다. ▪️ 자바스크립트에서 HTML을 만드는 연산작업이 서버에 집중되지 않기 때문에 서버에 부하가 적게 발생합니다.

단점 ▪️ SPA(Single Page Application)의 경우 처음 페이지 접근시 서버로부터 전체 페이지에 대한 자바스크립트 번들파일, CSS 파일을 받아야 하므로 페이지를 만들고 유저가 사용하기 까지 시간이 SSR에 비해 오래 걸립니다. ▪️ 검색엔진에서 자동화된 로봇인 ‘크롤러’로 웹 사이트를 읽는데, CSR은 자바스크립트를 실행해서 동적으로 콘텐츠를 생성해야 데이터를 수집할 수 있기 때문에 크롤러가 원하는 수집을 할 수 없는 경우가 있어 검색엔진 최적화에 불리한 점이 있습니다.

활용 ▪️ 유저의 상호작용이 많고, 유저의 개인정보를 기준으로 서비스하는 페이지에 적합합니다. ▪️ 예시로 유저 프로필 페이지나, 결제 내역, 어드민 전용 페이지가 있습니다.

SSR (Server-side Rendering) SSR은 서버에서 리퀘스트에 맞는 HTML을 만들어서 리스폰스로 보내주는 방식을 말합니다.

장점 ▪️ 크롤러에게 완성된 페이지를 전달하기 때문에 검색엔진 최적화에 유리합니다. ▪️ 처음 페이지 접근시 서버로부터 해당 페이지에 필요한 데이터들만 전달받고 만들어진 HTML을 전달 받기 때문에 유저가 사용하기 까지 걸리는 시간이 CSR에 비해 빠릅니다.

단점 ▪️ 서버로 짧은 시간에 많은 요청이 있는 경우 HTML을 만드는 연산작업이 서버에 많은 부하를 줄 수 있습니다. ▪️ 웹 어플리케이션 내에서 페이지 전환시 전체 페이지가 사라지고 새로운 페이지 HTML을 받으면서 깜빡임이 발생해 사용자 경험을 헤칠 수 있습니다.

활용 ▪️ 페이지 내용에 데이터베이스에 있는 데이터가 필요하고, 검색엔진 최적화가 필요한 페이지에 적합합니다.

HaydenDevK commented 5 months ago

초기 렌더링 주체가 다릅니다.

CSR은 클라이언트(브라우저)에서 렌더링을 수행하고, SSR은 서버에서 렌더링을 수행합니다.

이에 따라 각각의 장단점이 있습니다.

CSR은 모든 리소스를 클라이언트가 가지고 있기 때문에 페이지 전환 시에 속도가 빠르고 깜빡임도 없다는 장점이 있지만, 모든 리소스를 다운로드하기 때문에 초기 페이지 로딩 속도가 느려 유저가 빈 페이지를 보게 될 수 있고, 클라이언트의 하드웨어 및 소프트웨어 성능에 따라 사용자 경험이 달라질 수 있습니다.

반면 SSR은 초기 페이지 로딩 속도가 빠르고 서버에서 페이지를 로드하므로 자바스크립트 파일을 클라이언트에 보내지 않아도 되어 TTI를 빠르게 수행할 수 있으며 또한, 요청한 페이지에 대해서만 통신을 하면 되므로 네트워크 레이턴시가 줄어들고, 서버 측에서 렌더링을 하기 때문에 클라이언트의 하드웨어 및 소프트웨어 성능의 영향을 덜 받습니다.

그러나 페이지 이동 시마다 서버에서 페이지를 생성해야 하기 때문에 TTFB가 느리고, 서버와 클라이언트 간의 데이터 통신이 실패하면 화면에 아무 것도 보여지지 않을 수 있으며, 서버 부담과 비용이 증가할 수 있습니다.

Eugene-A-01 commented 5 months ago

SSR 서버측에서 즉시 렌더링이 가능한 CSS와 데이터들까지 전부 가져와진 HTML과 JS로 데이터를 내려주고 클라이언트는 바로 이 HTML을 그리기 때문에 처음 화면에 그려지는게 빠른 렌더링 방식입니다. 모든 데이터가 들어있는상태의 HTML을 받기 때문에 SEO에 유리합니다. 그러나 이때는 모든 스타일과 데이터가 들어가만 있는 그림에 불과하기 때문에 사용자 상호작용이 불가능하고 이후 브라우저에서 JS 작업 이후 사용자 상호작용이 가능해집니다. JS가 연결되면서 DOM이 HTML과 연결되는 과정에서 깜빡임이 있을 수 있습니다. SSR은 서버측 부하가 있을 수 있다는 단점이 있습니다.

검색엔진 상위노출이 필요하거나, 누구에게나 같은 화면이 보여지거는 페이지이거나, 사용자 인터렉션이 적은 페이지이거나, 데이터가 빈번하게 바뀌는 페이지의 경우 SSR이 유리한 경우입니다.

CSR 서버는거 바로 클라이언트 측에 빈 HTML뼈대와 JS를 보내주고 클라이언트측에서 동적으로 이 HTML 뼈대에 JS로 DOM을 생성해 페이지를 만들어 그려넣는 방식입니다. 초기 HTML+JS 다운이 모두 완료되기 전까지는 사용자는 아무것도 볼 수 없어 첫화면 그려지는건 느리지만, API호출이 완료되지 않은시점에도 placeholder들 하나씩 채워져 가는 과정부터는 전부 그려지지 않았어도 상호작용도 가능하다는 장점이 있습니다. 또한 빈 HTML에 즉시 연결되는 DOM이 일치하므로 깜빡임도 없다는 장점이 있습니다.

사용자와의 상호작용이 많은페이지이거나, 고객정보같은 페이지라서 검색엔진노출이 중요하진 않은 경우 CSR이 적절한 페이지 입니다.

hyeyoonS commented 5 months ago

CSR은 클라이언트에서 컴포넌트를 렌더링하는 것을 의미합니다. 서버에서 빈 html과 js bundle을 다운로드 받고, 이 js 소스코드를 클라이언트에서 해석해서 처음부터 그려나가게 됩니다. 때문에 초기 로딩 속도가 느리지만, 스크린간 이동이나 인터렉션에 강점이 있습니다.

반면에 SSR은 서버에서 컴포넌트를 해석하여 최종 결과물인 html파일을 내려주는 것을 의미합니다. CSR과는 반대로 초기 로딩속도가 빠르지만, 페이지를 이동할 때마다 새로운 html을 요청해서 받는 시간이 필요하고, 현재 화면에서도 작은 변경 사항이 생기면 처음부터 html을 다시 로드해야 하기 때문에 스크린간 이동이나 인터렉션에 약점이 있습니다.

kanglocal commented 5 months ago

  1. 웹페이지가 로딩되는 시간이 다르다. 로딩시간을 첫페이지의 로딩시간, 그 나머지를 로딩하는 시간 으로 나눌 수 있는데 펏페이지의 로딩 시간은 SSR이 더 빠르다. CSR은 HTML, CSS, JS를 한번에 불러오는 반면 SSR은 필요한 부분의 HTML과 스크립트만 불러오게 되기 때문이다. 나머지 시간의 로딩시간은 CSR이 빠르다. 다른 곳으로 이동하는 경우, CSR은 이미 다 받아 놨기 때문에 빠르지만, SSR은 첫 페이지를 로딩한 과정을 다시 실행하게 된다.

  2. SEO 대응이 다르다. SSR은 SEO최적화할 수 있다.

  3. 서버 자원을 SSR이 더 많이 사용한다.

Client Side Rendering

클라이언트쪽에서 렌더링이 일어난다. 서버에서의 처리 없이 클라이언트로 보내주기때문에 자바스크립트가 모두 다운로드되고 실행이 끝나기 전까지 사용자는 볼 수 있는게 없다.

+) CSR의 단계는?

  1. User가 웹사이트에 요청을 보낸다.
  2. CDN이 HTML파일과 JS로 접근할 수 있는 링크를 클라이언트로 보낸다.
  3. 클라이언트는 HTML과 JS를 다운로드 받는다.(이 때 SSR과 달리 유저는 아무것도 볼 수 없다.)
  4. 다운로드가 완료된 JS가 실행된다. 데이터를 위한 API가 호출된다.(이 때 유저들은 placeholder를 보게된다.)
  5. 서버가 API로부터의 요청에 응답한다.
  6. API로부터 받아온 data를 placeholder자리에 넣어준다.
  7. 위 과정이 끝나면 페이지는 상호작용이 가능해진다.

ServerSide Rendering

서버쪽에서 렌더링 준비를 끝마친 상태로 클라이언트에 전달된다.

+) SSR의 단계는?

  1. User가 웹사이트에 요청을 보낸다.
  2. 서버는 Ready to Render, 즉 즉시 렌더링 가능한 html파일을 만든다.(리소스체크, 컴파일 후 완성된 HTML 컨텐츠로 만든다.)
  3. 클라이언트에 전달되는 순간, 이미 렌더링 준비가 되어있기 때문에 HTML은 즉시 렌더링되지만 자바스크립트가 읽히기 전이라 사용자와 인터렉션은 불가능하다.
  4. 클라이언트가 자바스크립트를 다운받는다.
  5. 다운받는사이 유저는 컨텐츠를 볼 수 있지만 조작할 수 없다. 하지만 이때의 사용자 조작을 기억하고 있는다.
  6. 브라우저가 JavaScript 프레임워크를 실행한다.
  7. JS까지 성공적으로 컴파일되었기때문에 위에서 기억하고 있던 사용자 조작이 실행되고, 상호작용이 가능한 상태가 된다.