[Web] Rendering Pattern - SSG, SSR, CSR, MPA, SPA

Euiyeon Park·2024년 8월 27일

CDN CSR JavaScript MPA Rendering Pattern SSR Search Engine TIL Web Crawler rendering seo spa ssg web

Web

목록 보기

12/13

Rendering의 두 가지 의미

Rendering은 사용자에게 보여지는 웹 페이지를 만드는 것인데,
맥락에 따라 두 가지 렌더링이 있다.

HTML 문서를 완성함 - 서버와 클라이언트 둘 다 가능하다 (SSR, CSR)
Render Tree를 생성함 - 항상 브라우저가 생성한다

Rendering Pattern

어떤 방법과 기술, 접근법을 이용하여 Rendering 할 것인가?

Rendering Pattern이란 웹 페이지를 화면에 보여주는 방법 및 전략을 의미한다.

🍔 Static Web sites - SSG

정적 페이지를 반환하는 웹 서버(Nginx, Apache, S3)를 활용한다.

Static Websites는 가장 초기의 웹 페이지 형태이다.
초창기 웹 페이지는 한번 만들면 거의 변경될 일이 없었기 때문이다.

이미 만들어진 웹 페이지인 정적 웹 페이지를 요청에 따라 반환하므로
웹 서버 또는 스토리지(Storage) 중 하나를 선택해서 사용한다.

🍟 SSG(Static Site Generation)

SSG란 웹 페이지를 서버에서 미리 생성하여 정적 HTML파일로 저장하고,
사용자가 요청할 때 정적 파일을 제공하는 방식이다.

📌 SSG 특징

(AWS S3같은 정적 리소스 저장소 사용 시) 서버가 불필요하다.
스토리지/서버가 반환하고자 하는 모든 정적 웹 페이지를 갖고 있어야 한다.
서버에서 모든 페이지를 Build Time에 생성한다.
Build Time에 완성되어 스토리지/서버가 가지고 있는 정적 웹페이지를 반환만 하면 되기때문에 빠른 반환 및 로딩 속도를 가진다.
- 그러나 실시간성에 위배될 수 있다.
미리 생성된 정적 리소스(HTML/CSS/JS)를 CDN에 캐싱하여 네트워크 트래픽을 줄이고 사용자의 요청에 빠르게 응답할 수 있다.
SSG는 정적 컨텐츠가 많은 웹 사이트에 유용하다.
구글과 같은 검색엔진 최적화(SEO)에 유리하다 - 웹 크롤러가 수집이 가능하다.

🪄[참고] CDN(Content Delivery Network)

CDN은 웹 컨텐츠를 사용자에게 빠르고 효율적으로 제공하기 위한 분산 서버 네트워크다.
CDN은 전 세계 여러 지점에 위치한 서버로 구성되며, 웹 사이트나 어플리케이션에서 요청된 컨텐츠를 사용자에게 더 가까운 서버에서 제공해 로드 타임을 줄이고 성능을 향상시킨다.

사용자가 컨텐츠에 접근할 때, 요청이 원본 서버까지 가지 않고 사용자와 지리적으로 가까운 CDN 서버에서 직접 제공하기 위해 컨텐츠를 원본 서버에서 전 세계에 분산된 여러 엣지 서버(Edge Server)에 복사하여 저장한다.(CDN 캐시)

🍔 MPA와 SSR

동적 웹 페이지를 반환하는 웹 어플리케이션 서버(WAS)를 활용한다.
대표적으로 Tomcat (Spring Boot + Thymeleaf)

🍟 MPA(Multi-Page Application)

MPA는 여러 개의 개별적인 페이지로 구성된 전통적인 웹 어플리케이션을 의미한다.
웹 어플리케이션 내에서 다른 페이지로 이동할 때마다(새로운 페이지를 요청할 때마다)
전체 페이지가 새로 로드된다.

📌 MPA 특징

사용자가 다른 페이지로 이동하면, 서버로부터 새로운 HTML/CSS/JS를 불러와
페이지 전체가 새로고침된다.
- 이미 컨텐츠가 들어있는 상태의 HTML으로 페이지 전체를 새롭게 로드한다.
- 서버에서 이미 렌더링된 파일을 주기 때문에, MPA는 SSR을 채택한다.
각 페이지가 독립적인 URL을 가지고 있어 SEO에 유리할 수 있다.
페이지가 많아질수록 어플리케이션의 복잡성이 증가한다.

🍟 SSR(Server-Side Rendering)

