서버로부터 HTML 파일을 받아 브라우저에 뿌려주는 과정 ( = 실시간으로 웹사이트가 뿌려지는 과정)
CSR(Client Side Rendering)
●렌더링이 클라이언트 쪽에서 발생
●서버는 요청을 받으면 클라이언트에 html과 JavScript를 보내주고 클라이언트는 그것을 받아 렌더링을 시작
CSR의 단계 1. User가 WebSite요청을 보냄. 2. *CDN이 html파일과 Js로 접근할 수 있는 링크를 클라이언트로 보낸다. 3. 클라이언트는 html과 Js를 다운로드 받는다.(SSR과 달리 유저는 아무것도 볼 수 없다.) 4. 다운이 완료된 JS가 실행되고 데이터를 위한 API가 호출된다. (이때 유저는 placeholder를 보게 된다.) 5. 서버가 API로부터 요청에 응답한다. 6. API로 부터 받아온 data를 placeholder 자리에 넣어준다. 이제 페이지는 상호작용이 가능해진다.
CDN : aws의 cloudflare를 생각하면 됨. 엔드 유저의 요청에 '물리적'으로 가까운 서버에서 요청에 응답하는 방식
CSR 사용하는 경우
● 네트워크가 빠를 때 ● 서버의 성능이 좋지 않을 때 ● 사요자에게 보여줘야하는 데이터의 양이 많을 때 (로팅창 띄울 수 있는 장점 존재) ● 메인 Script가 가벼울 때 ● SEO에 상관 없을 때 ● 웹 어플리케이션에 사용자와 상호작용할 것들이 많을 때(아예 렌더링 되지 않아 사용자의 행동을 막는 것이 오히려 유리)
SSR(Server Side Rendering)
●서버로부터 완전하게 만들어진 html파일을 받아와 페이지 전체를 렌더링 하는 방식
SSR의 단계
1. User가 Website 요청을 보낸다. 2. Server는 즉시 렌더링 가능한 html파일을 만든다. (리소스를 체크, 컴파일 후 완성된 html 컨턴츠로 만든다.) 3. 클라이언트에 전달되는 순간 이미 렌더링 준비가 되어있기 때문에 html은 즉시 렌더링이 된다. 그러나 사이트 자체는 조작 불가능하다. (JavaScript가 읽히기 전이기 때문에) 4. 클라이언트가 JavaScript를 다운 받는다. 5. 다운 받아지고 있는 사이에 유저는 컨텐츠는 볼 수 있지만 사이트를 조작할 수는 없다. 6. 브라우저가 JavaScript 프레임 워크를 실행한다. 7. JavaScript까지 성공적으로 컴파일 되었기 때문에 기억하고 있던 사용자 조작이 실행되고 이제 웹 페이지는 상호작용이 가능해진다.
SSR 사용 경우
● 네트워크가 느릴 때 (CSR은 한번에 모든것을 불러오지만 SSR은 각 페이지마다 불러오기 때문) ● SEO(검색엔진 최정화)가 필요할 때 ● 최초 로딩이 빨라야하는 사이트를 개발할 때 ● 메인 Script가 크고 로딩이 매우 느릴 때 (CSR은 메인 스크립트가 로딩이 끝나면 API로 데이터 요청을 보냄. 그러나 SSR은 한번의 요청에 아예 렌더가 가능한 페이지가 돌아옴) ● 웹 사이트가 상호작용이 별로 없을 때
SSR과 CSR의 차이점
※ 크롤러 : 검색 엔진이 웹 사이트를 읽을 때 사용하는 자동화된 로봇
CSR
SSR
웹 페이지 로딩 시간
첫 페이지
모든 스크립트들 한 번에 불러옴
필요한 부분의 HTML과 스크립트만 불러옴으로 더 빠름
나머지 페이지
이미 첫 페이지 로딩때 나머지 부분 구성하는 코드를 받아옴으로 더 빠름
첫 페이지를 로딩한 과정 정확하게 다시 실행해 느림
SEO 대응
JS를 실행시켜 동적으로 콘텐츠가 생선되기 때문에 JS가 실행 되어야 meatadata가 바뀜 (이전 크롤러들을 JS를 실행시키지 않았기에 SEO 최적화가 필수였음. 구글이 트렌드를 바꿈)
