개발/테크톡

지난번 브라우저 최적화라는 주제로 [브라우저 최적화(1)] CRP의 이해와 브라우저 리소스 식별 방법 글로 잠깐 소개한 적이 있다. 오늘은 그보다 딥 다이브할 수 있는 주제를 가져왔다.개요우리가 자주 마주하는 브라우저 렌더링 프로세스의 내용은 위 그림 처럼 자주 접해왔다.요약: HTML에서 DOM 트리 생성하고, CSS 받아서 CSSOM 생성하고, 이를 합져서 자바스크립트를 실행해서 렌더 트리를 구성하고, 레이아웃 실행 후 페인트 처리가 되고 마지막에 디스플레이에 짜잔~! 하지만 우리는 이론적으로 렌더링 플로우가 위 이미지처럼 흘러가고 있다 정도만 이해하는 경우가 대다수다. 실제로 브라우저라는 애플리케이션에선 저 플로우를 수행하기 위해 엄청나게 많은 컴퓨터 내부 작업들이 이루어진다.프론트엔드 개발을 하면..

지난 Typescript 모듈 해석 방식 - tsconfig 설정과 실행 환경에 따른 차이 포스팅 다음 글로, Typescript의 중요한 옵션 중 하나인 Moduel Resolution에 대해서 알아보려고한다. 먼저 Module Resolution이 무엇인지, 이를 해석하는 방식이 어떻게 되고, 다양한 모듈에 대한 대응 방식 등에 대해 정리해보았다. Module Resolution이란 무엇일까?Typescript는 import한 파일을 실제로 어디서 찾는지 결정하는 과정이 어떻게 될까?import sayHello from "greetings";sayHello("world"); greetings는 어디에 있을까?node_modules/greetings/index.js일까?./greetings.ts일까?...

이번 글에선 타입 스크립트에서 modules의 기초가 되는 Module Resolution이 어떠한 배경으로 나오게 되는지 알기 위해 CommonJS(CJS)와 ECMAScript 모듈(ESM)의 차이, 그리고 타입스크립트가 모듈을 어떻게 해석하고 변환하는지 상세 다룰 예정이다. 자바스크립트에서의 모듈 개념의 발전을 시작으로, 타입스크립트가 모듈을 해석하는 과정과 트랜스파일링(컴파일 시점 변환) 시 고려해야 할 사항을 설명한다. 또한 Node.js와 번들러(Webpack 등)에서의 모듈 실행 환경의 차이점, 그리고 타입스크립트에서 사용할 수 있는 다양한 모듈 설정 값들(module 옵션) 에 대해서도 분석해보자. 배경자바스크립트는 브라우저에서만 실행되던 초기에는 모듈이 없었지만 HTML에서 스크립트 태..

지난 글 [브라우저 최적화(1)] CRP의 이해와 브라우저 리소스 식별 방법 CRP에서 렌더링 및 파서 차단에 대해 종류 역할을 이해하고 브라우저의 리소스를 식별하는 방법에 대해서 알아보았다. 브라우저 리소스의 흐름을 파악하게 되면 비로소 브라우저 최적화를 할 수 있는 단계를 밟을 수 있게 된다.이번 글에는 라이브러리나 프레임워크에서 최적화하는 방법과 이를 의존하지 않는 방법에 대해 정리해본다. preloadpreload는 현재 페이지에서 바로 필요로 하는 리소스를 먼저 가져오는 방법이다. 이 리소스는 CRP 이전에 요청되어 더 빨리 사용할 수 있고, 페이지의 렌더링을 막을 가능성이 낮아져 성능을 향상한다. preload는 폰트나 이미지 등 CSS 내부에서 사용하는 리소스, 크기가 큰 이미지와 비디오 파..

웹 페이지는 최초 렌더링 단계나 네트워크에서 렌더링/파서 차단(redner-blocking, parser-blocking)을 어떻게 다루냐에 따라 성능에 크게 좌우가 된다. 그 중에서 CRP(Critical Rendering Path)가 어떻게 흘러가는지 이해하고, HTML 속성과 CSS 처리 옵션을 다룰 줄 알면 사용자 경험을, 개선을 크게 향상 시킬 수 있다.이번 글에선 브라우저 렌더링 단계에서 CRP가 무엇이고 어떤 단계에서 리소스가 차단되는지 그리고 렌더링 우선순위를 어느 위치에 잡아야 하는지 알아보고 브라우저에서 제공하는 기능들을 통해 브라우저 리소스 로딩을 최적화하는 방법을 알아보자. CRP(Critical Rendering Path)CRP란 브라우저가 서버로부터 HTML, CSS, Javas..

개요디자인 시스템 구축을 위해 `Radix-UI` 를 사용 중인데 내부 구조를 살펴보다가 이벤트 핸들링 방식에 대해 궁금하여 오픈 소스 코드를 살펴보던 중 2년전 React가 17에서 18로 업데이트 되면서 이벤트 처리에 대한 큰 변화로인해 트러블 슈팅을 겪은 사례에 대해 알게되어 조사하게되었다. (이 글은 저의 트러블 슈팅이 아닙니다...!) 사건의 발단으로는 하나의 이슈 사항으로 인해 PR이 머지 된 사례가 있었다. 이슈로는 `ContextMenu`에 대한 일관된 동작이 이루어지지 않는 다는 것. 이는 React 18의 핵심 변경 사항 중 하나로, 모든 이벤트 핸들러에 일관되게 자동 일괄 처리(automatic batching)를 도입한 것으로, 특정 이벤트만 일괄 처리를 적용이 가능했던 17버전과는..