SSR
서버사이드 렌더링
말그대로 서버쪽에서 렌더링을 하여 화면을 보여주는 방식이다. 즉 서버로부터 완전하게 만든 HTML파일을 받아와 화면을 그리기 때문에, 첫 화면 로딩속도가 빠르다.
과정을 설명해보자면
1. 사용자의 요청: 사용자의 웹 브라우저가 URL을 통해 특정 페이지 요청
2. 서버처리: 웹서버가 이 요청을 받고, 필요한 DB조회나 API호출을 통해 요청 받은 페이지의 데이터를 준비
3. HTML 렌더링: 서버는 준비된 데이터와 템플릿을 결합하여 최종적인 HTML문서를 생성 -> 이HTML문서에는 사용자가 요청한 페이지의 컨텐츠가 모두 포함됨. 타임리프를 사용하여서
4. 클라이언트 전송: 생성된 HTML문서가 사용자의 브라우저로 전송, 전송된 HTML문서는 브라우저에 의해 해석되며, 사용자는 내용을 볼 수 있음
5. 브라우저 렌더링: 사용자 브라우저는 서버로 부터 받은 HTML,CSS,JavaScript 자료를 처리해서 화면에 보여준다. 서버에서 미리 렌더링 된 HTML이기 때문에 사용자는 데이터 로딩없이 즉각적으로 웹페이지를 볼 수 있다.
6. 클라이언트 사이드 자바 스크립트: 초기 로딩후 사용자 상호작용을 위해 클라이언트 사이드 자바스크립트가 활성화 -> 추가적인 데이터 요청 발생할 수 있고, AJAX와 같은 비동기 통신으로 처리됨
예를들어 내가 HTML파일을 전송한건 어차피 결국 동적으로 생성되었지만 정적으로 user와 커뮤니케이션이 안됨, 왜? 뭐 사진에 마우스올리면 사진이 살짝 흐릿해지면서 강조되는 이런기능 자체는 클라이언트에서 해야하니까 이러한 내용의 JS파일을 다운받아서 JS프레임워크(React등 )가 실행시켜줘야함.
그러면 이때무터 사용자와 상호작용이 가능함
즉 짧게 요약하면
서버가 렌더링된 HTML 파일을 보내고 브라우저가 받음 => 브라우저가 페이지를 화면에 띄워주고 JS 파일을 다운받는다(유저와 상호작용을 위해) => 브라우저가 React(프레임워크)를 실행한다 => 이제 페이지가 모두 작동된다!
장점은 첫페이지 로딩속도가 빠르지만, 초기 로딩 이후 페이지 이동시 속도가 CSR에 비해 느리다, Time To View는 빠른데, Time To Interact와의 공백시간이 있다. 왜냐하면 당연히, JS파일 다운받고 React실행해야하니까.
CSR
클라이언트 사이드 렌더링
말그대로 클라이언트가 렌더링을 맡아서 한다. 여기서 클라이언트는 브라우저를 말한다.
1. 사용자가 웹사이트에 요청을 보낸다.
2. 브라우저가 HTML,JS파일을 다운받고 그동안 화면에는 아무것도 보이지 않는다.
3. 브라우저가 JS파일을 읽는다. 이때도 화면 안보인다.
4. 다운이 완료된 JS가 실행되고 여기서 필요한 Data를 위한 API가 호출된다.
6. 서버가 API요청에 응답한다.
7. API로 부터 받아온 dATA를 Placeholder자리에 넣어준다. 이제 페이지는 상호작용이 가능하다.
한눈에 봐도 SSR보다 화면이 띄워지는 타이밍이늦다. 브라우저가 HTMl파일 JS파일을 다 읽고 프레임워크까지 다해야지 페이지가 보여지고, 상호작용이 가능하기 때문이다.
클라이언트 사이드 렌더링은 당연히 초기화면은 서버사이드 렌더링보다 느리지만,
서버사이드 렌더링에서 만약에 상품를 추가한다고 치면, 다시 상품추가 data를 서버에 보내고, 다시 data를 DB에 저장하던 처리를한후에, HTML을 다시 만들어서 클라이언트로 내보내줘야한다.
그러면 페이지도 새로 렌더링해야하고, 새로고침이 발생한다. 깜빡임이 발생한다.
그러나, 클라이언트 사이드 렌더링은 일단 한번 초기 방식으로 페이지 전체를 로딩하고나면, 필요한 데이터만 바꿔서 화면을 다시 그려준다. 이러면, 페이지를 전체적으로 새로 렌더링 할 필요도 없고 깜빡임도 발생하지 않으므로 우수한 사용자 경험을 제공한다.
장점
새로고침이 발생하지 않아 사용자 경험에 도움을 준다.
초기 로딩 이후 빠른 웹사이트 렌더링이 가능
필요한, 변경된 데이터만 받아오므로 트래픽 감소
단점
초기로딩느림
