프리온보딩

각광받고 있는 Next.js: 알보기위해 SSR, CSR의 살펴보기

올바른생활부터 2024. 2. 13. 20:57
728x90
반응형
SMALL

 
프론트엔드를 공부하다보면 SPA, MPA, SSR, CSR에 관해 들어본적 있을 것이다. 나 또한, 리액트를 공부하다가 알게되었지만 개념을 정확하게 인지하지 못한채 넘어갔었다.
마침 프리온보딩에서 SSR, CSR에 관해 설명을 해주어 이번 기회에 개념을 짚고 넘어가보려고 한다. SSR, CSR의 정의 및 차이점과 어느 상황에서 선택해야하는지 밑에서 알아보자.

목차

1. SSR과 CSR의 정의 및 차이점

2. SSR과 CSR의 정의 및 차이점

3. SSR 또는 CSR을 선택해야 하는 상황

 

1. MPA vs SPA 개념

MPA(multi page application)

  • 서버 사이드 렌더링 방식인 멜터 페이지 애플리케이션은 여러 페이지로 구성된 웹 애플리케이션이다.
  • 사용자의 클릭과 같이 인터렉션(상호작용)이 발생할 때마다 서버로부터 새로운 html을 받아와서 해당 링크로 이동하여 페이지 전체를 새로 렌더링하는 전통적인 웹 페이지 구성방식이다.

SPA(Single Page Application)

  • 하나의 페이지로 구성된 웹 애플리케이션이다.
  • 브라우저에 최초에 한번 페이지 전체를 로드하고, 이후부터는 특정 부분만 Ajax를 통해 데이터를 바인딩하는 방식이다.
  • 단일 페이지 어플리케이션(SPA)는 React와 Vue, 앵큘러와 같은 자바스크립트 프레임워크 등이 SPA의 방식을 가지고 있다.

  • SSR은 새로운 파일을 불러오지만. CSR은 json파일의 데이터만 받아온다.
SSR Next.js , Nuxt.js, Gatsby
CSR React, Angular, Vue, Svelte
상태관리 Redux, Mobx, Recoil, Vuex
테스팅 도구 Jest, Mocha, Cypress
빌드 및 번들링 도구 Webpack, Rollup, Parcel

2. SSR과 CSR의 정의 및 차이점

SSR(server-side rendering)

정의

    • 서버 사이드 렌더링은 최초에 사용자에게 보여줄 페이지를 서버에서 렌더링빠르게 사용자에게 화면을 제공하는 방식을 의미한다. 즉, 서버에서 페이지를 미리 렌더링 하고, 사용자에게 전달하는 기술
    • 사용자가 웹페이지에 접속할 때마다 서버는 HTML와 CSS, JS등을 포함한 완성된 페이지를 생성하고, 사용자에게 전달한다.
    • 웹페이지가 점점 느려지는 상황에 대한 문제의식을 SPA의 태생적인 한계를 느끼고, 이를 개선하고자 서버에서 페이지를 렌더링해 제공하는 기존 방식의 웹 개발이 떠오르고 있다.

  • 싱글 페이지 애플리케이션과 서버에서 페이지를 빌드하는 서버 사이드 렌더링의 차이“웹페이지 렌더링의 책임을 어디에 두느냐이다.”
  • SPA는 사용자에게 제공되는 자바스크립트 번들에서 렌더링을 담당하지만 SSR을 채택하면 렌더링에 필요한 작업을 모두 서버에서 수행한다.

작동원리

    • 서버에서 사용자 요청을 처리하고 HTML을 생성한 다음 사용자의 브라우저에 전송한다.

SSR의 기술적 특성

  • 서버 중심의 페이지 생성 및 관리하는 것이 특징이고, 클라이언트 측 자바스크립트 처리를 최소화하는데 중점을 둔다.

