지난 글 [브라우저 최적화(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버전과는..

개요프론트엔드에서 비동기 처리 중 가장 많은 비중을 차지하는 것이 "데이터 페칭"이라고 생각한다. React의 Suspense는 선언적 비동기 처리 작업 중에서 많은 개발자들 활용하는 기능이지만 일반적인 방식의 데이터 페칭 방식으로는 Suspense 처리를 할 수 없다.왜 그런 걸까? React의 Suspense의 개념과 기능에 대해서는 많이 알려져 있으니, 개념과과 기능은 따로 알아보고 지원하지 않은 이유와 Suspense의 구조/처리 방법에 대해 알아보고, tanstack-query나SWR와 같은 라이브러리에서는 어떤 식으로처리하여 선언적으로 사용할 수있는지해 알아보고자 한다.React 팀이 Suspense의 데이터 패칭을 지원하지 않은 이유Suspense는 이펙트 또는 이벤트 핸들러 내부에서 데..

개요 이번엔 RN(React Native)을 살펴볼 일이 생겼는데, 문득 RN이 어떤 방식으로 JavaScript에서 브라우저 엔진 없이 Native(iOS,Android)에서 상호작용과 UI가 그려지는지 궁금하게 되었다. 이번 글은 RN의 과거와 현재의 아키텍처가 어떤 식으로 구성되어 왔고, 개선된 아키텍처는 어떤 방식의 메커니즘을 가지게 되는지 정리해 보고자 한다. 웹 개발만 해 오던 분들이라면 너무 깊게 이해할 필요는 없을 것 같고, 단순히 React와 RN이 어떻게 다르게 동작하는지를 아키텍처 관점으로만 가볍게 봐도 괜찮을 것 같다. 먼저 RN의 메커니즘을 이해하기 위해선 아키텍처를 이해해야 하는데, RN은 0.68 버전 전부터 적용해 오던 브릿지(Bridge) 메커니즘을 적용하고 있었다. 하지만..

[원문]: https://code.visualstudio.com/blogs/2023/06/05/vscode-wasm-wasi#_how-does-it-work 한때 우리는 웹용 VS Code(https://vscode.dev)를 브라우저에서는 모든 편집 / 컴파일 / 디버그 주기를 지원하는 것을 목표로 하고 있었습니다. 브라우저에서 자바스크립트 실행 엔진이 제공된 후로 자바스크립트와 타입스크립트와 같은 언어는 비교적 쉽게 적용할 수 있었습니다. 하지만 코드를 실행(디버깅 같은)할 수 있게 된 후로 다른 언어에서는 더욱 어려웠습니다. 예를 들어, 브라우저에서 Python 코드를 실행하려면 Python 인터프리터를 실행할 수 있는 실행 엔진이 필요합니다. 이런 언어 런타임은 보통 C/C++로 작성됩니다. 웹 ..