코드를 변경하기 전에 고객 여정을 프로파일링하세요
내비게이션 열기, 결과 필터링, 양식 제출과 같은 중요한 경로와 상호작용 하나를 선택하세요. Chrome DevTools의 Performance 패널에서 깨끗한 브라우저 상태로 기록하세요. 같은 동작을 반복해 CPU 스로틀링을 적용한 실행과 개발용 머신에서의 실행을 모두 캡처하세요. 데스크톱 트레이스는 성능이 낮은 휴대폰에서 문제를 일으키는 작업을 숨길 수 있습니다.
트레이스는 번들 보고서에서 구성요소를 비난하기 위한 것이 아니라 좁은 가설을 테스트하는 데 사용하세요. Main 플레임 차트에서 더 넓은 막대는 더 오래 걸리는 작업을 의미하고, 겹친 막대는 호출 스택을 나타냅니다. 태스크에 빨간 삼각형이 있으면 잠재적 long task를 식별한 것입니다; 이를 선택하고 태스크를 시작한 코드 링크를 따라가세요. 의미 있는 변경을 위해 전후 트레이스를 저장하세요.
동작 직전부터 기록을 시작하고 가시적 결과 후에 멈추세요.
경로, 계정 상태, 동작 순서를 일관되게 유지하세요.
각 최상위 비용 항목에 대해 변경할 수 있는 팀이나 벤더를 배정하세요.
트레이스를 작업 큐로 읽으세요
긴 작업(long task)은 조사를 시작하는 기준일 뿐, 완전한 진단은 아닙니다. W3C Long Tasks 명세는 50밀리초 이상 지속되는 작업을 보고합니다. 작업 내부에는 JavaScript 평가, 이벤트 핸들러, 스타일 재계산, 레이아웃 또는 페인트가 있을 수 있습니다. 호출 스택은 어디서 조사를 시작할지 알려 주고, 타이밍은 문제가 코드, 렌더링 또는 서드파티 프레임 중 어디에 있는지 보여 줍니다.
가치 있는 인터랙션 중 반복되는 비용을 우선순위로 두세요. 짧은 핸들러도 레이아웃을 트리거하거나 이전 작업 뒤에서 대기하면 느리게 느껴질 수 있습니다. 트레이스는 실험실 측정이므로 대표 디바이스와, 가능하면 개인정보를 고려한 필드 텔레메트리에서 수정 결과를 확인하세요.
스타트업 파싱은 탭 이후 핸들러와 다른 해결책이 필요합니다.
리팩터링 전에 반복되는 스타일 쓰기와 레이아웃 읽기 패턴을 찾으세요.
트레이스, 시나리오, 최상위 비용을 작업 항목에 첨부하세요.
중요한 시점에 더 적은 코드를 배포하세요
경로와 목적별로 스크립트를 목록화하세요. 사용되지 않는 패키지, 중복, 종료된 실험, 더 이상 필요 없는 기능 코드를 제거하세요. 그런 다음 경로별이거나 드물게 사용되는 기능은 초기 경로 대신 필요할 때 로드되도록 분리하세요. 동적 로딩은 시작 작업을 줄일 수 있지만 사용자가 즉시 기능이 필요할 때 눈에 띄는 지연을 만들 수 있습니다.
컴포넌트에 전체 클라이언트 측 프레임워크가 필요한지, 유틸리티가 기존 기능을 중복하는지, 정적 HTML에 작은 개선만 더해도 충분한지 검토하세요. 지연 로드되는 모듈의 폴백 상태를 테스트하세요. 선택적 기능의 로딩을 미루더라도 페이지에 작동하지 않는 컨트롤이 표시되어서는 안 됩니다.
어떤 스크립트가 어떤 경로에서 허용되는지와 그 이유를 문서화하세요.
선택적 편집기, 지도, 플레이어, 리포팅 뷰 같은 곳에 고려하세요.
인증, 접근성, 결제, 양식 완료를 테스트하고 컨트롤에 영향이 있으면 적격한 검토를 받으세요.
브라우저가 응답할 수 있도록 작업을 분할하세요
작은 함수로 나눈다고 해서 동기적으로 실행되는 브라우저 작업이 자동으로 분리되지는 않습니다. 긴 루프가 있다면 작업을 배치로 나누고, 먼저 사용자에게 즉시 보이는 상태를 업데이트한 뒤 계속하기 전에 제어권을 양보(yield)하세요. 그러면 배치 사이에 브라우저가 입력과 렌더링을 처리할 수 있습니다.
지원되는 경우 scheduler.yield()는 메인 스레드에 양보하고 이후에 작업을 계속합니다; 기능 감지를 하고 지원되지 않는 브라우저에는 폴백을 사용하세요. 너무 작은 연산마다 양보하지 마세요: 오버헤드가 있고 완료 시간을 늘릴 수 있습니다. 측정에서 경계를 선택하고 취소를 보존하며 오래된 결과가 최신 상태를 덮어쓰지 않도록 하세요.
보이지 않는 후속 작업보다 먼저 작업이 접수되었음을 알리거나 진행 상태를 표시하세요.
항목당 한 번이 아니라 측정된 작업이 길어지기 전에 양보하세요.
현재 web.dev 안내는 isInputPending() 기반의 새로운 전략을 권장하지 않습니다.
인터페이스가 아니라 계산을 워커로 옮기세요
Web Worker는 메인 실행 스레드와 분리된 백그라운드 스레드에서 스크립트를 실행합니다. 비용이 큰 파싱, 데이터 변환, 검색 인덱싱 등 DOM 직접 접근이 필요 없는 계산에 적합합니다. 정의된 입력을 보내고 정의된 결과를 반환하며 렌더링과 가시적 상태 변경은 메인 스레드에 남겨두세요.
워커는 만능이 아닙니다. DOM을 직접 조작할 수 없고 Window를 사용할 수 없으며 일반 메시지 통신은 데이터를 복사합니다. 워커 생성, 데이터 이동, 오류 조정은 작은 계산의 경우 이득보다 비용이 클 수 있습니다. 전체 인터랙션을 측정하고 불필요한 워커는 종료하며, 워커 작업이 실패할 경우 폴백을 설계하세요.
입력·출력이 직렬화(serialize)되어 테스트 가능한 계산부터 시작하세요.
오래된 필터, 경로, 액션에 대해 생성된 결과는 폐기하세요.
정상 인터페이스를 통해 의미 있는 진행 정보를 제공하세요.
서드파티 JavaScript를 프로덕션 종속성으로 관리하세요
애널리틱스, 광고, 실험, 소셜 임베드, 비디오 플레이어, 지원 위젯은 요청, JavaScript 평가, iframe, 종속성을 추가할 수 있습니다. 벤더 스크립트는 필요할 수 있지만 애플리케이션 팀의 직접적인 제어 밖에 있으며 성능, 개인정보, 보안, 연속성에 영향을 줄 수 있습니다. 목적, 경로, 로딩 조건, 승인자, 동의 요구사항, 제거 소유자를 목록화하세요.
조건과 계약이 허용하는 경우, 서드파티 오리진 하나를 포함했을 때와 제외했을 때의 대표 페이지를 비교하세요. 성능 도구는 비용이 큰 평가, 페이로드, 긴 작업의 귀속 정보를 드러낼 수 있습니다. 문서화된 가치가 측정된 비용을 정당화할 때만 경량 또는 지연된 통합을 유지하세요. 선택적 종속성이 느리거나 없을 때도 핵심 콘텐츠와 주요 거래 기능이 정상적으로 제공되는지 확인하세요.
필요한 경로와 조건에서만 태그를 로드하세요.
태그 관리자 변경을 성능, 개인정보, 보안, 롤백 검토에 포함하세요.
비핵심 통합을 비활성화하는 방법을 문서화하고 테스트하세요.
반응성을 릴리스 안전망으로 만드세요
개선 효과가 확인된 트레이스를 중요한 여정에 대한 간단한 회귀 검사로 전환하세요. 포함할 상호작용, 기기 또는 CPU 제약 조건, 기대 응답, 검토자를 정의하세요. 번들 및 서드파티 인벤토리 검토를 함께 수행해 새 패키지나 태그가 메인 스레드 작업을 조용히 다시 도입하지 못하게 하세요.
Status Is UP은 라이브 가용성 모니터링을 대체하려는 것이 아니라 사전 최적화와 안전한 수정의 근거로 이 증거를 사용합니다. 고위험 변경 전에는 롤백을 준비하고 릴리스 후 핵심 흐름을 검증하세요. 결과는 디바이스, 네트워크, 브라우저, 콘텐츠, 계정 상태에 따라 달라지므로 임계값을 보증이 아닌 가이드레일로 취급하세요.
공유 내비게이션, 체크아웃, 검색, 대형 번들에 대해 전후 트레이스를 요구하세요.
알려진 정상 동작을 복원하는 기능 플래그, 태그 설정, 배포 버전을 숙지하세요.
주요 릴리스, 벤더 변경, 디바이스 믹스 변화 후에 다시 프로파일하세요.