[FE] 기본상식

bunny.log·2022년 6월 4일
0

클라이언트 렌더링(CSR)

  • API서버는 단지 JSON파일만 보내주고 웹 서버는 HTML, CSS, Javascript를 단순히 서빙(건네주는)하는 역할을 합니다.
  • HTML을 그리는 역할은 자바스크립트를 통해 브라우저(클라이언트)에서 수행 합니다.
  • HTML, CSS를 전부 브라우저에서 렌더링하기 때문에 웹 서버는 큰 부담이 없습니다.
  • 트래픽감소/새로고침이 발생하지 않아 네이트브앱과 비슷한 경험을 할 수 있습니다.

서버사이드 렌더링(SSR)

  • 웹 서버에서 SSR에서는, 애플리케이션의 모든 것을 JavaScript로 그리는 것이 아니라, 미리 서버에서 정적인 HTML, CSS, Javascript 를 미리 한 번 실행시킨 후 브라우저에 나타나는 HTML 형태 그대로를 만들어 제공!
  • 페이지를 로딩할 때 마다 새로고침이 일어나며 서버로부터 리소스를 전달받아 해석하고 화면에 렌더링하는 방식
  • 렌더링을 서버에서 하므로 불필요한 트래픽의 낭비가 생김

하이드레이션(Hydration)

  • 서버 측에서 렌더링된 HTML에 대해 JavaScript를 클라이언트에서 연결하는 작업(HTML에 연결된 JavaScript를 실행하여 이벤트 리스너 등 인터랙티브한 조작을 할 수 있게 하는 작업)
  • HTML을 구문 분석하고, 이벤트 리스너를 DOM에 연결하며 스토어에서 데이터를 가져옵니다. 따라서 사이트는 완전히 작동하는 React 앱이 됩니다.

하이드레이션를 통해, SPA의 문제점이었던 초기 렌더링을 빠르게 할 수 있습니다.

(CSR에서는 JavaScript가 실행되어 처음으로 HTML이 생성되므로, 크롤러가 다운로드하는 HTML에 메타 정보가 포함되어 있지 않은 경우가 있어 SEO에 불리하다고 합니다)

SSR과 CSR 흐름

  • 기본 화면만을 받아올 때는 클라이언트(브라우저) <-> 프론트엔드 서버
  • SSR을 할 때는 클라이언트(브라우저) <-> 프론트엔드 서버 <-> 백엔드 서버 <-> DB
  • API 요청을 할 때는 클라이언트(브라우저) <-> 백엔드 서버 <-> DB

이런 식으로 갑니다.

프론트 서버가 웹 서버이고 백엔드 서버는 API 서버에 더 가깝습니다.

토큰(token)

  • 인증받은 사용자에게 토큰을 발급
  • 서버에 요청할 때 헤더에 토큰을 담아 유효성검사(서버는 토큰이 유효한지 확인)
    장점)
    사용자 인증정보를 서버나 세션스토리지에 유지하지 않고 클라이언트 측에서 들어오는 요청만으로 작업하여 세션인증에 비해 서버 운영 효율이 더 좋다.

웹팩(webpack)

  • 웹팩이란 최신프론트엔드에서 가장 많이 사용되는 모듈번들러로 웹 애플리케이션을 구성하는 자원(HTML IMAGE)등의 연관관계를 파악한 다음 모듈로 보고 이를 조합해서 하나의 결과로 만드는 도구이다.

  • 네트워크 요청이 많지 않기 때문에 페이지로딩속도가 확연이 빨라진다(60%단축)

  • 웹 애플리케이션을 구성하는 몇십, 몇백개의 자원(HTML, CSS, Javascript)등을 하나의 파일로 병합 및 압축해주는 동작

  • 웹 애플리케이션의 빠른 로딩속도와 높은 성능

  • 웹팩은 초기페이지의 로딩속도를 높이기 위해 나중에 필요한 자원들을 요청하며 코드스플리팅이나 레이지로딩 등을 사용해 필요한 타이밍에 모듈을 로딩(코드스플리팅, lazyloading)

  • 브라우저별 HTTP요청 숫자의 제약에 강점

  • Entry : 빌드할 대상파일, 웹팩에서 웹자원을 변환하기 위해 필요한 최초 진입점이자 자바스크립트 파일경로

    Output : 빌드 후 결과물 경로, 파일경로와 파일이름까지 지정가능
    Module : 엔트리에서 아웃풋으로 변환 중간에서 개입하는 것이 모듈
    Loader : 웹팩으로 변환할 때 중간에 자바스크립트파일이 아닌 자원을 변환할 수 있도록 도움

