브라우저 렌더링이란?
브라우저가 서버로부터 요청해 받은 내용을 브라우저 화면(View)에 표시해주는 작업을 말한다.
브라우저가 서버로부터 HTML, CSS, JavaScript 문서를 전달받아 브라우저 엔진이 각 문서를 해석해 브라우저 화면을 그려준다.
브라우저 렌더링은 크게 클라이언트 사이드 렌더링(CSR)과 서버 사이드 렌더링(SSR) 방식으로 나누어진다.
클라이언트 사이드 렌더링(CSR)
CSR은 "Client-Side Rendering"의 약어로, 클라이언트 측에서 페이지를 렌더링하는 방식을 말한다. CSR은 서버로부터 받아온 데이터를 클라이언트에서 JavaScript를 통해 동적으로 조작하여 렌더링한다.
클라이언트에서 데이터를 받아오고 렌더링하기 때문에 초기 로딩 속도는 느리지만, 이후에는 페이지 이동이 빠르고 사용자 경험을 향상시키는 등의 이점이 있다.
또한 CSR은 클라이언트에서 캐시를 사용하여 적은 양의 데이터만 다시 요청하여 처리하는 것이 가능하다.
CSR의 실행과정
1. 사용자가 웹 사이트에 요청을 보낸다.
2. CDN이 HTML 파일과 JS로 접근 할 수 있는 링크를 클라이언트로 보낸다.
3. 클라이언트는 HTML과 JS를 다운로드 받는다.
4. 브라우저가 자바스크립트를 다운로드 받는다.
5. 다운로드가 완료된 JS가 실행이 되며 데이터를 위한 API가 호출이 된다.
6. 서버가 API로 부터의 요청에 응답한다.
7. API로부터 받아온 데이터를 placeholer 자리에 넣어주면, 페이지가 상호작용이 가능해진다.
CSR의 장점
- 높은 사용자 경험: CSR은 클라이언트 측에서 데이터를 받아와 렌더링하기 때문에 페이지 이동 속도가 빠르고, 사용자 경험이 높다.
- 캐싱 가능: 클라이언트에서 캐시를 사용하여 적은 양의 데이터만 다시 요청하여 처리하는 것이 가능하다.
- 적은 서버 부하: CSR에서는 클라이언트에서 데이터를 처리하기 때문에 서버 부하가 적다.
CSR의 단점
- 느린 초기 로딩 속도: CSR은 페이지를 렌더링하기 위해 필요한 JavaScript 파일을 먼저 다운로드한 후에 데이터를 받아와야 한다. 이로 인해 초기 로딩 속도가 느리게 느껴질 수 있다.
- SEO에 불리함: CSR에서는 초기 HTML 파일에 콘텐츠가 포함되어 있지 않기 때문에 검색 엔진이 페이지를 크롤링할 때 콘텐츠를 인식하지 못할 수 있다.
- 낮은 보안성: CSR에서는 클라이언트에서 데이터를 처리하기 때문에 보안성이 낮을 수 있다. 클라이언트 측에서 데이터를 조작하거나 해킹 등의 공격이 가능하다.
- 높은 개발 난이도: CSR은 대규모의 복잡한 웹 애플리케이션에서 많이 사용되며, 이를 구현하기 위해서는 높은 개발 난이도와 복잡성이 요구된다. 특히, 상태 관리와 라우팅 등을 구현하기 위해서는 추가적인 라이브러리나 프레임워크를 사용해야 한다.
서버 사이드 렌더링(SSR)
SSR은 "Server-Side Rendering"의 약어로, 서버 측에서 페이지를 렌더링하는 방식이다. 서버에서 페이지를 렌더링한 후에, 클라이언트에게 전달되며, 클라이언트에서는 추가적인 JavaScript 로딩이 필요하지 않다. SSR은 초기 로딩 속도가 빠르고, SEO에 유리하며, 서버에서 데이터를 처리하므로 보안성이 높다. 그러나 페이지 이동이 느리고, 서버에서 처리하기 때문에 서버의 부하가 증가할 수 있다.
SSR의 실행과정
1. 사용자가 웹 사이트에 요청을 보낸다.
2. Server는 ‘Ready to Render’ 즉시 렌더링 가능한 html 파일을 만든다.
3. 클라이언트에 전달하는 순간 이미 렌더링 준비가 되었기 때문에 HTML이 즉시 렌더링이 된다. 하지만 사이트에서 조작은 불가능하다.(JavaScript가 읽히기 전)
4. 브라우저가 자바스크립트를 다운 받는다.
5. 다운로드가 이루어지고 있는 상태에서 사용자는 컨텐츠를 볼 수 있지만 사이트를 조작할 수 없다. 이때 사용자의 조작을 기억하고 있다.
6. 브라우저가 JavaScript FrameWork를 실행한다.
7. JS까지 성공적으로 컴파일되었기 때문에, 아까 기억하고 있던 사용자의 조작이 실행되고 웹 페이지는 상호작용이 가능해진다.
SSR의 장점
- 빠른 초기 로딩 속도: SSR은 서버 측에서 데이터를 받아와 렌더링하기 때문에 초기 로딩 속도가 빠르다.
- SEO에 유리함: SSR에서는 초기 HTML 파일에 콘텐츠가 포함되어 있기 때문에 검색 엔진이 페이지를 크롤링할 때 콘텐츠를 인식할 수 있다.
- 높은 보안성: SSR에서는 서버 측에서 데이터를 처리하기 때문에 보안성이 높다. 클라이언트 측에서 데이터를 조작하거나 해킹 등의 공격이 어려워진다.
- 서버 부하를 분산 가능: SSR에서는 서버 측에서 데이터를 처리하기 때문에 서버 부하가 분산될 수 있다.
SSR의 단점
- 느린 페이지 이동 속도: SSR은 페이지 이동할 때마다 서버에서 데이터를 받아와 렌더링해야 하기 때문에 페이지 이동 속도가 느리다.
- 낮은 사용자 경험: SSR에서는 페이지 이동 속도가 느리기 때문에 사용자 경험이 낮을 수 있다.
- 어려운 캐싱: SSR에서는 캐시를 사용하는 것이 어려울 수 있다. 매번 새로운 데이터를 불러와야 하기 때문에 서버 부하가 증가할 수 있다.
- 낮은 개발 난이도: SSR은 일반적인 웹 개발 방식과 유사하기 때문에 개발 난이도가 낮다. 하지만, 대규모의 복잡한 웹 애플리케이션에서는 추가적인 복잡성이 요구될 수 있다.
사용 권장 예시
CSR을 사용 권장
- 네트워크가 빠를 때
- 서버의 성능이 좋지 않을 때
- 사용자에게 보여줘야 하는 데이터의 양이 많을 때(ex. 대규모의 복잡한 웹 애플리케이션)
- 메인 스크립트가 가벼울 때
- SEO(Search engine Optimization) 검색 엔진 최적화가 필요 없을 때
- 웹 어플리케이션에 사용자와 상호 작용 할 것들이 많을 때
(아예 렌더링이 되지 않아 사용자의 행동을 막는것이 경험에 오히려 유리하다)
SSR을 사용 권장
- 네트워크가 느릴 때 (CSR은 한번에 모든 것을 불러오지만 SSR는 각 페이지마다 나누어 불러오기 때문이다)
- SEO(Search engine Optimization) 검색 엔진 최적화가 필요할 때
- 최초 로딩이 빨라야 하는 사이트를 개발할 때
- 메인 스크립트가 크고 로딩이 엄청 느릴 때
(CSR은 메인스크립트가 로딩이 끝나면 API로 데이터 요청을 보내지만, SSR은 한번의 요청에 아예 렌더가 가능한 페이지가 돌아온다) - 웹 사이트가 상호작용이 별로 없을 때
CSR과 SSR 비교 정리
| CSR | SSR | |
| 초기 로딩 속도 | 느림 | 빠름 |
| 페이지 이동 속도 | 빠름 | 느림 |
| SEO | 불리함 | 유리함 |
| 보안성 | 낮음 | 높음 |
| 사용자 경험 | 높음 | 낮음 |
| 서버 부하 | 낮음 | 높음 |
| 개발 난이도 | 높음(복잡한 SPA 구현) | 낮음(일반적인 웹 개발) |
| 캐싱 | 가능 | 불가능 |
출처
https://www.startupcode.kr/company/blog/archives/12
https://hahahoho5915.tistory.com/52
https://off-dngw.github.io/posts/SSR-CSR/
'IT 지식 > Web' 카테고리의 다른 글
| Cookie의 MaxAge, Expires 옵션 (0) | 2023.04.04 |
|---|---|
| 브라우저 저장소(local storage, session storage, cookie) (0) | 2023.03.31 |
| [Web] HTTP와 HTTP 메시지 구조 (0) | 2023.03.30 |
| Restful API (0) | 2023.03.27 |
| [Web] 웹페이지가 브라우저에 렌더링되는 과정 (0) | 2023.03.27 |
