코드 땜장이

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

script async와 defer 차이, 실행 시점과 선택 기준까지 한 번에 정리 빠른 답 async는 다운로드가 끝나는 즉시 실행되어 HTML 파싱을 끊을 수 있습니다. defer는 문서 파싱이 끝난 뒤 선언 순서대로 실행되어 앱 초기화 코드에 안전합니다. 의존성이 없고 독립적으로 동작하는 외부 스크립트는 async가 잘 맞습니다. 실행 순서와 DOM 준비 시점이 중요하면 defer를 먼저 검토하는 것이 실무적으로 안전합니다. 목차 한눈에 비교 왜 둘 다 비동기인데 체감은 다를까 흐름으로 보기 HTML 파싱과 렌더링 사이에서 스크립트가 끼어드는 지점 async가 맞는 경우와 defer가 맞는 경우 설정 예시로 보는 배치 전략 콘솔과 DevTools로 실행 순서 확인하기 자주 놓치는 예외: inline script와 module script 선택 기준을 한 줄로 정리하면 한눈에 비교 Point 1 다운로드: async 와 defer 모두 HTML 파싱과 병렬로 다운로드를 시작할 수 있습니다. Point 2 실행 시점: async 는 다운로드가 끝나는 즉시 실행되고, defer 는 문서 파싱이 끝난 뒤 실행됩니다. Point 3 실행 순서: 여러 async 스크립트는 먼저 받아진 순서대로 실행되고, 여러 defer 스크립트는 문서에 적은 순서대로 실행됩니다. Point 4 DOM 접근 안정성: async 실행 시점에는 DOM이 아직 덜 만들어졌을 수 있지만, defer 는 문서 파싱 후라 DOM 접근이 훨씬 예측 가능합니다. Point 5 DOMContentLoaded 관계: defer 와 기본 module 스크립트는 DOMContentLoaded 전에 실행되며, 이 이벤트는 그 실행을 기다립니다. async 는 보통 그 흐름 바깥에서 실행됩니다. 왜 둘 다 비동기인데 체감은 다를까 헷갈리는 이유는 둘 다 “비동기로 로드된다”는 문장만 기억하기 쉽기 때문입니다. 하지만 실제 성능과 렌더링에 더 큰 영향을 주는 것은 다운로드 자체보다 스크립트...