브라우저 렌더링 과정

1-주소창에 구글 입력 .
2-구글 서버로 찾아간다.
3-*DNS가 연결해줄 곳을 찾음
4-서버에서 HTML 파일을 클라이언트로 보냄.
5-HTML 파일 파싱 및 DOM Tree 생성
6-link 태그를 만나 css 파싱 및 CSSOM 트리 생성
7-DOM , CSSOM 합쳐 Render Tree 생성
(8. JavaScript를 만나면? HTML파서는 JS 코드를 실행하기 위해 파싱 중단
8-JS 엔진실행 및 JS코드 파싱)

1.HTML 파일과 CSS 파일을 파싱해서 각각 Tree를 만든다. (Parsing)

  • Parsing
    브라우저가 페이지를 렌더링하려면 가장 먼저 받아온 HTML 파일을 해석해야한다.
    Parsing 단계는 HTML 파일을 해석하여 DOM(Document Object Model) Tree를 구성하는 단계이다.
    파싱 중 HTML에 CSS가 포함되어 있다면 CSSOM(CSS Object Model) Tree 구성 작업도 함께 진행한다.

    다운받은 HTML , CSS => Object Model로 만듦.
    HTML => DOM , CSS => CSSOM

  • Style
    Style 단계에서는 Parsing 단계에서 생성된 DOM Tree와 CSSOM Tree를 매칭시켜서 Render Tree를 구성한다.
    Render Tree는 실제로 화면에 그려질 Tree이다.

  • Layout
    Layout 단계에서는 Render Tree를 화면에 어떻게 배치해야 할 것인지 노드의 정확한 위치와 크기를 계산한다.
    루트부터 노드를 순회하면서 노드의 정확한 크기와 위치를 계산하고 Render Tree에 반영한다.
    만약 크기 값을 %로 지정하였다면, Layout 단계에서 % 값을 계산해서 픽셀 단위로 변환한다.
    예를 들면 Render Tree를 구성할때 visibility: hidden은 요소가 공간을 차지하고,
    보이지만 않기 때문에 Render Tree에 포함이 되지만, display: none 의 경우 Render Tree에서 제외된다.

2.두 Tree를 결합하여 Rendering Tree를 만든다. (Style)
3.Rendering Tree에서 각 노드의 위치와 크기를 계산한다. (Layout)
4.계산된 값을 이용해 각 노드를 화면상의 실제 픽셀로 변환하고, 레이어를 만든다. (Paint)
5.레이어를 합성하여 실제 화면에 나타낸다. (Composite)

<브라우저의 기본 구조>

사용자 인터페이스 주소 표시줄, 이전/다음 버튼, 북마크 메뉴 등. 요청한 페이지를 보여주는 창을 제외한 나머지 모든 부분이다.

브라우저 엔진 사용자 인터페이스와 렌더링 엔진 사이의 동작을 제어.

렌더링 엔진 요청한 콘텐츠를 표시. 예를 들어 HTML을 요청하면 HTML과 CSS를 파싱하여 화면에 표시함.

통신 HTTP 요청과 같은 네트워크 호출에 사용됨. 이것은 플랫폼 독립적인 인터페이스이고 각 플랫폼 하부에서 실행됨.

UI 백엔드 콤보 박스와 창 같은 기본적인 장치를 그림. 플랫폼에서 명시하지 않은 일반적인 인터페이스로서, OS 사용자 인터페이스 체계를 사용.

자바스크립트 해석기 자바스크립트 코드를 해석하고 실행.

자료 저장소 이 부분은 자료를 저장하는 계층이다. 쿠키를 저장하는 것과 같이 모든 종류의 자원을 하드 디스크에 저장할 필요가 있다. HTML5 명세에는 브라우저가 지원하는 '웹 데이터 베이스'가 정의되어 있다.

렌더링 엔진

렌더링 엔진의 역할은 요청 받은 내용을 브라우저 화면에 표시하는 일이다.
렌더링 엔진은 HTML 및 XML 문서와 이미지를 표시할 수 있다. 물론 플러그인이나 브라우저 확장 기능을
이용해 PDF와 같은 다른 유형도 표시할 수 있다. 그러나 이 장에서는 HTML과 이미지를 CSS로 표시하는
주된 사용 패턴에 초점을 맞출 것이다.

렌더링 엔진들

파이어폭스 : 게코엔진 (Gecko)
사파리, 크롬 : 웹킷 (Webkit)
profile
나를 위한 경험기록

0개의 댓글