SSR은 웹 페이지의 HTML이 서버에서 렌더링되어 클라이언트에게 전달되는 방식이다.
사용자가 브라우저에서 페이지를 요청하면, 서버는 미리 렌더링된 HTML을 보내준다.

📌 SSR 특징

HTML컨텐츠가 서버에서 미리 렌더링된 상태로 받아오므로 초기 로딩 속도가 빠르다.
서버가 생성해서 반환하므로 웹 페이지 반환속도는
DB 반환속도, 웹 페이지 생성속도에 의존한다.
- 서버의 CPU, 메모리 자원 사용량이 많아진다.
ViewTemplate과 Model을 조합해 요청에 따라서 웹 페이지를 생성하기 때문에
(Static Website에 비해) 용량 관리에 효율적이다.
- Static Website는 모든 정적 웹 페이지를 서버가 가지고 있어야 한다.
- 요청에 따라 실시간으로 데이터를 조회하고 페이지를 생성한다.
- CSS, JS는 불변적이고 DOM은 Model에 따라 달라지므로 가변적이다.
서버에서 HTML을 생성하기 때문에,
검색엔진 크롤러가 페이지 내용을 더 쉽게 읽을 수 있어 SEO에 유리하다.
- CSR의 경우 JavaScript가 실행되기 전까지 크롤러가 충분한 정보를 얻지 못한다.
클라이언트와 서버 간의 상태 동기화와 캐싱 전략이 필요해지며,
복잡한 어플리케이션에서 구현이 어려울 수 있다.
- SSR에서 초기 HTML을 렌더링하고 클라이언트에게 보낸 이후에
  페이지가 동적으로 업데이트되거나 상호작용이 필요할 때,
  클라이언트 측 JavaScript가 실행되어 상태를 관리된다.
- SSR은 요청이 있을 때마다 서버가 HTML을 생성하기 때문에
  서버에 상당한 부하를 줄 수있다.
  따라서 성능 최적화를 위해 캐싱 전략이 필요하다.

🍟 MPA는 왜 SSR로 렌더링할까?

MPA의 특성상 각 페이지 전환마다 전체 페이지를 새로고침하므로
SSR이 자연스럽고 효율적이다.

MPA는 사용자가 페이지를 이동할 때마다 서버에 새로운 페이지를 요청한다.
서버는 이 요청에 따라 새로운(완성된) HTML을 다시 생성해서 클라이언트에게 보내준다.

SSR은 서버에서 페이지를 완전히 렌더링한 HTML을 클라이언트에게 제공하는 방식이다.

🍔 SPA와 CSR

웹 브라우저 내의 자바스크립트를 활용해 동적 페이지를 생성한다.
자바스크립트 반환을 위한 웹 서버 또는 스토리지를 이용한다.

🍟 SPA(Single-Page Application)

SPA란 단일 HTML 페이지로 구성된 웹 어플리케이션을 의미한다.
사용자가 방문한 첫 페이지에서 필요한 모든 HTML/CSS/JS를 한번에 로드하고
그 이후에는 페이지 전환 없이 동적으로 컨텐츠를 변경한다.

📌 SPA 특징

초기 로드 시 모든 리소스를 받아온 후 페이지 전환과 컨텐츠 업데이트는
JavaScript를 통해 수행되며 전체 페이지가 아닌 일부 컨텐츠만 동적으로 변경된다.
- 초기 로드에 모든 리소스를 받아오므로 초기 로딩 시간이 길어진다.
일반적으로 SPA는 클라이언트 측에서 렌더링 되기때문에 검색엔진 크롤러가
컨텐츠를 제대로 인식하지 못할 수 있다.
- SEO에 불리할 수 있으며, 추가적인 최적화 작업이 필요할 수 있다.
페이지 전환 시 서버 요청이 줄어들어 네트워크 트래픽이 감소한다.
페이지 전환 시 전체 페이지가 새로고침되지 않으므로
어플리케이션의 반응성이 뛰어나고 사용자 경험이 빠르고 부드럽다.
- 웹에서 앱의 경험이 가능하다.
클라이언트 측에서 상태를 관리해야하므로, 어플리케이션이 복잡해질 수록 상태 관리도 복잡해진다.

🍟 CSR(Client-Side Rendering)

CSR은 클라이언트(브라우저) 측에서 JavaScript를 사용해 웹 페이지의 HTML을 동적으로 생성하는 렌더링 방식이다.
사용자가 페이지를 요청할 때 서버는 기본 HTML파일을 전달하고,
클라이언트측에서 JavaScript가 실행되어 컨텐츠를 렌더링 한다.

