카테부에서 아래와 같은 주제에 대해 딥다이브 세션을 진행해보았다.

웹 페이지 렌더링 방식이 CSR, SSR, SSG 차이에 대해 정리하시오.

지난 포스트에서 배경지식을 위해 웹 렌더링에 공부한 내용을 포스트했었다.

[ 아래링크 참고 ]
[딥다이브 week2-1] 웹 페이지 렌더링이란?

이 포스트에서는 이제 본격적으로 웹 페이지 렌더링 방식들 (CSR, SSR, SSG, ISR, Universal Rendering), 웹 애플리케이션 특성 (SPA, MPA), SEO와의 관계성에 대해 정리해보려고 한다.

---

웹페이지 렌더링 방식

: 이전포스트에서 얘기했듯이 웹 렌더링이란, 웹페이지를 사용자가 볼 수 있는 형태로 변환하는 일련의 과정을 말함.

웹페이지 렌더링 방식에서 이야기하는것은 클라이언트가 렌더링 한다 vs 서버가 렌더링 한다 인데,
여기서 말하는 렌더링은 이전포스트에서 말한 렌더링과는 조금 다름.

브라우저 엔진이 하는 전체 렌더링 파이프라인을 뜻한다기 보다는 :

• 초기 HTML을 어디서, 어떻게 만들어서 브라우저에게 넘겨주느냐에 초점이 있음.
• 서버가 JS를 실행해 컴포넌트를 모두 HTML 문자열로 반환하여 그 완성된 HTML 문서를 보내준다 아니다.
• 클라이언트가 JS를 따로 실행전에도 화면에 내용을 바로 표시할 수 있다 아니다.

⇒ 예를 들어, SSR에서 서버가 HTML을 만들어준다고 해도, 브라우저는 여전히 다음 작업은 해야한다.

• HTML 파싱 → DOM 생성
• CSS 파싱 → CSSOM 생성
• DOM + CSSOM → 렌더 트리 생성
• 레이아웃, 페인팅, 컴포지팅
• 필요 시 동적으로 추가 JS 엔진 실행

따라서 “웹페이지 렌더링 방식”은 실제로 HTML + CSS 파일을 웹 “화면에 그리는” 작업 이전의 과정을 어떤 쪽에서 도맡아 수행하냐에 대한 내용임.

→ 렌더링 방식에 따라 로딩속도, 검색 엔진 최적화, 사용자 경험 등이 달라짐.

CSR (Client Side Rendering)

클라이언트(브라우저)에서 웹 페이지를 렌더링 하는 것

• 서버 : 최소한의 HTML 껍데기 뼈대만 전달
• 브라우저 : JS엔진 실행 후, 데이터를 다 채워넣고 DOM을 구성해 화면을 그림
• 초기 화면을 만드는 역할을 클라이언트(JS엔진)에 맡김

동작방식

1. 브라우저가 초기 HTML index.html 을 다운로드

   : 사용자가 웹 페이지 방문 → 브라우저는 웹 서버에 HTTP 요청 → 서버는 브라우저에게 index.html 을 포함한 초기 응답을 보냄 (index.html 은 기본 레이아웃 및 초기 구조만 정의된 빈껍데기)

2. 자바스크립트 파일 다운로드

   : index.html 에 포함된 자바스크립트 번들 파일 다운로드 (웹의 논리 및 동장방식 정의)

3. API 요청 및 동적 컨텐츠 로드

   : 브라우저는 자바스크립트를 해석하고 실행 → AJAX, Fetch API 등을 사용하여 서버로부터 동적 데이터를 가져옴 → 받아온 데이터를 파싱하여 웹 페이지에 동적으로 추가

