브라우저 렌더링이란?
브라우저 렌더링 방식인 CSR과 SSR에 대해 본격적으로 알아보기 전에, 브라우저 렌더링이 뭔지 살펴보자.
브라우저 렌더링 : 브라우저가 서버로부터 요청해 받은 내용을 화면에 표시해주는 작업.
- 브라우저 : 서버로부터 전달받은 문서를 브라우저 엔진이 해석해 브라우저 화면을 그림 ⬅️ 서버 : HTML, CSS, JavaScript 문서 전달
CSR : Client Side Rendering
렌더링 주체가 클라이언트(브라우저)로, 클라이언트인 브라우저가 서버에서 받은 데이터로 화면을 그리는 것.
- 서버는 요청을 받으면 클라이언트에 HTML과 JavaSript를 보내주고, 클라이언트는 그것을 받아 렌더링함
CSR 렌더링 과정
- 사용자가 웹사이트에 요청 보냄
- CDN : JavaScript에 대한 링크를 담은 HTML 파일을 클라이언트에 전송
CND: 유저의 요청에 "물리적"으로 가까운 서버에서 요청에 응답하는 방식 - Client : 브라우저가 HTML, JS 파일을 다운받음
유저는 아무 것도 볼 수 없음 - Client : 다운로드된 JavaScript가 실행되며, 데이터를 위한 API가 호출
사용자는 placeholder는 볼 수 있음 - Server : API 요청에 대한 응답
- Client : API로부터 받아온 Data를 placeholder 자리에 넣어줌
페이지는 상호작용이 가능해짐
요약
클라이언트가 서버에게 웹페이지를 요청 -> 브라우저가 JS 다운 -> 브라우저가 리액트를 실행 -> 페이지 렌더링 : Viewable + Interactable
서버에서 처리 없이 클라이언트로 보내주기 때문에 JavaScript가 모두 다운로드 되고 실행이 끝나기 전까지 사용자는 볼 수 있는 것이 없음
장점
1) 빠른 인터렉션 구현 가능 (로딩되면, 빠른 UX 제공)
- 새로고침이 발생하지 않아 사용자가 네이티브 앱과 비슷한 경험할 수 있음.
2) 서버의 부하가 적음
단점
1) 첫 페이지 로딩 속도가 SSR 비해 느림 : TTV ⬆️
- 첫 요청 시, 전체 페이지에 대한 모든 문서를 다운 받기 때문에 로딩 속도가 느림
2) SEO에 대한 추가 보완 작업이 필요함
- 포털 사이트 검색엔진 크롤러가 웹사이트에 대한 데이터를 제대로 수집하지 못하는 경우가 발생할 수 있음.
- 별도의 보완 작업 : ex. sitemap 문서 작성 등
3) 보완에 취약
4) 자바스크립트 활성화가 필수
CSR 사용
- 네트워크가 빠른 경우 (한 번에 모든 스크립트를 불러오는 방식)
- 서버 성능이 좋지 않은 경우
- 메인 스크립트가 가벼운 경우
- SEO(검색 엔진 최적화)에 대해 상관이 없는 경우
- 웹 어플리케이션이 사용자와 상호작용할 것들이 많은 경우
아예 렌더링 되지 않아서 의도하지 않은 사용자의 행동을 막는 것이 UX 부분에서 오히려 유리할 수 있음
SSR : Server Side Rendering
렌더링의 주체가 서버로, 서버는 클라이언트 요청이 들어올 때마다 매번 새로운 화면을 만들어 클라이언트(브라우저)에 제공하는 것
SSR 렌더링 과정
- 유저가 웹사이트에 요청 보냄
- Server : "Ready to Render" = 즉시 렌더링 가능한 HTML 파일 생성
- Client : 브라우저는 전달받은 HTML 파일을 빠르게 렌더링
화면이 표시는 되지만, JavaScript가 읽히기 전이기 때문에 사이트 조작은 불가능함 - Client : 브라우저가 자바스크립트를 다운받음
- 다운받는 사이, 사용자는 콘텐츠는 볼 수 있지만 사이트 조작은 안 됨.
사용자의 조작을 기억할 순 있음 - Client : 브라우저가 자바스크립트 프레임워크 실행
- JavaScript까지 성공적으로 컴파일 되었기 때문에 기억하고 있던 사용자 조작이 실행되고 이제 웹 페이지는 상호작용이 가능해짐
요약
서버가 브라우저에 ready to be rendered HTML 응답 전송
-> 브라우저가 화면을 렌더링 : Viewable
-> 브라우저가 JS를 다운 받음
-> 브라우저가 리액트를 실행시킴 : Interactable
서버에서 미리 렌더링하여, 렌더 가능한 HTML 파일을 보내주기 때문에, JS를 다운받는 동안 사용자는 화면을 볼 수 있다.
장점
1) 첫 페이지 로딩 속도가 빠름 : TTV ⬇️
- 사용자의 요청에 따라 서버에서 페이지 내용을 렌더링하고, 그 결과인 HTML을 클라이언트(브라우저)에 전송, 즉 서버에서 미리 페이지를 렌더링하기 때문에 클라이언트가 추가적인 자바스크립트를 실행하여 DOM을 구성하거나 변경하는 작업 없이 바로 HTML 문서를 파싱하여 화면에 표시할 수 있음.
2) SEO 가능
3) 보완 우수
4) 실시간 데이터 사용
5) 사용자별 필요한 데이터 사용 가능
단점
1) 페이지 이동 속도가 느림
- 페이지 이동 시마다 서버에게 필요한 데이터를 요청하는 방식이라 속도가 느림
SSR 사용
- 네트워크가 느린 경우 (각 페이지마다 나눠서 불러오기 때문)
- SEO(검색 엔진 최적화)가 필요한 경우
- 최초 페이지의 로딩이 빨라야 하는 사이트를 개발하는 경우
- 메인 스크립트가 크고, 로딩이 매우 느린 경우
- 웹 사이트가 상호작용이 많지 않은 경우
CSR V.S. SSR의 차이
1. 웹페이지 로딩 시간
첫 페이지 로딩 시간
SSR Wins!
- CSR : HTML, CSS와 모든 스크립트들을 한 번에 불러오는 방식
- SSR : 필요한 부분의 HTML과 스크립트만 불러오는 방식 ➡️ 더 빠름
나머지 콘텐츠(첫 페이지 로딩 후, 사이트의 다른 페이지로 이동) 로딩 시간
CSR Wins!
- CSR : HTML, CSS와 모든 스크립트들을 첫 페이지 로딩에서 한번에 불러오는 방식이므로 나머지 컨텐츠 부분을 구성하는 코드를 받아왔기 때문에 비교적 빠르게 작동
- SSR : 필요한 부분의 HTML과 스크립트만 불러오는 방식이므로 나머지 컨텐츠 부분을 첫 페이지를 로딩한 과정처럼 정확하게 다시 실행하기 때문에 비교적 느리게 작동
2. SEO 대응
SEO(검색 엔진 최적화) : 웹 사이트가 organic 검색 방식을 통해 검색 엔진에서 상위에 노출될 수 있도록 최적화하는 과정
CSR 방식에서는 페이지의 주요 컨텐츠가 JavaScript에 의존하기 때문에 SEO 문제가 발생할 수 있는 반면, SSR 방식에서는 서버에서 미리 페이지를 렌더링하여 완성된 HTML을 제공하기 때문에 웹 크롤러가 페이지 내용을 쉽게 파악할 수 있기 때문에 SEO에 더 유리한 방식.
SSR Wins!
- CSR : JavaScript를 실행시켜 동적으로 컨텐츠가 생성되기 때문에, JavaScript가 실행 되어야 meatadata가 바뀌는 방식
이전 크롤러들은 JavaScript를 실행시키지 않았기에 SEO 최적화가 필수적이었음- SSR : Server Side에서 컴파일되어 클라이언트로 넘어오기 때문에 크롤러에 대응하기 용이
JavaScript를 실행시켜 동적으로 컨텐츠를 생성하는 CSR에 비해 클라이언트로 넘어오기 전에 JavaScript를 서버 쪽에서 컴파일되기 때문에, SEO에 대응하기에 용이한 방식은 SSR 방식
3. 서버 자원 사용
CSR Wins!
- CSR : 클라이언트에서 JavaScript를 실행시켜 컨텐츠를 생성한 후, 서버로 보내기 때문에 서버 자원 사용이 적음
- SSR : 매번 서버를 통해 JavaScript 컴파일을 오청하기 때문에 서버 자원의 사용이 많음 ➡️ 서버 과부하
참고자료
https://www.startupcode.kr/company/blog/archives/12
https://velog.io/@hyungjin_han/Computer-Science-SSR-VS-CSR?ref=codenary
