외부 스크립트마다 필요한 시간을 선언해
| 전략 | 실행 시점 | 맞는 사례 |
|---|---|---|
beforeInteractive | hydration 전 | bot 탐지, 동의 배너처럼 먼저 필요한 코드 |
afterInteractive | hydration 뒤 | 분석, tag manager. 기본값이야. |
lazyOnload | 브라우저가 한가할 때 | 채팅 위젯, 소셜 embed |
worker | Web Worker 안 | 메인 스레드를 막지 않아야 하는 무거운 계산 |
beforeInteractive는 루트 레이아웃에만 둬
이 전략은 문서 head에 일찍 주입되어야 하므로 루트 레이아웃에서만 허용돼. 다른 컴포넌트에 두면 실행 시점 오류가 나. “혹시 모르니 일찍”이 아니라 페이지가 동작하기 전에 반드시 필요한지 증명할 수 있을 때만 골라.
제3자 코드는 제품의 성능 예산을 써
분석과 위젯은 앱 번들과 별개라서 놓치기 쉽지만 메인 스레드, 네트워크, 개인정보 동의에 모두 영향을 줘. 전략을 고른 뒤 실제 사용자 지표에서 INP와 LCP 변화를 확인해.
제3자 스크립트마다 없을 때 깨지는 기능, 필요한 최초 시점, 개인정보 범위를 표로 적어 전략을 골라. consent 이전에 분석이 실행되지 않는지, 실패했을 때 핵심 UI가 남는지, route 이동마다 중복 초기화되지 않는지 확인해. 사용하지 않는 공급자 태그는 주기적으로 제거해.
lazyOnload로 미루면 초기 성능 영향은 줄지만 스크립트의 총 CPU와 개인정보 책임은 사라지지 않아. worker 전략도 DOM 접근이 필요한 코드는 옮길 수 없어. 로딩 전략은 나쁜 스크립트를 좋은 코드로 바꾸는 게 아니라 피해 시점을 조절하는 도구야. 스크립트가 실패하거나 차단됐을 때 핵심 화면이 계속 읽히는지도 확인해. 분석과 광고처럼 부가 기능인 스크립트가 오류를 던져 앱의 상호작용까지 멈추게 해서는 안 돼.
네 전략으로 같은 모의 스크립트를 불러 실행 시점과 메인 스레드 작업을 기록해. beforeInteractive를 잘못된 위치에 두었을 때 오류를 확인하고, 분석 스크립트를 차단해도 핵심 기능이 남는지, 동의 전 요청이 전혀 나가지 않는지도 network에서 검증해. 제3자 서버를 막거나 느리게 한 상태에서도 핵심 상호작용이 끝나는지 확인해. 로딩 전략은 속도 선택이면서 외부 장애를 격리하는 계약이야.