4. 최종 컨텐츠 렌더링

   : 서버로부터 받은 html (웹 레이아웃, 뼈대 구조), JS (요소별 기능), 동적 데이터를 사용하여, 브라우저가 웹 페이지의 최종 컨텐츠를 동적으로 생성 (렌더링) 한다. 서버로부터 가져온 동적 데이터의 경우 HTML DOM에 추가하여 렌더링한다.

   ⇒ 즉, 브라우저 쪽에서 렌더링 엔진을 동적으로 돌리는 것임.

5. 페이지 이동 시 자바스크립트만 재사용

   : 새로운 HTML 파일을 요청하지 않아도 됨 (기존에 이미 기본 뼈대인 index.html 을 서버로부터 받았기 때문에). 대신, 이미 다운로드된 자바스크립트를 재사용하여 새로운 데이터를 가져오고 필요한 부분만 일부 재렌더링 한다. 전체페이지를 html 부터 다시 로드하는 것이 아니다.

장점

• 모든 script, meta, link 등이 사전에 로드되었기 때문에 초기 로딩 후에는 추가 로드 시간이 줄어들고, 서버를 호출할 때마다 전체 UI 를 다시 로드할 필요가 없다.
• 전체페이지를 매번 새로 렌더링 하지 않고, 변화가 있는 부분만 업데이트 하면 되므로 서버부하 감소
• 만약 스크립트까지 캐싱된게 있으면, 인터넷 없이도 CSR 웹 애플리케이션 실행이 가능하다.

단점

• SEO에 불리하다. JS 실행전에는 빈 HTML 껍데기일 뿐, 데이터 키워드 등이 없다.
• 브라우저에서 사용할 수 있는 컨텐츠로 HTML을 컴파일하기 전에, 기본 index.html 과 기본 CSS 등 필수파일을 로드해야 하고, 브라우저가 JavaScript를 직접 실행하여 데이터를 채우고 만들어야 하기 때문에 초기 화면 구성 시간이 SSR보다 느리다.
• 이 초기 로드 시간동안 사용자는 아예 빈페이지를 보게 되므로 사용자 경험이 좋지 않다.

적합한 상황

• 사용자와의 상호작용이 많은 웹사이트에 적합
• 사용자의 입력에 따라 화면이 동적으로 변하는 일이 잦은 경우와 SEO가 크게 중요하지 않은 경우

SSR (Server Side Rendering)

서버측의 HTML로 렌더링하는 방식

웹 애플리케이션의 초기 렌더링을 서버에서 처리하고, 클라이언트에 전달하는 방식

• 서버 : JS까지 실행에서 미리 완성된 (데이터까지 다 채워진) HTML 문서를 완성해 전달
• 브라우저 : 받은 HTML을 JS엔진 실행 없이 바로 DOM으로 만들어 표시하고, 이후 JS 필요시 동작
• 초기화면을 만드는 역할을 서버에서 처음 한번 다 해주고 넘김.

동작방식

1. 사용자 요청 처리

   : 사용자가 웹 페이지 방문 시, 브라우저가 서버로 그 요청을 전송

2. 서버 측 렌더링 (브라우저가 html 파일 다운 X)

   : 서버가 필요한 데이터와 리소스를 가져옴 → 페이지에 포함된 서버 측 스크립트를 실행 → 페이지의 동적인 부분에 데이터를 채워 초기 상태 생성 → 초기 상태와 함께 전체 페이지의 HTML을 컴파일

3. HTML 전송

   : 생성된 HTML을 초기상태와 함께 클라이언트에게 응답으로 보냄

4. 브라우저에서 HTML 및 자바스크립트 처리

   : 서버로부터 받은 HTML을 화면에 표시 → 사용자는 초기 페이지를 볼 수 있음 → 이후에는 클라이언트 측 자바스크립트를 활성화하여 사용자의 상호작용에 따라 페이지를 업데이트 및 추가적인 데이터 요청 후 재렌더링

5. 페이지 이동 시 작업 반복

   : 페이지 이동 시, 클라이언트는 서버로 새로운 요청을 보내고 SSR 프로세스가 다시 시작됨.
   → 새로운 HTML 이 다시 서버로부터 다운로드 되고 브라우저에 의해 처리됨

