웹페이지 랜더링 ・ Restful API

 

📌 웹페이지가 브라우저에 랜더링되는 과정

 

 

HTML 파싱 - DOM 트리 구축 - CSS 파싱 - Render 트리 구축 - 레이아웃 - 페인트 - 반응성 및 상호작용

 

 

 

1. HTML 파싱

 

• 브라우저가 html 파일을 랜더링 하는 경우는 언제일까?

브라우저에 사이트 주소를 입력하게 되면, 주소에 있는 서버가 약속되어 있는 html 파일을 브라우저로 전송하게 된다.

이때, html 코드는 8비트의 데이터 형태로 전송된다.(=바이트 스트림) 

 

바이트를 문자로 변환하고 가지고 있는 토큰과 비교를 해서 해당 문자가 html 코드인지 확인한다.(토큰화 과정) 토큰은 브라우저에 저장되어 있는 html의 시작 혹은 종료 태그 그리고 속성과 속성 값 등 약속된 여러가지 값들을 의미한다. 

 

 

 

2. DOM 트리 구축

 

위 토큰화 과정을 통해 노드가 생성된다. 노드는 DOM 트리를 이루는 거대한 구조의 한 단위를 말한다. 작은 노드들이 모여서 하나의 거대한 트리 구조를 이루게 된다. 

 

DOM 트리

 

브라우저가 DOM 트리를 생성할 때, link와 img 태그를 만나게 되면 해당 태그 안에 명시되어 있는 리소스를 다운 받는다.

script 태그를 만나게 되면 돔 생성을 중단하고 스크립트 태그 안에 들어있는 자바스크립트 코드를 해석한다.

 

 

 

3. CSS 파싱

 

브라우저로 전달받은 CSS 파일을 문자로 해석하고 가지고 있는 토큰과 비교를 해서 노드를 발행한다. 노드들이 모여서 CSS object 모델.  즉, CSSOM Tree를 생성한다. 

 

 

 

4. Render 트리 구축

 

 

DOM 트리와 CSSOM 트리를 합쳐서 렌더 트리를 생성한다. (이를 크게 레이아웃 단계라고 표현하기도 한다.) Render 트리는 화면에 표시되는 요소들과 그들의 스타일 정보를 담고 있는 트리 구조이다. 하지만, 일부 요소는 렌더링에 포함되지 않을 수 있다. 예를 들어, 스타일에 "display: none"이 지정된 요소는 렌더 트리에 포함되지 않는다. 

 

 

 

 

5. 레이아웃 (리플로우)

 

 

 

앞서 만들어진 DOM 트리와 계산된 스타일을 따라가면서 요소의 크기나 좌표와 같은 정보를 담은 레이아웃 트리를 생성하게 된다. 

 

 

 

 

 

* 리플로우 : css를 수정해서 화면에 보여지는 레이아웃이 변경된다면, 브라우저는 레이아웃을 다시 생성한다. 그리고 다음 단꼐인 페인트 단계로 넘어간다. 따라서 레이아웃이 중간에 변경되는 것은 브라우저에 부담이 되는 작업이다.

 

리플로우와 리페인트가 반드시 순차적으로 동시에 실행되지는 않는다. 레이아웃의 영향이 없는 변경이 리플로우 없이 리페인트만 실행된다.

 

 

 

 

6. 페인트 (리페인트)

 

렌더 트리를 따라서 페인트 기록이 생성이 된다. 페인트 기록에는 요소를 렌더링 하는 순서 그리고 지금까지의 정보를 바탕으로 한 페이지를 여러 개의 레이어로 나눈 다음 그 위에 텍스트, 색, 이미지, 보더, 그림자 등 모든 시각적인 부분을 그리는 작업이 진행된다.

여러가지 레이어를 스크린에 픽셀로 표현하게 되고, 나누어져 있던 레이어를 하나로 합성해서 페이지를 완성하게 되는 컴포지팅 단계가 이어진다.

---

 

** transform, opacity는 리플로우, 리페인트 생략

transform, opacity는 DOM 트리를 변경하지 않기 때문이다. 따라서 유려한 애니메이션을 구현하기 위해서 포지션 속성보다는 트랜스폼 속성을 통해서 구현하는 것이 좋다.

 

 

 

7. 반응성 및 상호작용

 

웹 페이지가 렌더링되고 화면에 표시된 후, 사용자의 상호작용에 대해 브라우저는 이벤트를 감지하고 처리한다. 사용자의 입력에 따라 웹 페이지가 변경되거나 새로운 요청이 서버로 전송되어 동적으로 업데이트될 수 있다.

 

 

 

 

 

---

 

 

 

📌 Restful API란?

 

RESTful API는 Representational State Transfer(표현 상태 전송)의 약어로, 웹 서비스의 아키텍처 스타일 중 하나이다. RESTful API는 네트워크 기반의 소프트웨어 시스템 간 통신을 위한 규칙과 제약을 제공한다.

 

1. 주요 특징:
   • 클라이언트-서버 구조: 클라이언트와 서버 간의 역할을 분리하여 확장성과 유연성을 향상시킵니다.
   • 상태 없음(Statelessness): 각 요청은 서버에 대한 충분한 정보를 포함하고 있어야 하며, 서버는 이를 기반으로 요청을 처리합니다. 세션 상태를 유지하지 않는 것이 특징입니다.
   • 캐시 지원: 응답 데이터에 캐시 헤더를 포함하여 클라이언트 측에서 캐싱을 통해 성능을 향상시킬 수 있습니다.
   • 계층화: 여러 계층으로 구성된 시스템에서 중간 계층(로드 밸런서, 캐시 등)을 통해 확장성과 보안성을 개선할 수 있습니다.
   • 일관된 인터페이스: 일관된 URI(Uniform Resource Identifier)를 통해 자원에 접근하고, HTTP 메서드를 사용하여 자원의 상태를 조작합니다.
2. 주요 HTTP 메서드:
   • GET: 서버에서 리소스를 가져올 때 사용합니다. 주로 데이터 조회에 사용됩니다.
   • POST: 서버에 새로운 리소스를 생성할 때 사용합니다. 주로 데이터 생성에 사용됩니다.
   • PUT: 서버의 리소스를 업데이트(전체 교체)할 때 사용합니다.
   • PATCH: 서버의 리소스를 업데이트(부분 변경)할 때 사용합니다.
   • DELETE: 서버의 리소스를 삭제할 때 사용합니다.

 

RESTful API에는 이외에도 OPTIONS, HEAD, TRACE, CONNECT 등의 HTTP 메서드도 사용될 수 있다. 이들은 다음과 같은 기능을 수행한다.

• OPTIONS: 서버가 제공하는 리소스에 대한 지원 가능한 메서드를 확인하기 위해 사용됩니다.
• HEAD: GET 메서드와 유사하지만, 응답 본문을 반환하지 않고 헤더 정보만을 반환합니다.
• TRACE: 요청을 반사하여 디버깅이나 테스트 목적으로 사용됩니다.
• CONNECT: 프록시를 통해 서버와의 터널을 맺기 위해 사용됩니다.