[Next.js] CSR과 SSR

Jane·2023년 8월 23일

2

Next.js

목록 보기

3/9

TL;DR: 간단하게 표로 보기

특징	SSR	CSR
장점	● 정적인 사이트에서 이상적이다. ● 첫 페이지 접근이 빠르다. ● JS에 의존하지 않는다. ● 크롤링에 용이하여 SEO에 적합하다.	● 동적인 웹 앱에서 이상적이다. ● 첫 로드 이후에 페이지 렌더링이 빠르다. ● 애플리케이션의 반응성이 빠르게 개선되어 사용자와의 상호작용이 부드럽다. ● CSR 구현에 최적화된 JS 라이브러리가 다양하다.
단점	● 서버 요청이 많이 발생한다. ● 전체 페이지를 다시 로딩해야 해서 CSR에 비해 페이지 로드 속도가 느리다. ● 사용자와 사이트 간의 상호작용이 부드럽지 못하다. ● 서버에서 사용자 요청을 처리하여 보안 취약점에 노출될 가능성이 높다.	● 검색 엔진 크롤러가 페이지 내용을 인식하기 어려워 SEO에 적합하지 않다. ● 클라이언트 측에서 페이지를 렌더링하여 API 응답 속도가 느리다. ● 첫 페이지 로딩이 오래 걸린다. ● 추가적인 외부 라이브러리를 필요로 한다. ● 메모리 소모량이 크다.

📢 조금 더 자세히 알아봅시다!

MPA와 SPA

이미지 출처

👥 MPA

고전적인 웹 페이지 구성 방식으로, 여러 개의 페이지로 구성된 웹을 의미한다.
페이지 별로 해당 페이지에 맞는 HTML, CSS, JS 파일을 받아 화면을 구성한다.
하이퍼링크를 클릭했을 때 해당 페이지로 이동하고, 화면이 깜빡이면서 새로운 페이지에 맞는 화면이 그려지는 방식이다.
이미 하드코딩된 정적 페이지들을 서버에서 개별적으로 가지고 있다가 요청에 따라 해당 요청에 상응하는 정적 페이지를 찾아 반환한다.
렌더링이 서버 사이드에서 완료되어 최종 완성된 문서를 반환하고 있는 형태!
사용자가 페이지를 새로고침하거나 다른 페이지로 이동할 때마다 해당 페이지의 HTML 문서를 서버로부터 다시 받아와야 한다.
- 이때의 HTML 문서는 사진과 같은 컨텐츠들이 이미 포함된, 서버가 렌더링한 파일이다.
- MPA는 SSR 렌더링 방식을 사용한다.

👤 SPA

단일 페이지 애플리케이션
현재의 페이지를 동적으로 작성함으로써 사용자와 소통할 수 있는 웹 애플리케이션
최초 한 번 페이지 전체를 로딩한 뒤 데이터만 변경하여 사용할 수 있는 애플리케이션
어떤 페이지에 접속하더라도 동일한 HTML, CSS, JS 파일로 접속한 페이지에 맞게 화면을 구성한다.
연속되는 페이지 간의 UX를 향상시키고, 웹 애플리케이션이 데스크톱 애플리케이션처럼 동작하도록 돕는다.

SPA의 등장 배경

모바일 환경에 대한 수요가 증가함에 따라 모바일 웹에 대한 성능 최적화 문제가 발생했다.
PC에 비해 성능이 떨어지는 모바일 디바이스의 웹 성능 문제를 해결하기 위해 SPA가 등장하게 되었다.

🧐 SPA는 어떻게 동작하는가!

사용자 입장에서는 단순히 페이지 내용이 바뀌고, 브라우저 상에서 보이는 URL이 다르다면 다른 페이지로 보일 것이다.
이러한 사실에서 착안하여, SPA는 하나의 페이지에서 JS를 통해 보고있는 DOM의 내용을 모두 지우고 다른 컨텐츠로 DOM을 채운 뒤 브라우저 상의 URL을 변경하여 바뀐 페이지를 보고 있는 것처럼 만들어준다.
- 페이지 컨트롤 시 History API를 사용해 브라우저 세션의 히스토리 스택을 조절한다.
- 그 다음 JS로 DOM 컨트롤을 하면서 직접 화면을 변경시켜준다.
- 예: React의 React-Router-Dom
React를 통해 기능 구현 시 (CRA 환경에서는) WebPack과 같은 번들링 도구를 거쳐 하나(또는 여러 개의) 거대한 JS 파일로 번들링 되고, SPA에서는 이러한 JS 파일을 전달받아 페이지를 구축하게 된다.

