Notice
Recent Posts
Recent Comments
Link
«   2024/11   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Tags
more
Archives
Today
Total
관리 메뉴

박나겸

[WEB] 렌더링 본문

cs 스터디

[WEB] 렌더링

itsmekyum 2024. 1. 30. 08:06

렌더링은  웹 페이지 접속 시 페이지를 화면에 그려주는 것 이라고 이전 게시물에 설명을 해놨다.

 

렌더링 종류

렌더링은 서버로부터 받아와 전체페이지를 렌더링하는 서버사이드 렌더링(SSR)과 클라이언트에서 필요한 부분만 렌더링하는 클라이언트 사이트 렌더링(CSR)로 구성된다.

 

SSR(Server Side Rendering)

- 서버 영역에서 렌더링 과정을 수행하는 것

- 사용자가 웹 페이지에 접속하면 서버로 해당 페이지에 대한 요청이 진행 되고 서버에서는 필요한 html, css,js 를 이용해서 페이지를 서버에서 렌더링한 다음 클라이언트로 보내주는 것이다. 즉, 서버에서 완전한 html 페이지를 직접 만들어서 제공한다. 

-  동작 원리

  1. 사용자가 웹 페이지를 방문하면, 서버는 리소스를 확인하고 페이지 내에 있는 서버측 스크립트를 실행 후 HTML 컨텐츠를 컴파일한다.
  2. 컴파일된 HTML을 브라우저로 전송.
  3. 브라우저는 HTML을 다운로드하고 사용자가 페이지를 볼 수 있도록 한다.
  4. 브라우저는 자바스크립트를 다운로드하고 실행하면서 페이지를 interactive하게 만든다.
  5. 사용자가 페이지를 이동할 경우, 위 동작을 반복

- 장점 

  • 초기 페이지 로딩 속도가 빠름
  •  seo (검색 엔진 최적화) 유리 : 서버에서 완성된 html 파일을 보내주기 때문에

- 단점

  •  화면 깜빡임 현상 발생 : 화면에 변화가 생길 때 마다 서버에서 파일을 보내주고 다시 화면을 구성하기 떄문에 
  •  서버 과부화 발생 : 화면 전환이 있을 때 마다 서버에 요청해서 받아오기 떄문에

CSR(Client Side Rendering)

- 클라이언트 영역에서 렌더링을 수행하는 방식

- 사용자가 웹브라우저를 통해서 웹사이트에 방문하였을 때 웹사이트에서 제공하는 웹페이지에 대한 html, css,js 와 같은 리소스들을 클라이언트 단에서 다운로드 받고 클라이언트 사이드에서 페이지 전환을 처리하여 보여주는 방식

- 동작 원리

  1. 유저가 웹 페이지를 방문하면, 브라우저는 빈 HTML 파일을 다운로드
  2.  서버로 부터 HTML 파일을 받아온 다음, 웹 사이트 화면을 구성하는데 필요한 추가적인 데이터들을 서버에서 다시 다운로드  
  3. 사용자가 페이지를 이동할 경우, 서버에 추가 요청하지 않고 이미 다운받은 JS를 이용하여 랜더링 한다.

- 장점

  • 초기 페이지 로딩 후에는 페이지 이동이 빠름
  • 페이지간 이동시 깜빡임이 존재하지 않아 네이티브 앱과 비슷한 경험가능 : 새로고침이 없어서
  • 서버의 부하가 적음
  • TTV와 TTI 의 공백 기간이 짧음 : TTV - 사용자가 화면을 보는 시점 / TTI - 사용자가 실제로 서비스를 이용하는 시점

- 단점

  • SEO 친화적이지 않음 : 초기 화면을 빈 페이지로 보여주기 때문에
  • 초기 페이지 로딩속도가 느리다 
  • 클라이언트측에서 보안에 좋다.

- SSR과 CSR의 원리

page1이 page2로 변화한다고 가정해보자.
위쪽의 파란색버튼 부분은 그대로이고, 아래의 초록색버튼만이 변화한 부분이다.

SSR의 경우에는 모든 페이지를 통째로 렌더링을 해야한다. 이미있던 파란색버튼도 다 만들어서 서버에서 클라이언트로 보내줘야 한다. ➡️ 시간도 오래걸리고 만들필요가 없는 것을 계속 만들어야해서 비효율적이다
CSR은 위쪽의 파란색버튼은 keep해두고 변화가 있는 초록색버튼만을 서버의 api에서 json방식으로 가져와서 렌더링해준다. ➡️ 더 효율적이고 빠르다

 

SSG(Static Site Generation)

- 빌드 타임에 js를 변환하며 미리 만들어놔서 요청이 들어오면 이미 완성된 html을 반환

- 동작원리

  1. SSR처럼 서버로부터 HTML을 받아오며, 빌드과정에서 HTML 파일을 생성한다.
  2. 화면을 서버에서 미리 만들어서 전송해주는 방식.

- 장점

  • TTV(페이지 로딩 속도) 빠름
  • SEO 친화적
  • 보안이 좋다

- 단점

  • 정적 파일로 제공이 되기에 사용자별 데이터 제공이 어려움

ISR (Incremental Static Regeneration)

- 빌드 시점에 페이지를 렌더링 한 후, 설정한 시간마다 페이지를 새로 렌더링 해줌

- SSG의 하위 개념이라고 생각하면 됨

 - 동작원리

  1. 페이지를 처음 방문하면 데이터는 SSG 방식처럼 빌드과정에서 받아온 데이터입니다.
  2. ISR은 revalidate 시간이 지나면 해당 페이지만 서버사이드에서 다시 빌드하게 된다. API를 백그라운드에서 접속하기 때문에 클라이언트 쪽에 보이는 데이터는 변함이 없습니다.
  3. revalidate 시간 후에 새로고침을 누르면 ISR이 페이지를 재 빌딩 하는 시간 후에 렌더링 되기 때문에 실제 시간보다 1초 늦게 보입니다. 여기서 1초라는 뜻은 페이지 재 빌딩이 1초 걸린다는 뜻입니다.

장점

  • 페이지 로딩속도(TTV)가 빠름
  • SEO 친화적
  • 보안이 좋음
  • 데이터가 주기적으로 변경됨

단점

  • 실시간 데이터가 아니다
  • 유저별 데이터 제공은 힘들다

그럼 언제 어떤 방식을 사용해야 할까?