슬기로운 땅콩 마을

본론에 들어가기 앞서, 현대의 웹 개발에서 렌더링 최적화가 모바일 앱에 비해 상대적으로 중요하지 않게 느껴질 수 있습니다. 이는 모바일 앱과 웹 간의 명확한 차이점 때문에 그럴 수밖에 없습니다. 모바일 앱은 성능과 네이티브 기능 구현에 중점을 두며, 이러한 최적화에 대한 제약이 상대적으로 적습니다. 예를 들어, 플러터는 자체 렌더링 엔진인 스키아(Skia)와 임펠러(Impeller)를 사용하며, 웹과는 다른 레이아웃 계산 방식을 채택하고 있습니다. 객체 지향적으로 잘 설계되어 있어 커스터마이징이 용이하고, 자체적으로 최적화하기도 어렵지 않습니다. 다만, 이러한 장점에도 불구하고 최적화가 부족한 앱들이 간혹 존재하기도 합니다. 반면, 웹은 렌더링 성능보다는 주로 접근성에 중점을 두기 때문에, 개발자들은 웹..

CSS 작업을 할때 사용되는 식별자인 변수, 클래스, 아이디 이름을 --a, .a, #a와 같이 압축하는 웹팩 플러그인을 개발하였습니다. 참고로 식별자 이름을 a, b, c 형태로 난독화하면서 동시에 압축하는 것을 보통 맹글(Mangle)이라고 합니다. 사용 방법은 그냥 제공되는 플러그인을 추가하면 됩니다. 다만 클래스와 아이디의 경우, 식별하는 것이 다소 까다롭기 때문에 어느정도 테스트하고 그만큼 안정화되면 추후에 기능이 기본적으로 활성화될 예정이며 혹시 사용하실 분들은 해당 플러그인은 2024-08-26, 즉 업로드 시간 기준으로 개발 버전이므로 해당 패키지를 자주 업데이트 시도해주셨으면 좋겠습니다. 변수 이름의 경우 식별하는데 어렵지 않고 JS에서 참조하는 대부분의 경우를 커버합니다. 물론 리액트에..

대부분의 경우, 프로젝트를 시작하기 위해서는 여러가지 기본적인 설정 값들을 추가하거나 수정할 필요가 있습니다, 하지만 대부분의 경우 단순 노동이라고 생각되며 세팅하는 과정에서 무언가가 잘못될 가능성도 없는 것이 아닙니다. 이러한 시간 낭비와 문제점을 줄이기 위해서 다른 사람이 미리 만들어 놓은 시작 키트, 즉 템플릿을 이용하여 초기 세팅을 빠르게 마칠 수 있습니다. 저의 경우, Preact 관련하여 최적화 세팅까지 되어있는 템플릿은 찾기가 어려웠습니다. 따라서 최대한 사용자 경험을 높이기 위해 JS의 경우 Terser를 이용하여 압축하고 CSS의 경우 별도의 플러그인으로 압축을 수행하며 webpack-dev-server를 이용한 핫 리로드(Hot Realod) 기능을 추가한 템플릿을 제작하였습니다. 그것..

오늘도 평소와 다름없이 내 깃허브에 소중하게 관리되고 있는 나의 애기들, 패키지들을 유지보수하기 위해 코드를 살펴보던 중, animatable-js의 Ticker 클래스가 눈에 띄었다. 이 클래스를 자세히 살펴보던 순간, 자바스크립트의 requestAnimationFrame 함수를 빈번하게 호출하면 브라우저의 렌더링 동기화 과정에서 상당한 성능 비용이 발생하지 않을까 하는 작은 의문이 들었다. 물론 자바스크립트 내에서 콜백 함수를 등록하고 호출하는 행위 자체는 그리 큰 비용이 들지 않는다. 하지만 requestAnimationFrame은 브라우저가 제공하는 API이며, 이를 통한 렌더링 동기화 과정에서 발생할 수 있는 여러 가지 성능 이슈의 가능성을 고려해 보았다.이러한 고민 끝에 실제로 테스트를 해보는..

웹에서는 Flutter 또는 Jetpack Compose와 달리 레이아웃 계산에 직접 관여하거나 제어할 수 없습니다. 즉, 자식의 크기를 직접 계산하거나 그려지는 요소의 위치를 정의하는 로직에 직접적으로 관여할 수 없습니다. 대신, CSS 스타일이나 JavaScript를 사용하여 레이아웃에 간접적으로 영향을 미칠 수 있습니다. 레이아웃 계산을 변경하거나 특정 요소의 크기나 위치를 조정하는 경우, 브라우저는 이러한 변화를 반영하기 위해 Reflow를 수행해야 합니다. Reflow는 레이아웃을 다시 계산하는 과정으로, 빈번하게 발생하면 성능 저하를 일으킬 수 있습니다.  이 Reflow의 경우, 레이아웃의 크기와 위치를 참조하거나 요소의 돔 구조가 변경되면 수행되는 레이아웃 단계입니다.따라서, 여러 번의 레..