이전 방식에서는 페이지 이동 시 새로고침이 발생하고, 페이지를 로드할 때마다 서버로부터 데이터를 받아 이를 해석하고 화면에 렌더링하는 방식을 사용했다.
이와 달리 SPA는 브라우저에 로드된 후 페이지 전체를 서버에 요청하는 것이 아니라, 처음 한 번 페이지 전체를 로드한 후 데이터만 변경하여 사용한다.
- 이를 통해 트래픽을 감소시켜 DB 과부하를 최소화하고, 화면 깜빡임이 사라져 사용자에게 더 나은 UX를 제공할 수 있게 되었다.
- 서버는 단지 JSON 파일만을 보내주고, 클라이언트 측에서 JS 파일을 이용해 동적으로 HTML 요소를 생성해 페이지를 업데이트하는 방식을 사용하게 된 것!

📢 이 방식이 바로 CSR!

CSR (Client-Side-Rendering)

클라이언트 가 화면을 그리는 주체!

이미지 출처

클라이언트인 브라우저가 렌더링을 처리하는 방식
서버는 올려놓은 파일을 전달해주기만 하고, 브라우저가 이 JS 파일을 실행하면서 DOM에 내용을 추가하여 렌더링하게 된다.
페이지 첫 로드 시 서버에서 모든 동작을 내려주고, HTML의 빈 부분은 클라이언트가 앞에서 다룬 Ajax 비동기 통신을 통해 요청을 보내 데이터를 fetch해오고, 페이지를 그린다.
SPA의 발전, CPU의 성능 상승, JS의 표준화 및 React, Vue, Angular와 같은 프레임워크의 등장과 함께 본격적으로 도입되었다.
관련 웹 프레임워크: React.js, Angular.js, Vue.js

// index.html
<html>
  ...
  <body>
    <div id="root"></div>
    <script src="app.js"></script>
  </body>
</html>

코드를 통해 살펴보면, body 태그 안에 root와 어플리케이션에 필요한 JS의 링크만 포함된 HTML 코드가 서버로부터 전송된다.
- 따라서 첫 접속 시 빈 HTML 화면이 보이게 된다.
- 이후 서버로부터 app.js 파일을 다운로드 받으면 어플리케이션에 필요한 로직, 구동에 필요한 프레임워크, 라이브러리 소스 코드 등이 제공된다.
- 추가적으로 데이터가 필요한 경우 서버로부터 JSON 데이터를 받아와 클라이언트 측에서 JS와 함께 동적으로 HTML 파일을 생성해 사용자에게 보여주게 된다.
npx create-react-app 실행 이후 생성된 public/index.html 파일을 생각해보면 이해하기 쉽다.
클라이언트가 초기에 JS을 읽으며 무엇을 그릴지 판단하고 렌더링하는 작업을 하는 동안 지연이 생긴다.
- 이후 작업에 있어서는 서버에 의존하지 않고 클라이언트 혼자 렌더링이 가능하다.

⚙️ CSR의 단계

사용자가 클라이언트 요청을 보낸다.
CDN이 HTML 파일과 JS로 접근할 수 있는 링크를 클라이언트에게 전송한다.
- CDN: 사용자의 요청에 물리적으로 가까운 서버에서 요청에 응답하도록 하는 방식

클라이언트는 HTML과 JS 파일을 다운로드 받는다.
- 이때 유저는 빈 화면만을 보게 된다.

다운로드가 완료된 JS 파일이 실행되고, 데이터를 요청하기 위한 API가 호출된다.
- 이때 사용자들은 placeholder(예: skeleton UI)를 보게 된다.

서버에 API 요청에 응답하여 데이터를 전송한다.
클라이언트는 API로부터 받아온 데이터를 placeholde 자리에 넣어주고, 상호작용이 가능한 페이지가 된다.

❤️‍🔥 장점

빠른 화면 전환과 인터렉션 구현 가능

View 렌더링을 브라우저가 하게 되므로 서버 트래픽을 감소시키고, 이를 통해 사용자에게 더 빠른 상호작용을 제공한다.
새로고침이 발생하지 않아 사용자가 네이티브 앱과 비슷한 경험이 가능해진다.
- 네이티브 앱
  - Android, iOS처럼 구체적인 플랫폼만을 위해 만들어진 응용 프로그램
  - 사용자에게 가장 빠르고 안정적이며 반응이 빠른 환경을 제공한다.
