Mong dev blog

개발 기술212

이미지 리스트 성능 문제는 DOM에서 끝나지 않는다

0. 들어가며…vue, react를 이용해 dom을 렌더링하는 게 자연스러워진 요즘.각 프레임워크에서 리스트를 표현할 때는 Vue에서는 v-for, React에서는 map을 사용해 여러 DOM 요소를 렌더링한다.이 방식은 단순하다. 그래서 데이터 배열만 있으면 누구나 손쉽게 리스트 UI를 만들 수 있다.하지만 이 단순한 방식이 언제나 좋은 선택은 아니다.DOM을 계속 늘려도 괜찮을까?만약 다음 조건이라면 큰 문제는 없다.데이터 개수가 100개 미만이고노출되는 리스트 DOM이 많지 않으며한 화면에서 무거운 연산을 하지 않는 경우이런 상황에서는 단순 렌더링 방식이 성능 리스크로 이어질 가능성은 크지 않다.하지만 리스트 DOM이 100개를 넘어 1,000개, 혹은 그 이상까지 늘어날 수 있는 구조라면?이 시점..

sourcemap? 운영에서는 그냥 끄는 옵션 아니에요?

0. 들어가며…이거 무슨 에러지?개발을 하다 보면, 다음과 같은 에러를 마주치게 된다.app-abc123.js:1:120Uncaught Error: Something went wrong에러는 분명히 발생했고 콘솔에도 찍혔다. 그런데 이상하다…?에러 메시지를 가만히 들여다보고 있으면 몇 가지 답답함이 밀려온다.어떤 파일에서 발생한 에러인지 감이 안 오고어떤 코드 줄에서 터졌는지도 모르겠고심지어 이게 내가 작성한 코드인지조차 확신이 안 든다에러는 났는데 정작 어디를 봐야 할지 모르는 상태. 이쯤 되면 자연스레 이런 생각이 든다.*"아… 이거 sourcemap 없어서 그런가?"*sourcemap, 들어는 봤는데 설명은 애매한 그 단어sourcemap. 대부분의 개발자가 한 번쯤은 들어봤을 단어다.하지만 막상 ..

브라우저 렌더링 최적화를 위한 Virtual Scroll - 구현 코드 살펴보기

0. 들어가며1편에서는 Virtual Scroll이 어떤 원리로 렌더링 비용을 줄이는지,그리고 실제 Chrome Performance Trace에서 Layout·Paint·GPU Memory가 얼마나 절감되는지를 살펴보았다.Virtual Scroll은 얼핏 보면 “DOM을 줄이고, translateY로 위치만 바꾸는” 단순한 구조처럼 보인다.하지만 실제로 구현해보면 다음과 같은 고민들이 바로 등장한다.1. 스크롤이 발생할 때 어떤 index부터 렌더링해야 할까?2. 화면에 필요한 DOM pool 크기는 어떻게 계산할까?3. Pool DOM은 어떤 방식으로 위치만 이동시켜 재사용할까?4. 이미지 로딩처럼 아이템 높이가 바뀌면 offset을 어떻게 갱신해야 할까?5. scroll 이벤트가 아주 자주 발생하는..

브라우저 렌더링 최적화를 위한 Virtual Scroll - 원리/성능 비교

0. 들어가며…대부분의 서비스는 수 많은 데이터를 스크롤 기반으로 보여준다.거래 내역, 로그, 쇼핑 내역처럼 연속된 데이터를 무한 스크롤로 제공하는 방식은 이미 모바일·웹 모두에서 기본 UI 패턴이 되었다.그런데 특정 상황에서 이 스크롤 방식이 문제가 될 수 있다. "만약 한 번에 보여줘야 하는 아이템이 100개 이상이라면 어떨까?"단순히 100개의 DOM을 렌더링해 스크롤하는 정도는 괜찮아 보이지만, 실제 서비스 환경에서는 상황이 다르다.예를 들어, 100개짜리 리스트를 무한 스크롤로 노출한 상태에서 소켓 데이터가 실시간으로 들어오고, 동시에 canvas 기반 그래프까지 그려야 한다면?스크롤이 순간적으로 뚝뚝 끊기는 ‘렉’이 발생한다.이 문제의 핵심 원인은 화면에 쌓여 있는 DOM 수와 그로 인해 반복..

[Vue] Fragment의 함정: 왜 $el은 Text Node가 될까?

0. 들어가며…Vue에서 자식 컴포넌트의 스타일을 가져올 때 ref.value.$el.{스타일_속성} 방식을 사용한다.// 부모 컴포넌트console.log(childRef.value.$el.style.clientHeight) // 300여기서 $el은 “컴포넌트 인스턴스가 관리하는 루트 DOM 노드”를 가리킨다.그래서 이 방법을 사용하면 같은 루트 요소의 스타일을 바로 읽을 수 있다.그런데 어느 날, 컴포넌트의 레이아웃 구조를 바꾸자 $el.{스타일_속성}이 undefined를 반환하기 시작했다.💡문제 상황부모 컴포넌트는 2개의 자식 컴포넌트를 가진다.그리고 각 자식 컴포넌트의 높이 값을 $el.clientHeight 방식으로 가져왔다. 각 자식 컴포넌트의 구성은 다음과 같다. hello..