장점

  1. 초기 로딩 속도가 빠르다(= 최초 페이지 진입이 비교적 빠르다.)
    • 빠른 초기 페이지 로딩 및 표시를 하여 사용자가 웹페이지에 접속할 때 서버에서 이미 렌더링된 페이지가 전송되었기 때문에 사용자는 즉시 컨텐츠를 볼 수 있다.
      • 일반적으로 서버에서 HTTP 요청을 수행하는 것이 더 빠르고, 또 HTML을 그리는 작업도 서버에서 해당 HTML을 문자열로 미리 그려서 내려주는 것이 클라이언트 기존 HTML에 삽입하는 것보다 더 빠르다.
      • 모든 경우에 서버 사이드 렌더링이 초기 페이지 렌더링에 비해 이점을 가진다고 볼 수 없지만 화면 렌더링이 HTTP 요청에 의존적이거나 렌더링해야 할 HTML의 크기가 커진다면 상대적으로 SSR이 더 빠를 수 있다.
    • 특히, 대규모 트래픽이 예상되는 경우에 유리함
  2. 검색 엔진 최적화(SEO) 효과 이점이 있다.(= 검색 엔진과 SNS 공유 등 메타데이터 제공이 쉽다.)
    • SSR은 검색 엔진 최적화에 유용하다. 서버 사이드 렌더링이 검색 엔진 최적화에 유용한지 이해하려면 검색 엔진이 사이트에서 필요한 정보를 가져가는 과정을 알아야한다.
        1. 검색 엔진 로봇이 페이지에 진입한다.
        2. 페이지가 HTML 정보를 제공해 로봇이 이 HTML을 다운로드한다. 단. 페이지의 정적인 정보를 가져오는 것이 목적이므로 HTML을 다운로드하고, 자바스크립트 실행 하지 않는다.
        3. 다운로드 한 HTML페이지 내부의 오픈 그래프(open graph)나 메타(meta) 태그 정보를 기반으로 페이지의 검색(공유)정보를 가져오고, 이를 바탕으로 검색 엔진에 저장한다.
    • SPA는 자바스크립트에 의존하기 때문에 페이지에 최초로 진입했을 때 메타(meta) 정보를 제공할 수 있도록 조치를 취하지 않는다면 검색 엔진이나 SNS 공유 시에 불이익이 있을 것이다.
    • 반면, SSR검색 엔진에 제공할 정보를 서버에서 가공해서 HTML응답으로 제공할 수 있으므로 검색 엔진 최적화에 대응하기가 매우 용이하다.
    • 즉, 검색 엔진 최적화 효과의 이점은 HTML 페이지는 검색 엔진이 쉽게 크롤링하고 색인할 수 있어 더 나은 SEO 퍼포먼스 및 가시성을 향상 시킨다고 볼 수 있다.
  3. 누적 레이아웃 이동이 적다.
    • 누적 레이아웃 이동이란 사용자에게 페이지를 보여준 이후에 뒤늦게 어떠한 HTML 정보가 추가되거나 삭제되어 화면이 덜컥 거리는 것과 같은 부정적 사용자 경험을 말한다. 이에 대한 예시로는 신문 기사를 제공하는 사이트에서 전체 기사 내용이 먼저 노출되고, 뒤늦게 배너가 로딩되는 것이다.
    • SPA는 API 요청에 의존하고, API 요청의 응답 속도가 제각각이며, 이를 적절히 처리해두지 않는다면 누적 레이아웃 이동 문제가 발생할 수 있다. 반면, SSR의 경우는 API 요청이 완전히 완료된 이후에 완성된 페이지를 제공하므로 이러한 문제에서 비교적 자유롭다.
  4. 사용자의 디바이스 성능에 비교적 자유롭다.
  • 이는 서버 사이드 렌더링을 수행하면 자바스크립트 리소스 실행이 사용자의 디바이스에서만 실행되므로 사용자 디바이스 성능에 의존적인 부담을 서버에 나눌 수 있어 사용자의 디바이스 성능으로부터 조금 더 자유로워질 수 있다.

※ 사용자의 디바이스: 사용자가 웹 페이지나 애플리케이션에 접근하는 데 사용하는 기기를 의미한다.

단점

1. 서버 부하 증가한다.

  • 모든 사용자 요청이 서버 측에서 처리되어야 되기 때문에 높은 트래픽 시 서버의 부하를 증가 시킨다. 이에 서버의 성능과 확장성에 대한 고려를 필요하게 된다.

2. 적절한 서버가 구축돼 있어야 한다.

  • SPA나 정적 HTML 페이지만으로 서비스하는 HTML, JS, CSS 리소스를 다운로드 할 수 있는 준비만하면 된다. 서버는 정적인 데이터인 자바스크립트와 HTML을 제공하면 모든 역할이 끝난다. 그러나 SSR은 사용자의 요청을 받아 렌더링을 수행할 서버가 필요하다. 사용자의 요청에 따라 대응할 수 있는 물리적인 가용량을 확보 해야하고, 예기치 않은 장애 상황에 대응할 수 있도록 복구 전략도 필요하다.

3. 서비스 지연에 다른 문제

  • 싱글 페이지 애플리케이션은 최초에 어떤 화면이라도 보여준 상태에서 느린 작업이 수행될때 “로딩 중”과 같은 적절한 안내를 한다면 사용자는 기다릴 여지가 있다. 하지만 서버 사이드 렌더링에서 지연이 일어난다면,
  • 서버 사이드 렌더링이 최초 렌더링될 때 지연되어 화면에 빈 화면이 노출된다면 큰 문제가 된다. SSR은 서버에서 사용자에게 보여줄 페이지에 대한 렌더링 작업이 끝나기까지는 사용자에게 그 어떤 정보도 제공할 수 없다. 애플리케이션의 규모가 커지고 작업이 복잡해지고, 이에 따라 다양한 요청에 얽히는 경우 SSR은 안좋은 사용자 경험을 제공할 수 있다.

SSR의 사례

  • 대표적인 SSR 프레임워크
    • Next.js(React), Nuxt.js(Vue)
  • SSR의 실제 적용 사례는
    • 뉴스 포털 사이트 - 실시간 뉴스 업데이트와 빠른 콘텐츠 전달함
    • 블로그 플랫폼 - 사용자의 글을 신속하게 검색 엔진에 노출시킴
    • 대형 eCommerce 사이트 - 빠른 페이지 로딩과 SEO 최적화를 함