장점

• 렌더링이 준비된 HTML 파일을 브라우저에서 로드하기 때문에 CSR에 비해 초기 페이지 로드시간이 더 빠르다.
• 이미 다 만들어진 페이지를 검색엔진 크롤러가 받기 떄문에 SEO에 친화적이다.
• 컴퓨팅 성능이 더 뛰어난 “서버”를 이용해 소프트웨어 성능 영향을 줄임 → 클라이언트 부담 감소
• 서버에서 페이지 로직 및 렌더링 실행 시 클라이언트는 적은 자바스크립트만 있어도 됨

단점

• 페이지 이동시마다, 각 요청이 올 때마다 서버에서 HTML 페이지를 생성하는데 시간이 걸림
• 초기 페이지 로드 시 필요한 데이터가 방대하면 오히려 서버 준비 기간이 길어져 첫 페이지 로딩시간이 오래걸릴 수 있음. (CSR의 경우 일단 빈화면 혹은 레이아웃만 뜨고, 브라우저가 JS엔진을 다 돌리면 그때 데이터가 뜨고, SSR의 경우 초기 데이터가 엄청 많으면 화면 로딩 자체가 늦게됨)
• 클라이언트에서 자바스크립트를 이용해 렌더링하는 CSR에 비해 요청마다 서버가 HTML파일과 안에 내용을 생성해야 하기 때문에 서버 호스팅이 증가

적합한 상황

• 동적 컨텐츠가 많은 웹사이트 → 항상 전체 렌더링을 통해 최신 상태의 웹사이트를 제공해야 하는 경우
• 검색 엔진 노출이 중요한 웹사이트
• 초기 로딩 속도가 중요한 사이트

SSG (Static Site Generation)

“빌드 타임”에 모든 페이지를 HTML 파일로 미리 생성하는 방식.

• “빌드 타임”이 내가 생각한 그 빌드가 맞았음. “개발자가 코드를 빌드할 때”임.
• 즉, 배포전에 미리 HTML 파일을 다 생성해놓고 서버/CDN에 올려두는 것. (HTML 하드코딩느낌)
• 사이트 생성 후 백엔드가 필요하지 않으므로 CDN을 사용한다.
• 주로 제품 페이지, 뉴스 기사, 소프트웨어 문서, 블로그 등 거의 변경되지 않는 정보성 콘텐츠에 사용

동작 과정

1. 빌드 시에 서버는 모든 가능한 요청경로에 대한 HTML을 각각 미리 생성
2. 사용자가 웹사이트 접속 시, 서버(CDN)은 미리 생성해 둔 HTML을 보냄
3. 브라우저는 받은 HTML을 그림 (화면에 표시함)
4. 추가 페이지 요청 시, 미리 생성해둔 해당 페이지의 HTML을 CDN에서 꺼내 제공함.

장점

• 매우 빠른 응답 (CDN에서 정적 파일 제공)
• 서버 부하가 그냥 없음 (서버에서 매번 렌더링 필요없이 CDN에서 렌더링된 파일을 그냥 주면됨)
• SEO 친화적 (이미 HTML 완성됨)

단점

• 실시간 데이터 반영이 어려움 → 게시물 추가/수정 시, 다시 빌드해야함
• 데이터 변경이 필요할 시, 전체 사이트를 닷 ㅣ빌드해야 함.

ISR (Incremental Static Regeneration)

SSG와 SSR의 단점을 보완하고 장점을 결합한 렌더링 방식

빌드 시점에 페이지를 미리 생성하면서도, 특정 시간 간격으로 페이지를 재생성하여 업데이트 데이터 반영

동작과정

1. SSG와 동일하지만, 빌드 시점에 Next.js에서 getStaticProps와 revalidate 옵션을 이용하여 페이지를 언제, 어떻게 생성할 지를 설정함

