브라우저가 로드하는 항목에서 단일 인벤토리를 구축하세요
대표 페이지를 먼저 수집하세요: 홈, 랜딩, 상세, 검색, 장바구니, 체크아웃, 계정, 캠페인 등. Chrome DevTools에서 신규 방문과 재방문을 기록하세요. 브라우저 증거를 태그 매니저, CMS 플러그인, 코드 의존성과 비교하세요. 한 관점만으로는 주입된 스크립트를 놓칠 수 있습니다.
공급업체나 통합별로 한 행을 만드세요. URL별로만 기록하지 마세요. 접촉하는 도메인과 태그를 추가할 수 있는지 여부를 캡쳐하세요. 목적을 방어하고 제거를 승인할 수 있는 비즈니스 소유자를 지정하세요. 캠페인, 공급업체 변경, 템플릿 릴리스, 리디자인 후 재검토하세요.
페이지, 여정, 공급업체 도메인, 요청, 전송 크기, 메인 스레드 작업, 테스트 조건을 저장하세요. 랩(trace)은 진단 증거일 뿐 모든 방문자에게 보장되지 않습니다.
목적, 소유자, 동의 범주, 트리거, 노출되는 데이터, 종속성 순서, 폴백, 검토일을 포함하세요.
유지, 제거, 예산 결정을 가시화하세요
각 소유자에게 통합이 사라지면 무엇이 더 나쁠지 물어보세요. 대답이 애매하면 비활성화하거나 제거하세요. web.dev는 예산 설정, 중복 기능 회피, 불필요한 스크립트 정리를 권장합니다.
예산은 팀의 가드레일이며 보편적 임계값이 아닙니다. 바이트, 요청, 메인 스레드 시간, 로드 타이밍에 대해 공급업체별·페이지별 허용치를 설정하세요. 변경 전후의 기준선을 비교하세요. 소유자가 허용치 내에 머물거나 다른 비용을 제거하거나 만료되는 예외를 받아야 합니다. 비교 가능한 여정과 사용자 중심 지표를 사용하세요.
현재 목적이 있고, 소유자가 비용 및 데이터 사용을 수용하며, 허용 가능한 실패 경로가 있는 종속성만 유지하세요.
만료된 픽셀, 중복 분석, 비활성 채팅, 사용하지 않는 실험, 방치된 플러그인을 단계적 릴리스로 퇴역시키세요.
사유, 비용, 승인자, 보상 조치, 검토일을 기록하세요.
늦게 로드해도 안전할 때만 늦게 로드하세요
로딩 동작을 신중히 선택하세요. classic 외부 스크립트(특별한 async, defer, module 동작 없음)는 HTML 파싱이 계속되기 전에 가져오고 실행됩니다. async에서는 다운로드가 병렬로 진행되지만 준비되면 즉시 실행되어 순서가 보장되지 않습니다. defer에서는 classic 외부 스크립트가 파싱 후 문서 순서대로 DOMContentLoaded 전에 실행됩니다. defer는 순서가 필요한 스크립트에 적합하지만 보편적 해결책은 아닙니다.
선택적 채팅, 소셜, 지도, 동영상, 추천 인터페이스는 경량 플레이스홀더를 렌더링하고 클릭이나 관련 시점에 공급업체를 로드하세요. 이 페이사드 패턴은 전체 임베드 대신 처음부터 여러분의 제어로 시작합니다. 키보드 상호작용을 보장하고 공간을 예약하세요. 가격 계산, 로그인, 결제 처리, 필수 접근성 제공, 또는 검토된 대안 없이 확정된 의무를 충족하는 코드에 대해서는 지연하지 마세요.
첫 작업 종속성에는 즉시 로드, 순서가 필요한 코드는 파싱 후, 선택적 임베드는 상호작용 또는 가시성 트리거를 사용하세요.
상호 의존 스크립트에 async를 표시하고 순서가 유지되리라 기대하지 마세요. 게시된 체인을 문서화하고 테스트하세요.
핵심 UI를 window load에 묶지 마세요. 타사 임베드는 async나 defer를 사용하더라도 이를 지연시킬 수 있습니다.
동의(Consent)를 사후처리가 아닌 관문으로 만드세요
각 공급업체를 관할 구역과 데이터 흐름을 이해하는 개인정보 및 법무 이해관계자와 분류하세요. 동의 기반 통합의 경우 태그가 관련 데이터를 전송하기 전에 동의 상태를 확립하세요. Google은 기본 동의 명령이 측정 명령보다 먼저 실행되어야 하고 선택 변경 후 업데이트가 따라야 한다고 권장합니다. 이 제품 지침은 법적 조언이 아닙니다.
첫 방문에서 무응답, 수락, 거부, 철회 상태를 테스트하세요. 인터페이스와 네트워크를 확인하세요: 위젯이 숨겨져 있다고 해서 요청이나 식별자가 전송되지 않았음을 증명하지 않습니다. 동의 플랫폼이 비동기 로드되는 경우 타이밍을 테스트하세요. 선택을 적절히 영구화하고 현재 페이지와 이후 방문에 변경 사항을 적용하세요.
공급업체 라벨에만 의존하지 마세요. 태그가 필수, 선택, 특정 지역 또는 여정에서 금지인 이유를 기록하고 승인을 받으세요.
철회 후 구성된 비필수 태그가 로드되거나 데이터를 전송하지 않음을 확인하고 테스트 증거를 보관하세요.
제어하지 않는 코드의 파급 범위를 줄이세요
OWASP는 클라이언트 변경에 대한 통제 상실, 브라우저에서 임의 코드 실행, 민감 데이터 노출을 핵심 위험으로 식별합니다. 태그 게시 권한을 제한하고 임의 HTML 또는 임의 코드 기능을 검토하며 허용된 데이터 레이어 필드를 문서화하세요. 고위험 통합에는 공급업체 계약과 자격을 갖춘 보안 검토가 도움이 되지만, 어느 것도 테스트를 대신하지 않습니다.
Subresource Integrity(SRI)는 브라우저가 스크립트를 암호 해시와 대조해 검증하게 합니다. 이는 리소스를 고정할 수 있고 교차 출처 전달에 CORS가 지원될 때만 도움이 됩니다; W3C는 CORS 없이 SRI를 사용하는 것은 논리적 오류라고 설명합니다. 많은 변경되는 공급업체 URL에는 적합하지 않습니다. iframe sandbox는 호스트 DOM과 쿠키에 대한 직접 접근을 줄일 수 있지만 전문적인 검토가 필요합니다. 결제 및 보안 민감 흐름은 자격 있는 검토가 필요합니다.
목적에 필요한 문서화된 필드만 전달하세요. 비밀, 결제 데이터, 불필요한 고객 속성을 노출하지 마세요.
SRI는 바이트를 검증할 뿐 데이터 사용이나 이후 요청의 적절성을 판단하지 않습니다; 격리는 즉시 적용되는 해결책이 아닙니다.
고객이 겪기 전에 공급업체 실패를 연습하세요
유지할 공급업체마다 테스트 환경이나 브라우저 요청 차단기에서 해당 도메인을 차단한 뒤 여정을 실행하세요. 느린 응답과 태그 매니저 구성에서 통합이 없는 경우도 테스트하세요. 주요 콘텐츠, 네비게이션, 폼, 체크아웃, 계정 접근이 의도대로 동작하는지 확인하세요. 이는 릴리스 전에 가정들을 드러냅니다.
사건 발생 전 수정 절차를 정의하세요: 누가 태그를 비활성화할 수 있는지, 플래그나 태그 매니저 게시가 필요한지, 롤백 방법, 검증 방법을 명시하세요. SIU는 사전 가동시간 최적화와 수정 조치입니다: 인벤토리, 예산, 사전 점검, 롤백 연습을 사용해 종속성 위험을 줄이세요. SIU는 공급업체 인프라를 제어하거나 가용성을 보장하거나 리뷰를 대체할 수 없습니다.
공급업체 없이도 무엇이 사용 가능한지, 무엇이 저하될 수 있는지, 폴백, 비활성화까지의 최대 지연을 명시하세요.
변경 기록에 전후 트레이스, 동의 결과, 차단된 공급업체 결과, 롤백 소유자를 첨부하세요.