TIL: 서버사이드 렌더링

Snoop So·2023년 5월 23일
0
  • 캐싱 정책

  • 라우터

  • 검색 엔진 최적화

  • CSR 클라이언트 사이드 렌더링

  • .html 파일이었음

  • 페이지 단위.

  • 라우팅 분기처리를 함

  • write. url 분석함

  • 일치하는 html을 만들어서 줌

  • url html을 만든다. 데이터베이스 조회. 가져온 것을 바탕으로 templating을 함

  • 브라우저가 그리는 것도 렌더링, 서버에서는 템플릿 작업이라고 함.

  • html에 템플릿 문법이 막 있는거임. 백엔드 막내가 퍼블리셔와 협업함. 여기 안에 js 를 넣을 수 있음

  • Ajax라는 것이 나와서 오래걸리기 시작함

  • javascript하려고 했더니 XML이 크니까 json으로 바뀌었음. (더글라스 프콜라스..?)

  • 템플릿엔진이 많이 나옴. 머스타치, 핸들바... (클라이언트 렌더링의 시작)

  • 첫페이지를 메일 서비스를 만든다고 침. 클라이언트 사이드 렌더링으로 만들기.

  • url을 입력함.

  • static 파일은 로직이 필요없어서 웹서버에서 처리한다. 거점들이 있음.. 지역 서버. 캐시해 놓은 파일들이 있다. (와슨, CDN, 캐시 서버)

  • script 파일을 웹서버에서 왔어

  • javascript 해석 전까지는 리액트는 아직 오지도 않았음. 그래서 아무것도 안보임.

클라이언트사이드 렌더링

브라우저에서 URL 요청: 브라우저는 입력된 URL로 HTTP 요청을 보냅니다.

서버에서 응답: 해당 URL을 제공하는 서버가 요청을 받으면 HTML, CSS, JavaScript 등의 정적 파일들을 클라이언트로 보냅니다. 클라이언트 사이드 렌더링에서는 서버는 보통 아주 간단한 HTML과 필요한 JavaScript, CSS 파일을 보냅니다.

브라우저에서 HTML 파싱: 브라우저는 받은 HTML을 파싱해서 DOM (Document Object Model) 트리를 생성합니다.

브라우저에서 JavaScript 로딩: HTML 내에 포함된 JavaScript 스크립트를 로딩하고 실행합니다.

JavaScript 프레임워크(또는 라이브러리) 초기화: 로딩된 JavaScript는 대부분 싱글 페이지 어플리케이션(SPA)의 구조를 관리하는 프레임워크(예: React, Angular, Vue.js 등) 또는 라이브러리의 코드입니다. 이 코드가 실행되면서 해당 프레임워크 또는 라이브러리가 초기화되고 작동하기 시작합니다.

JavaScript에서 DOM 생성 및 업데이트: 초기화된 프레임워크 또는 라이브러리는 클라이언트에서 동적으로 HTML을 생성하고, 이를 이용해 DOM을 업데이트합니다. 이 과정에서 필요한 데이터를 서버에 요청하고 응답을 받는 AJAX 요청 등이 수행될 수 있습니다.

브라우저 렌더링: 업데이트된 DOM을 바탕으로 브라우저가 웹 페이지를 렌더링합니다.

서버사이드 렌더링

브라우저에서 URL 요청: 브라우저는 입력된 URL로 HTTP 요청을 보냅니다.

서버에서 요청 처리: 해당 URL을 제공하는 서버가 요청을 받으면 요청에 대한 응답을 처리하기 시작합니다. 이 때, 요청된 페이지에 필요한 모든 HTML을 미리 생성하게 됩니다. 이 과정에서 필요한 데이터를 DB나 다른 서버에서 가져와 HTML에 포함시킬 수도 있습니다. 이렇게 모든 HTML이 생성된 후에, HTML 외에도 필요한 CSS, JavaScript 등의 파일과 함께 클라이언트에게 전송됩니다.

브라우저에서 HTML 파싱: 브라우저는 받은 HTML을 파싱해서 DOM (Document Object Model) 트리를 생성합니다. 이 때, 이미 모든 내용이 HTML에 포함되어 있으므로, 웹페이지의 기본 레이아웃과 내용이 바로 사용자에게 보여집니다.

브라우저에서 CSS 파싱 및 렌더 트리 구성: 브라우저는 받은 CSS를 파싱하고, 이를 이용해 렌더 트리를 구성합니다.

브라우저에서 JavaScript 로딩 및 실행: 서버에서 받은 JavaScript 파일을 로딩하고 실행합니다. JavaScript는 보통 페이지의 동적인 행동을 제어하기 위해 사용됩니다.

브라우저 렌더링: 최종적으로 브라우저는 렌더 트리를 바탕으로 화면에 웹 페이지를 그립니다.

장단점

  • 서버사이드렌더링은 서버에 왕복하는 게 없어져서 속도가 빠름

  • 근데 단점은 첫 로딩이 느리다!

  • 그래서 렌더링된 결과를 미리 서버에 보내고 그 다음에 바로 화면에 뿅 보여줌.

  • 나중에 필요한 이벤트만 하이드레이션으로 뿅하고 줌.

  • 그래서 프론트 서버에서 이걸 처리함 그래서 도커도 띄워야 하고,.. 이걸 백엔드가 함

  • 라우팅이라는 것은 인덱스부터하는 것. 근데 서버에서도 해야해서 문제가 생김. 그래서 힘듦 복잡하고

  • 그러다보니 이걸 쉽게 해주는 것이 next.js이다.

  • 이걸로 Fecth 요청을 클라이언트가 안하는 것까지 감.

  • 이제는 다 서버 컴포넌트에서 fetch하게 만들고 있음...

  • 짜는 것은 리액트로 짜는데 그건 서버에서 실행하는 리액트 컴포넌트

  • 블로그 페이지 같은 정적인 데이터만 다루는 페이지들은 static site generation (SSG) 를 사용함

  • 동적 렌더링이 필요 없음. 빌드 타임에 html을 만들어서 주면 되잖아. 이걸 React 로 짤 수 있음

  • 블로그를 만들었어. 블로그 페이지 요청해봤자 바뀌는게 없음. 빌드된 결과를 만들어놓음

  • 요청하면 바로 보여줌. 이런 도구들이 있음

  • 이걸 해주는 것이 리액트 기반의 개츠비. Next.js도 그렇게 됨

  • 쪼끔 동적인거가 있으면?! incremental static regeneration (ISG) 이라는게 또 나왔음 ㅋㅋㅋㅋ

  • 처음 요청만 하고 나머지 캐시하면 되잖아? 이럴때 씀...

  • 요청을 하고 캐시해서 쓰자가 ISG

0개의 댓글