2. 새로운 요청 및 페이지 재생성
   : 새로운 사용자 요청이 들어왔을 때, revalidate 옵션 설정 시간이 경과된 상태라면 해당 페이지를 서버에서 재생성.

장점

• SSG의 장점 + 데이터 주기적으로 반영

단점

• 구현 복잡성 : 각 페이지의 상태를 옵션으로 관리하고 재생성 로직을 다 짜야함
• 재생성 시간 : 페이지 재생성하는데 시간이 소요됨. (빈번하게 바뀌는 데이터는 어려울 수 있음)

Universal Rendering

CSR 과 SSR의 장점을 모두 합친 렌더링 방식으로, 서버와 클라이언트측 모두에서 동일한 JS 컴포넌트 코드를 실행해 양쪽에서 모두 실행하는 렌더링 방식이다.

동작 방식

1. 서버에서 먼저 JS를 돌리고 HTML까지 생성해서 브라우저에 전달 → 초기 화면이 바로 보임

2. 브라우저에서는 같은 코드를 똑같이 다시 실행해 이벤트 바인딩, 동적 상호작용을 붙임 “하이드레이션”

   → 뼈대 html 안에 데이터를 똑같이 다 채워놨고 이벤트도 동기화 시켰으므로 이후에는 html을 다시 서버로부터 다 다시 불러올 필요 없이 동적 데이터 할당이 가능함.

단점

• 하이드레이션 과정이 무거움.

검색 엔진 최적화(SEO) 와 웹 사이트 렌더링 기법의 관계

검색 엔진은 웹페이지를 “크롤러”로 읽고, 내용을 분석해서 결과에 노출함.

검색 엔진은 아래 요소에 따라 사이트를 크롤링, 상단에 노출시킴

• 콘텐츠 품질 (키워드가 적절히 포함된, HTML의 제목, 헤딩 등의 태그가 잘 구조화된)
• 웹페이지 구조 (크롤러가 읽기 쉬운 HTML 구조)
• 렌더링 방식
  • JS 로만 화면을 그리는 CSR 사이트는 검색엔진이 제대로 내용을 읽지 못할 수 있음
  • SEO가 중요한 웹 서비스에서는 주로 SSR, SSG을 적용하기도 함
• 웹 성능 (빠른 로딩 속도, 접근성 등의 점수)

⇒ SEO는 이 검색 엔진이 내 사이트를 더 잘 이해하고, 상위에 노출할 수 있도록 하는 전략과 기술임.

웹 애플리케이션 특성

Single Page Application (SPA)

: 하나의 브라우저 내에서 동작하는 애플리케이션

• 사용하는 동안 추가적인 페이지 로딩을 필요로 하지 않고, 우리가 방문하고 사용하는 모든 컨텐츠는 하나의 웹페이지 안에서 이루어진다.
• 필요한 데이터만 JavaScript로 불러와서 화면 일부만 갱신하는 방식.
• ex) Gmail, Google Maps, Facebook, GitHub 등이 SPA에 해당

⇒ 따라서 전통적으로는 CSR을 사용했음

장점

• 빠른 화면전환 : 페이지 리로드가 없기 떄문에 전환 간에 렌더링을 기다리는 시간도 없다.
• 사용자 경험 ⬆️

단점

• 초기 로딩이 무거움
• JS 실행 전에는 내용이 없어서 SEO 불리할 수 있음

Multi Page Application (MPA)

: 전통적인 방식으로, 페이지 이동 시마다 서버가 HTML을 새로 렌더링해서 보낸다.

• 브라우저에서 변경사항이 있을 때 서버로 새로운 페이지 렌더링을 요청하고 그것을 표시
• 기본적으로 규모가 더 크고 많은 UI 레벨을 갖게 된다 → AJAX 사용
• ex) 네이버, 다음 같은 포털의 초기 구조

⇒ 따라서 전통적으로는 SSR을 사용했음

장점

• SEO에 유리 (서버가 완성된 HTML을 내려줌)