HTML만 받아왔을 때에는 아무것도 보이지 않다가 링크된 모든 로직을 처리하는 JS 파일이 도착하면 웹 사이트가 보여지는 동시에 상호작용이 가능해진다.

💔 단점

SSR에 비해 느린 첫 페이지 로딩 속도

서버에 첫 요청을 할 경우 전체 페이지에 대한 모든 문서 데이터를 받게 되어 SSR보다 로딩 속도가 느리다.
처음 사이트에 접속할 때 필요한 데이터를 한 번에 받아 다운로드 시간이 오래 걸리므로 사용자가 첫 화면을 보기까지의 시간이 오래 걸릴 수 있다.
이 때문에 빠르게 소비되는 컨텐츠의 경우 네트워크 상황이 좋지 않아 페이지가 노출되기까지의 시간이 오래 걸릴 경우 문제가 발생할 수 있다.

SEO에 대한 추가 보완 작업 필요

위의 코드 예시에서 알 수 있듯, CSR에서 사용되는 HTML의 body 부분은 빈 상태이기 때문에 HTML 문서를 분석해 웹 사이트에서 검색되도록 돕는 검색 엔진의 크롤러의 방식에 적합하지 않다.
Google의 검색 엔진에는 JS 엔진이 내장되어 있어 크롤링이 되긴 하지만 다른 포털 사이트 검색 엔진의 크롤러에서도 제대로 웹 사이트의 데이터가 수집되게 하려면 별도의 보완 작업이 필요하다.
- 예: sitemap 작성 (검색 엔진에 게시 될 자신의 웹 사이트 콘텐츠의 크롤링 및 인덱싱을 돕는 페이지 목록 파일)

SSR (Server-Side-Rendering)

서버 가 화면을 그리는 주체!

이미지 출처

클라이언트가 서버에 매번 데이터를 요청하여 서버에서 처리하는 방식
정적인 웹사이트에서 영감을 받아 도입된 방식이다.
클라이언트에서 요청이 들어올 때마다 매번 서버에서 새로운 View 화면을 생성하여 제공한다.
서버에서 필요한 데이터를 모두 가져와 HTML 파일과 이를 동적으로 제어할 수 있는 소스코드를 클라이언트에게 전달한다.
- 클라이언트 측에서는 HTML 파일을 받아 바로 사용자에게 보여줄 수 있다.
관련 웹 프레임워크: Next.js, Flask

자세히 알아보기

클라이언트에서는 브라우저에서 볼 파일을 생성할 로직을 포함한 파일만을 서버에 올린다.
서버에서는 HTML, CSS, JS를 렌더링하는 로직을 실행해 최종 파일을 만들어 이미 DOM 구성이 완료된 파일을 클라이언트에게 보낸다.
- 예를 들어 백엔드가 Spring 기반이면 Java, django 기반이라면 Python, Node.js의 경우 JS를 사용하여 SSR를 구현하기 위한 로직을 작성한다.
- 이를 통해 백엔드에서는 요청 URL에 대응하는 백엔드 코드를 실행해 요청에 필요한 데이터를 수집(DB에서 데이터 가져오기, API에서 데이터 호출하기)하고, HTML 파일에 데이터를 반영한다.
- 이후 서버 측에서 렌더링 엔진을 사용해 HTML, CSS, JS 파일들을 클라이언트에 보낼 수 있는 형태로 처리한 뒤 전송한다.
서버 단에서 모든 data fetching 작업과 렌더링 작업을 처리하므로 브라우저는 JS 파일을 다운로드 받는 동안 미리 화면을 렌더링하는 것이 가능해진다.
- 사용자 입장에서는 로딩 바나 Skeleton UI를 보지 않고도 바로 렌더링된 웹 페이지를 볼 수 있다.

코드를 통해 보면, 클라이언트는 서버로부터 아래와 같이 이미 다 그려진 DOM 파일을 받게 되는 것이다.

// index.html
<html>
  ...
  <body>
    <h1>WOW!:D</h1>
    <div>
      <p>화면에 그려질 내용이 모두 들어있습니다!</p>
    </div>
  </body>
</html>

⚙️ SSR의 단계

