코드 땜장이

웹 애플리케이션 성능 최적화, 로딩 경로별로 정리하는 핵심 방법 빠른 답 첫 화면에 필요 없는 JavaScript는 분리하고 늦게 불러와야 초기 로딩이 빨라집니다. 이미지와 비디오는 화면에 보일 때 로드하고, 크기와 포맷을 먼저 줄여야 체감 성능이 좋아집니다. 캐시는 단순 저장이 아니라 정적 자산과 HTML의 정책을 다르게 가져가야 효과가 큽니다. 최적화는 감으로 하지 말고 Network, Performance, Lighthouse 같은 측정 결과로 우선순위를 잡아야 합니다. 목차 왜 웹 성능은 로딩 경로로 봐야 할까 흐름으로 보기 요청 시작과 리소스 다운로드에서 생기는 병목 파싱과 실행: DOM, CSSOM, JavaScript가 서로 만나는 지점 렌더링: 렌더 트리, 레이아웃, 페인트, 컴포지팅의 비용 초기 로딩을 줄이는 설정 무거운 자산을 늦게 가져오는 방법 재방문 속도를 높이는 캐시 전략 DevTools로 병목을 반복 측정하는 방법 흔한 오해와 함께 보는 정리 포인트 왜 웹 성능은 로딩 경로로 봐야 할까 같은 300KB라도 언제 내려오고 무엇을 막느냐에 따라 체감은 크게 달라집니다. 첫 화면에 바로 필요한 CSS 300KB와, 아직 열지 않은 설정 페이지의 JavaScript 300KB는 사용자 경험에 미치는 영향이 다릅니다. 그래서 성능 최적화는 파일 크기를 줄이는 일에만 머물지 않고, 어떤 자원이 어떤 단계의 병목이 되는지 파악하는 작업에 가깝습니다. 브라우저 관점에서 병목은 보통 세 갈래로 나타납니다. 네트워크에서 늦게 내려오는 경우, JavaScript 파싱과 실행 때문에 메인 스레드가 오래 묶이는 경우, 렌더링 단계에서 레이아웃과 페인트가 반복되는 경우입니다. 이 세 지점을 로딩 경로 하나로 묶어 보면 코드 스플리팅, 레이지 로딩, 캐시, CSS 최적화가 각각 어디에 영향을 주는지 자연스럽게 연결됩니다. 흐름으로 보기 이 순서를 먼저 잡아두면 최적화 기법의 위치가 정리됩니다. 코드 스플리팅과 defer 는 초기 다운로드와...

리액트 성능 최적화, 무작정 memo 쓰기 전에 먼저 봐야 할 기준들 빠른 답 느린 원인을 확인하기 전에는 memo부터 늘리지 말고 React DevTools Profiler로 병목을 먼저 찾습니다. 상태를 너무 상위에 두면 하위 전체가 자주 리렌더링되므로, 상태 소유권을 필요한 범위로 최대한 좁힙니다. useMemo와 useCallback은 비용이 큰 계산이나 참조 안정성이 실제로 필요한 경우에만 적용합니다. 초기 로딩이 느리다면 라우트 단위 코드 스플리팅부터 검토하는 편이 체감 성능에 더 직접적입니다. 목차 리액트 앱은 왜 느려질까 성능 최적화의 첫 단계: 상태 소유권 좁히기 React.memo, useMemo, useCallback은 무엇이 다를까 초기 로딩이 느리다면 코드 스플리팅부터 보기 Profiler로 먼저 확인할 것 흔한 안티패턴과 디버깅 포인트 무엇부터 적용하면 좋을까 리액트 앱은 왜 느려질까 리액트 앱이 느려질 때 많은 분이 먼저 memo , useMemo , useCallback 부터 떠올립니다. 하지만 실제 병목은 대개 훅이 부족해서가 아니라, 상태가 너무 위에 있거나, 작은 변화가 너무 넓은 화면에 전파되거나, 리스트 렌더링과 정렬·필터링 같은 계산이 반복되기 때문에 생깁니다. 여기서 먼저 구분할 것이 있습니다. 리액트에서 리렌더링은 정상 동작입니다. 상태나 props 가 바뀌면 다시 렌더링하면서 다음 UI를 계산하는 것이 리액트의 기본 모델입니다. 문제는 그 렌더링 범위가 불필요하게 넓거나, 계산 자체가 무겁거나, 실제 DOM 반영 비용까지 커질 때입니다. 즉, 리렌더링이 있다 와 성능 문제가 있다 는 같은 말이 아닙니다. 성능 최적화의 목표는 리렌더링을 무조건 없애는 것이 아니라, 사용자 행동에 비해 과도한 계산과 전파를 줄이는 것입니다. 성능 최적화의 첫 단계: 상태 소유권 좁히기 프론트엔드에서 가장 먼저 봐야 할 것은 데이터 흐름입니다. 리액트는 부모에서 자식으로 내려가는 단방향 흐름을 가지므로, 어떤 상태...