[TS × 클린 아키텍처] 2편 — 타입스크립트 한계와 Mapper: AST로 타입 검증하기

0. 들어가며…최근에 클린 아키텍처를 적용하면서, data → domain 변환을 담당하는 Mapper 클래스를 만들었다.이 과정에서 타입스크립트(TypeScript)를 적극적으로 활용해 타입 안정성을 확보했지만, 하나의 큰 벽에 부딪혔다.타입스크립트의 타입은 런타임에 존재하지 않는다는 것!즉, 코드 상에서는 안전해 보이지만, 실제 실행 환경(JS 런타임)에서는 그 모든 타입 정보가 사라진다.결국 API나 외부 모듈에서 잘못된 타입의 데이터가 들어오더라도 이를 검증할 방법이 없었다.1편에서는 검증을 위해, Zod 처럼 스키마 기반의 타입 검증기를 만들었으나 다음과 같은 3가지 문제가 있었다.문제설명성능매번 스키마를 해석하며 검증함 → 반복 비용 발생안전성타입 정의와 스키마가 불일치할 수 있음DX(개발 경..

[TS × 클린 아키텍처] 1편 — 타입스크립트 한계와 Mapper: 스키마로 런타임 검증하기

0. 들어가며이번에 회사에서 새 레포지토리를 구성하면서 가장 먼저 고민한 것은 도메인 계층과 UI 계층을 어떻게 분리할 것인가였다. 기존에는 UI 코드 안에 모든 비즈니스 로직이 섞여 있었고, API 응답 객체를 그대로 사용하는 방식이었다. 하지만 이 방법은 다음과 같은 두 가지 문제를 만들었다.문제 1. API 응답 객체를 그대로 사용 → MER_UUID, USR_NM 같은 축약 필드명이 코드 전반에 퍼져 가독성이 떨어졌고, 백엔드 필드명이 변경되면 프론트엔드 전체를 수정해야 했다.문제 2. UI와 비즈니스 로직이 뒤섞임 → Vue/React 컴포넌트 파일 안에 UI 코드와 비즈니스 플로우가 함께 들어있어, 코드 변경 시 UI까지 영향을 받는 경우가 많았고 책임 분리가 어려웠다.클린 아키텍처는 “의..

[JS] 모바일 웹뷰에서 가상 키보드 감지하는 법: visualViewport·디바운스·rAF

1. 들어가며모바일 웹/웹뷰에서 인풋 포커스로 키보드가 열리고 닫힐 때, 동시에 바텀시트(하단 고정 팝업)를 다루면 화면이 종종 “들썩인다”.타이밍이 조금만 어긋나도 바텀시트가 순간적으로 튀거나 위치가 흔들려 UX의 신뢰성을 해쳐 서비스의 완성도도 낮아 보인다.이 문제를 해결하려면 가상 키보드 상태를 감지해야 한다. 그러나 아쉽게도 모든 환경에서 통하는 표준 API는 없다.특히 인앱 웹뷰는 브라우저마다 구현이 달라, 키보드의 표시·숨김 타이밍을 직접 알려주지 않는다. 그럼, 어떻게 해야 가상 키보드의 열림/닫힘을 감지할 수 있을까?focus/blur를 보고 추정하기? 아니면 화면 리사이즈 변화를 관찰하기?이번 글에서는 두 접근을 모두 살펴보고, 이 중 실제로 효과가 있었던 리사이즈 + 디바운스 + rAF..

[JS] Array.map() vs Iterator Helper API: 어떤 방식이 더 빠를까?

0. 들어가며…JavaScript로 반복 작업을 처리할 때, 우리는 주로 Array.map(), forEach(), for…in 같은 메서드를 사용한다.특히 Array.map()은 filter(), some() 등과 연결할 수 있어 가독성 높은 코드를 작성할 수 있다.그런데, 만약 데이터 크기가 수십만, 수백만 건에 이르거나 파일 스트림처럼 순차적으로 들어오는 데이터를 다룰 때는 어떨까? Array.map()을 사용하게 되면…전체 배열을 한 번에 처리하면서 생성된 중간 결과들이 모두 메모리에 쌓이게 되고,실제로 필요한 데이터는 극히 일부인데도 불필요한 연산을 수행해야 한다. 그럼 Array.map() 말고 다른 방법은 없을까?2025년 3월 TC39 Stage 3로 승격된 Iterator Helper A..

이전 1 2 3 4 ··· 24 다음

티스토리툴바