CSR(client-side rendering)

정의

  • 클라이언트 측에서 페이지를 렌더링하는 방식임.
  • 사용자의 브라우저에서 렌더링을 담당함
    • 처음에 입문하게 되는 리액트, 뷰, 앵큘러 등을 사용해서 브라우저를 띄웠을 때 그것은 CSR렌더링 방식을 실행함.
  • 브라우저에서 JS를 사용하여 페이지를 생성함

작동원리

  • 사용자가 브라우저에 처음 접속할 때 서버에 기본적인 HTML, JS를 전송한다. 이후 브라우저에서 JS을 실행하여 웹 페이지의 콘텐츠와 인터페이스를 생성하고 렌더링함.

CSR의 기술적 특성

  • CSR의 방식은 동적인 웹애플리케이션에 적합하고, 사용자 상호작용에 따라 실시간 페이지를 갱신하고, 브라우저 중심의 페이지 처리 및 관리를 가능하게 함

장점

  • 사용자의 경험과 페이지 인터랙션(상호작용)의 향상한다.
    • 브라우저에 직접 페이지를 렌더링 함으로써 사용자는 인터페이스와 상호작용을 할 수 있다.
    • 실시간 사용자 경험과 반응형 디자인에 매우 중요한 요소가 된다.
  • 서버 부하 감소시킴
    • 대부분의 페이지 렌더링과 로직 처리가 브라우저인 즉, 클라이언트 측에서 처리되기 때문에 서버의 요청이 최소화되고, 서버의 자원을 더 효율적으로 사용할 수 있게 된다.

단점

  • 초기 로딩 시간 지연됨
    • SSR렌더링 경우 페이지가 이미 만들어진 상태에서 전송이 되기 때문에 굉징히 빠르게 로딩이 된다는 장점이 있지만, CSR렌더링의 경우 브라우저가 JS파일을 전부 로딩되고, 실행해야지 페이지가 완전히 렌더링 되는 단점이 있다.
    • JS파일의 크기와 복잡성이 있는 경우에 초기 로딩이 지연될 수 있다. 이는 사용자가 첫 페이지를 보는데 시간이 지연됨
  • SEO 최적화 문제
    • 검색 엔진의 js처리하는 한계가 있다.
    • SEO 최적화에 대한 추가적인 노력이 필요함

CSR의 사례

  • CSR 프레임워크 앵큘러, 리액트, 뷰가 있다
  • CSR의 실제 적용 예시
    • 소셜 미디어 플랫폼, 대화형 웹 애플리케이션
    • 사용자 경험 중심의 웹 사이트가 있다.

SSR과 CSR 차이점

  • 렌더링 위치의 차이
    • SSR: 서버에서 페이지 렌더링함
    • CSR: 클라이언트(브라우저)에서 페이지 렌더링함
  • 로딩 속도 및 사용자 경험
    • SSR: 빠른초기 로딩과 서버 부하 가능성 증가함
    • CSR: 초기 로딩 지연되고, 사용자 인터랙션(상호작용) 우수함
  • SEO 최적화
    • SSR: 검색 엔진에 친화적임
    • CSR: 검색 엔진 최적화에 추가 작업이 필요함
  CSR SSR
장점 - 화면 깜빡임이 없음, - 초기 로딩 이후 구동 속도가 빠름, - 서버 부하가 분산됨 - 초기 구동 속도가 빠름 - SEO에 유리함
단점 - 초기 로딩 속도가 느림 - SEO에 불리함 - 화면 깜빡임이 있다 - 서버 부하가 증가함

3. SSR 또는 CSR을 선택해야 하는 상황

SSR 선택하는 상황

  • 콘텐츠 중심의 웹사이트 , 블로그, 뉴스 사이트 등의 SEO 중요성이 높은 프로젝트에 SSR렌더링이 더 적합하다.

CSR 선택하는 상황

  • 사용자 인터랙션(상호작용)이 중요한 애플리케이션인 SPA(Single-page Application), 대화형 웹 애플리케이션 경우에는 CSR이 더 적합하다.

💡 각 방식의 결정 요소는 사용자 경험, 로딩시간, SEO 요구사항을 고려해서 결정 해야한다.

1. next.js에서 페이지를 넘길 때마다 왜 느린가?(상황마다 다름)

: SSR에서는 초기로딩속도는 빠르지만, 새로운 페이지 요청마다 서버로부터 전체 HTML을 새로 받아와야하기 때문에 느리다.

 

2. Next.js 사용할때 서버를 따로 생성하지 않아도 Next.js가 자체적으로 서버를 만들어주는 역할을 하나요?

: Next.js를 사용할 때 별도의 서버를 구현하지 않아도 Next.js 자체적으로 서버를 생성하여 SSR을 처리한다. 필요에 따라 Custom Server를 구현하거나, 다른 서버와 통합할 수도 있다.

참고

728x90
반응형
LIST