사용자가 클라이언트 요청을 보낸다.
서버는 리소스를 확인하고, 컴파일링하여 즉시 렌더링 가능한 HTML 파일을 생성한다.
클라이언트에 전달되는 순간 이미 렌더링 될 준비가 되어 있으므로 HTML은 즉시 렌더링된다.
- 이때 JS 파일은 읽히기 전이므로 사이트 자체의 조작은 불가능하다.

클라이언트가 JS 파일을 다운로드 받는다.
- 다운로드 되는 중에 사용자는 컨텐츠를 볼 수는 있지만 조작은 할 수 없다.
- 이때 페이지에서는 사용자의 조작을 기억하고 있는다.

브라우저가 다운로드 된 JS 프레임워크를 실행한다.
JS까지 성공적으로 컴파일링 된 후에는 기억된 사용자 조작이 실행되고, 상호 작용이 가능한 웹 페이지가 된다.

❤️‍🔥 장점

CSR에 비해 빠른 첫 페이지 로딩 속도

이미지 출처

CSR 방식보다 처음 서버에 요청하는 데이터의 양이 상대적으로 적다.
첫 페이지에 해당 하는 문서만 브라우저에게 전달하여 렌더링시키기 때문에 초기 로딩 속도가 CSR에 비해 빠르다.

SEO에 적합

CSR과 달리 모든 컨텐츠가 HTML 파일에 담겨서 오게 되므로 효율적인 SEO가 가능하다.

보안에 우수

사용자 정보를 서버 측 세션으로 관리하기 용이하여 CSR 방식에 비해 보안이 우수하다.

프론트엔드 영역과 백엔드 영역을 완전히 분리하여 생산성 향상 가능

이미지 출처

CSR 방식에서는 CSR 페이지를 프론트엔드에서, SSR 페이지는 백엔드에서 개발해야 했다.
하지만 SSR 환경을 구축할 경우 페이지를 온전히 프론트엔드에서 개발하게 되므로 페이지가 변경될 때마다 발생하던 불필요한 커뮤니케이션을 줄일 수 있다.
- 이를 통해 백엔드에서는 API 개발 및 데이터 활용에만 집중할 수 있게 되어 커뮤니케이션 비용이 줄고, 작업 완성도 및 이슈 대응 생산성을 높일 수 있다.

💔 단점

초기 로딩 이후 페이지 이동 시 속도 저하

페이지를 이동할 때마다 클라이언트가 서버에게 필요한 데이터를 요청하게 되어 속도가 느리다.

Blinking Issue

정적인 사이트처럼 사용자가 다른 링크로 가게 될 경우 전체 HTML 문서를 다시 받아와야 한다.
사용자가 새로고침을 할 경우 전체 웹 사이트를 서버에서 다시 받아와야 해서 화면이 없어졌다가 나타나는 문제가 발생하는데, 이는 UX의 관점에서 좋지 않다.

서버 과부하 및 비용 문제

서버가 각 사용자의 클릭에 따른 HTML 문서를 만들어야 하므로, 어플리케이션 사용자가 많을수록 서버에 데이터를 요청하는 횟수가 많아져 과부하 문제가 생길 수 있다.
서버의 자원을 사용하게 되므로 서버의 성능에 따라 CSR보다 처리 속도가 떨어질 수 있다.
매번 서버에서 로직을 실행하는 비용이 발생하고, 동적 컨텐츠가 많을 경우 캐싱 또한 무효화되므로 CSR에 비해 서버 비용이 많이 발생할 수 있다.

TTV와 TTI 간 공백 시간 발생

HTML 파일을 받았음에도 동적으로 웹을 제어하는 JS 파일을 받지 못해 사용자가 웹 어플리케이션을 클릭해도 웹이 반응하지 않는 문제 상황이 발생할 수 있다.
- 최종적으로 JS 파일이 도착해야 사용자가 원하는 동작을 처리할 수 있는 상호작용이 가능해진다.
이 때문에 사용자가 사이트를 볼 수 있는 시간(TTV)과 실제로 인터렉션이 가능한 시간(TTI) 사이에 공백 시간이 생긴다.

👥 Hydration

👥 렌더링이 정말 매번 요청할 때마다 필요한가요?

🔎 References

참고 자료 모음

An investment in knowledge pays the best interest🙃

이전 포스트

[Next.js] 웹 브라우저 렌더링의 발전 과정

다음 포스트

[Next.js] Hydration

0개의 댓글