📌 CSR 특징

(AWS S3 같은 저장소 사용 시) 서버가 불필요하다.
서버에서 최소한의 HTML(또는 빈 HTML)을 전달하며, 이후 클라이언트 측에서 JavaScript가 실행되어 DOM을 동적으로 조작해 컨텐츠를 생성한다.
- 데이터가 필요하면 API 호출을 통해 서버에서 데이터를 받아와 화면에 표시한다.
- 템플릿 엔진의 역할을 JavaScript가 담당한다.
웹 브라우저가 동적 웹 페이지를 생성해 반환하기 때문에,
웹 페이지 전환 시 깜빡임이 존재하지않는다.
초기 HTML이 거의 비어있기에 검색엔진 크롤러가 페이지의 컨텐츠를 제대로 인식하지 못할 수 있어, SEO에 불리하다.
초기 렌더링 이후 서버와 상호작용 없이 클라이언트에서 컨텐츠를 동적으로 변경할 수 있어 사용자와 어플리케이션 간의 상호 작용이 빠르다.
- 초기 로딩 이후 페이지 내에서 클릭, 스크롤, 입력 등의 사용자 상호작용이 발생할 때마다 서버에 새 요청을 보내지 않고, 이미 로드된 클라이언트 측 JavaScript가 데이터를 처리하고 DOM을 조작해 페이지를 동적으로 업데이트한다.
페이지 전환 없이 클라이언트 측에서 자유롭게 렌더링을 조정할 수 있어
사용자 경험이 뛰어나다.
서버는 기본 HTML과 JavaScript만 제공하므로 서버 부하가 줄어들고 네트워크 트래픽이 감소한다.
JavaScript 파일이 클라이언트에서 실행되어야 페이지가 완전히 렌더링되므로
초기 로딩 시간이 길 수 있다.
JavaScript 의존도가 높다
- 사용자의 브라우저에서 JavaScript가 비활성화되어 있거나 오류가 발생하면 페이지가 제대로 렌더링 되지 않을 수 있다.

🍟 SPA는 왜 CSR로 렌더링할까?

SPA는 클라이언트 측에서 전체 어플리케이션을 관리하고, 빠르고 매끄러운 사용자 경험을 제공하는데 중점을 두며, 이는 CSR로 렌더링할 때 더 효과적이다.

SPA는 처음에 하나의 HTML 페이지를 로드하고, 그 이후에는 클라이언트 측에서 관리한다. 페이지 전환이 필요한 경우에도 서버에 새로운 HTML을 요청하지 않고,
이미 로드된 JavaScript가 필요한 부분만 동적으로 업데이트한다.

CSR은 클라이언트 측에서 JavaScript가 전체 페이지 또는 일부를 렌더링하므로
페이지 전환 시에도 전체 페이지를 다시 로드할 필요가 없다.

🪄[참고] 웹 크롤러의 시점

위에서 MPA, SPA, SSR, CSR을 다루면서 웹 크롤러와 SEO와 관련된 얘기가 많이 나와
참고사항으로 정리하고자 한다.

우선 SPA와 CSR에서
' 크롤러가 렌더링을 좀 기다렸다가 정보를 수집을 하면 되지 않나..? '
라는 호기심에서 시작되었다.

우선 검색엔진 크롤러가 HTML파일을 받는 시점은 서버가 HTTP요청에 응답하는 시점이다.
일반적인 웹 어플리케이션에서 크롤러는 클라이언트가 서버에 요청을 보내면 서버가 즉시 응답하는 HTML을 받아간다.

그러나 CSR과 SPA는 서버가 응답하는 HTML이 완전한 컨텐츠를 포함하지 않기 때문에 크롤러가 페이지를 제대로 인덱싱하지 못하는 경우가 생겨 SEO에 불리할 수 있다는 것이다.

하지만 여기서 여전히 의문은 남아있다.
'그러니까 좀 기다리면 되지 않냐구 ...'

CSR과 SPA는 JavaScirpt를 통해 페이지를 동적으로 렌더링하는데,
모든 크롤러가 JavaScript를 실행하는 것은 아니다.
또한 크롤러는 웹 상의 수많은 페이지를 빠르게 수집해야되는데, JavaScript를 실행하고 페이지가 완전히 렌더링되기까지 기다리는 것은 시간이 많이 소요될 수 있으므로
크롤러는 기본적으로 서버에서 바로 제공하는 HTML을 우선적으로 수집한다.