#프론트엔드 #브라우저 #렌더링
2023-07-25 Note browser frontend notes renderingHTML CSS JS ECMAScript, Babel, 모듈, DOM, SPA
다음 자료 1 를 참고하여 키워드 정리 한다. 그리고 좋은 책으로는 2이 있다. 이 책은 내가 번역할 예정이다.
웹 페이지가 브라우저에 표시 되는 과정
https://zenn.dev/ak/articles/61d25099295372 좋은 글입니다.
URL 해독
HSTS 목록 살펴보기
HTTP Strict Transport Security (HSTS) https://zenn.dev/ak/articles/dfaa9e01b374a0
DNS 로 IP 주소 얻기
브라우저 캐시 확인 hosts 파일 검사 스타브리졸바 호출 캐시 DNS 서버에 캐시가 있으면 캐시 DNS 서버에 캐시가 없으면 Amazon Route 53 찾지 못하면
포트 번호
HTTP 요청 제출
로드 밸런서 헬스 체크 세션 유지
HTTP 응답 제출
HTML 렌더링
JSON 데이터 검색
끝
SPA
기존 웹 앱
브라우저 렌더링의 작동 방식
https://zenn.dev/ak/articles/c28fa3a9ba7edb
HTML 다운로드
HTML 분석
Bytes 에서 Characters 로 변환 Tokens 로 변환 Nodes 로 변환 DOM 구축 CSS 다운로드
CSS 분석
CSSOM 구축
JavaScript 다운로드
JavaScript 실행
어휘 분석 구문 분석 컴파일 실행
렌더 트리 구축
Layout
Painting
Paint Composite
참고문헌
전체 흐름 Token 정보 Nodes, DOM, CSSOM 정보 JavaScript 실행 정보 Layout 정보 Paint 정보
ECMAScript
JavaScript 표준을 제정 ES6 (2015) 에서 let const class promise module 등의 기능 추가
Babel
6 to 5 변환
Module
배경 - 의존성 문제를 해결 하기 위해서 아래 CommonJS 가 2009 년 등장
CommonJS
초기에는 서버 측에서 JavaScript 사용이 목표였으므로 ServerJS 였음. 이 스펙에 따라서 구현 된 것이 Node.js 라고 하는 서버 측 JavaScript 실행 환경이다.
모듈을 로드하려면 아래와 같이 한다.
const fooFunc = require("./foo.js")
fooFunc()
이는 노드에서 모듈을 처리하는 메커니즘. 즉, 브라우저에서 호출 하면 동작 안됨. 편리한 npm 패키지들을 브라우저에서 사용하기 위해서 Browserify 모듈 번들 등장 (2011)
Module Bundler
3에 따르면 자바 스크립트의 모듈 종속성을 해결하고 하나의 JavaScript 파일로 결합하는 도구. 결합이 번들이라는 말임.
모듈을 통한하는 도구를 뜻함. 오. 이 문서그래서 CommonJS 로 작성된 코드로 브라우저 상에서 실행 할 수 있게 되었다.
ESM
ECMAScript Modules가 제정되었다. 이는 2015 년 ES6 표준임. ES Modules, ESM 과 동일한 말이다.
import, export 를 브라우저에서 사용하면 된다.
<html lang="ja">
<body>
<!-- ESMを利用するときは、 type="module" を必ず付ける必要がある-->
<script type="module">
import { fooFunc } from './foo.js'
fooFunc()
</script>
</body>
</html>
function fooFunc() {
console.log("Hello World from foo!");
}
export { fooFunc };
장점 :: 기본으로 Strict 모드, await 사용, 정적 분석 가능
모듈 번들러가 여전히 필요한 이유는
웹 응용 프로그램의 성능 저하 방지하기 위함. 모듈 번들러를 사용하지 않고 ESM Native 로 실행하면 아래 그림과 같이 파일 로딩이 다수 발생하게 된다. 모듈 번들러를 사용하지 않으면 프로젝트 규모에 따라서 왕복 횟수가 수백 수천에 이를 수도 있다.
잠시만, 내가 관심있었던 Native ESM 관련 링크도 있다. 다음 헤딩에 추가.
그래서 여러 파일을 번들로 묶는 것이다. 그렇다고 막 묶으면 번들 사이즈가 너무 커진다. 주의가 필요하다.
그래서 어떻게 하는가? 디노에서 어떻게 하는지만 알면 된다.
Native ESM
https://zenn.dev/uhyo/articles/what-is-native-esm-era
Native ESM 시대란 무엇인가?ECMASCRIPT 스펙으로 정의된 모듈 시스템. 브라우저에서 직접 import, export 사용. 그래서 Native 는 이를 강조하는 것 임.
Native ESM 시대라는 말은 빌드 후에도 ES Modules 을 사용하는 것을 의미.
프런트 엔드 측면에서 보면 브라우저는 빌드에서 얻은 아티펙트를 로드. 빌드 단계를 담당하는 도구가 Babel, esbuild, webpack 등임. 주류의 방법에서는 번들러라는 툴로 여러개의 import, export 결과를 하나의 JavaScript 파일로 통합. 즉 빌드 후에는 ES 모듈 사용 안함.
이와 달리 네이티브 시대는 빌드 후에도 모듈을 이용. 즉 복수 파일. 왜? 무엇을 해결 하는가? 빌드 성능 문제와 런타임 성능 문제. 여기에 대응하려는 접근임. 관련 기술 내용이 있지만 일단 개념만 알면 되겠음.
DOM : Document Object Model
Document Object Model (DOM)은 HTML 및 XML 문서에 대한 프로그래밍 API 입니다. 문서의 논리 구조와 문서에 액세스하고 조작하는 방법을 정의합니다.
서버가 보내준 HTML 를 바로 해석 할 수 없다. 구문 분석 한 후 메모리에 트리 형태의 데이터 구조로 변환함. 이게 DOM 트리임.
트리로 변환 된 각 요소는 각각이 노드 임. 이 노트를 업데이트 하면 웹 페이지 표시도 자동 변경. JavaScript 사용 하면 돔 트리에서 임의 노드를 검색 편집 삭제 추가 등 작업을 할 수 있다. 이처럼 컨텐츠를 동적으로 변경하기 위해서 노드를 조작하는 작업을 DOM 조작이라고 함.
SPA : Single Page Application
Single Page Application 은 단일 HTML 페이지를 로드하여 사용자의 애플리케이션 작업에 맞게 페이지를 동적으로 업데이트하는 웹 애플리케이션입니다.
기존 MPA 는 사용자 즉 클라이언트 측에서 요청 보내면 서버에서 적절한 웹 페이지 정보 (HTML, CSS, JS)를 보냄. 클라이언트는 받은 정보로 페이지를 업데이트함.
SPA 에서는 CCR(Client Side Rendering)로 페이지 일부 동적 업데이트 가능.
- 첫 번째 요청 제출
- 서버 측은 웹 페이지 정보(HTML/CSS/JavaScript 등)를 응답합니다.
- 클라이언트 측에서 HTML 그리기
- API 서버에 필요한 데이터 요청
- 클라이언트 측에 필요한 데이터 응답
- 자바 스크립트 DOM 조작 으로 차이점 업데이트
1-3 은 동일. JavaScript 로딩이 완료 되면 4-6 만 반복하면 됨. 헤더나 바닥글과 같은 공통 부분은 다시 쓰지 않고 유지. 즉 전체 페이지 재로딩 할 필요가 없음.
CSR(Client Side Rendering) 문제점
첫 페이지 표시 속도가 느림. 처음 요청시 거의 빈 HTML 파일만 받고 자바스크립트가 로딩 될 때 까지 빈 화면이 표시. 이러한 문제에 대응하기 위해서 SSR 렌더링 등장.
SSR(Server SIde Rendering)
서버 측 렌더링(SSR)은 브라우저 대신 서버에서 웹 페이지를 렌더링하는 화면 표시에 유용한 애플리케이션 기능입니다. 서버측은 완전히 렌더링된 페이지를 클라이언트로 보냅니다.
즉 처음에는 서버 측에서 하고 그 이후 엑세스는 클라이언트에서 차이만 업데이트.
- 첫 번째 요청 제출
- 서버 측에서 JavaScript 실행
- API 서버에 초기 데이터 요청
- 초기 데이터 응답
- 서버 측에서 HTML 생성
- 렌더링 된 HTML / CSS / JavaScript 등을 응답
- 클라이언트 측에서 JavaScript 실행
- 차등 업데이트에 필요한 데이터 요청
- 클라이언트 측에 데이터 응답
- 자바 스크립트 DOM 조작 으로 차이점 업데이트