단점

• 매번 전체 페이지를 새로 렌더링해서 받으므로 전환 속도가 낮다

궁금증들

🤔 그럼 MPA는 무조건 SSR방식을 사용한다는건가요?

서버가 HTML 페이지를 렌더링해서 보낸다길래..

⇒ 전통적으로는 주로 SSR 구조를 사용했음. 최근엔 MPA 안에서도 CSR을 섞기도 함.

SPA = 구조적 특성 (페이지 1개)

MPA = 구조적 특성 (여러 페이지)

CSR/SSR/SSG = 화면을 "어디서, 언제" 그릴지에 대한 렌더링 전략

• SPA + CSR → 전형적인 React/Vue 앱. SEO 약함. (ex. 순수 CRA 앱)
• SPA + SSR/SSG/ISR → SEO 보완 가능. (ex. Next.js, Nuxt.js)
• MPA + SSR → 전통적 서버 렌더링. SEO 강함. (ex. JSP, PHP, Django 등)
• MPA + CSR 혼합 → 일부 페이지는 서버 렌더링, 일부는 클라이언트 렌더링.

[정리]

• SPA 자체가 SEO에 약한 건 CSR 기반이기 때문.
• 하지만 SSR/SSG를 쓰면 SPA도 SEO에 강해질 수 있음.
• MPA는 기본적으로 SSR이라 SEO 친화적.
• 현대 프레임워크(Next.js, Nuxt.js)는 SPA 구조를 유지하면서도 SSR/SSG를 지원해 SEO와 성능을 동시에 잡음.

🤔 AJAX는 뭐고 이걸 왜 MPA에 사용하죠? 관계가 있나요?

AJAX (Asynchronous JavaScript And XML)

웹 페이지를 새로고침하지 않고 서버와 데이터를 주고받을 수 있게 해주는 기술

무중단배포같은거네요?

비동기 요청
→ 화면 전환 시 UI가 크게 안바뀐다면 화면 전체가 아닌 필요한 데이터만 갱신할 수 있도록 사용하는 방식

• MPA의 경우 UI 레벨이 복잡하고 자주 화면 전환이 일어날 수있는데, 이때마다 서버에게 전체를 렌더링을 부탁하기는 어려움 → AJAX 방식 사용
• 이렇게 하면 MPA 에서도 부분적으로 SPA 같은 사용자 경험 (SSR 기반) 을 제공할 수 있음.

🤔 스프링부트 view 렌더링 방식

스프링부트의 Controller에서 반환한 값을 브라우저에서 API url로 접근 시 직접 확인할 수 있다.

• Map, Dto, List, JSON은 그냥 JSON 데이터로 보이고,
• String은 그냥 String 값이 보인다.

이 때, String의 경우에는 서버에서 View를 렌더링해 보내고 브라우저에서 그 View를 바로 띄우는 구조라고 한다.

1. @Controller 가 String을 반환할 시
2. ViewResolver가 그 이름에 맞는 HTML/JSP/Thymeleaf 템플릿을 찾아서 실행
3. 서버 쪽에서 템플릿 엔진을 실행해 HTML (반환값인 String view를 포함한) 을 완성에 response body에 실어 보냄
4. 브라우저는 그 완성된 HTML을 받아 그대로 렌더링 함.

⇒ 따라서 이런 흐름은 서버에서 이미 완성된 HTML을 내려주기 때문에 SSR과 가깝다고 볼 수 있다.

⇒ 하지만 SSR 이라는 용어는 보통 JS 컴포넌트를 서버에서 미리 HTML로 채워넣는다는 의미로 쓰므로 똑같은 개념은 아니다.

---

출처

https://hooninedev.com/240409/

https://yong-nyong.tistory.com/86

https://velog.io/@4ggie97/SEO-Search-Engine-Optimization

https://velog.io/@jodheeee/WEB-웹-렌더링의-방식SSR-CSR-SSG