서드 파티 태그를 최적화하기 전에 사이트에 이러한 스크립트가 여전히 필요한지 확인하세요.
서드 파티 스크립트 또는 '태그'가 사이트 성능 문제의 원인이 될 수 있으므로 최적화 대상이 될 수 있습니다. 하지만 추가한 태그를 최적화하기 전에 필요도 없는 태그는 최적화하지 않도록 해야 합니다. 이 도움말에서는 새 태그에 대한 요청을 평가하고 기존 태그를 관리 및 검토하는 방법을 설명합니다.
서드 파티 태그에 관해 논의할 때는 종종 성능 문제로 빠르게 넘어가면서 이러한 태그의 '핵심' 역할이 무엇인지 파악하지 못하는 경우가 많습니다. 다양하고 유용한 기능을 제공하여 웹을 보다 동적이고 상호 연결성이 높은 대화형으로 만듭니다. 하지만 서드 파티 태그는 조직 전체의 여러 팀에서 추가할 수 있으므로 시간이 지나면 이를 잊어버리는 경우가 많습니다. 사람들이 이동하거나 계약이 만료되거나 결과가 나오지만 팀은 스크립트를 삭제하기 위해 다시 연락하지 않습니다.
서드 파티 태그 스크립트 실행 또는 기술적 관점에서 지연되거나 지연 로드되거나 사전 연결될 수 있는 태그를 결정하기 전에 조직 관점에서 사이트/페이지에 추가할 태그를 관리할 수 있습니다. 많은 양의 서드 파티 태그로 인해 속도가 느려지는 웹사이트의 일반적인 주제는 웹사이트의 이 부분이 한 사람이나 팀이 소유하지 않아서 협력의 대상이라는 점입니다. 스테이징 환경에서 성능이 만족스러워 웹사이트를 최적화하는 것보다 더 실망스러운 일도 있습니다. 단지 추가된 태그로 인해 프로덕션에서 성능이 저하되는 속도만 가능합니다. 서드 파티 태그에 대한 '심사 프로세스'를 구현하면 이러한 태그에 대한 부서 간 책임과 책임을 생성하는 워크플로를 빌드하여 이를 방지할 수 있습니다.
서드 파티 태그를 검사하는 방법은 조직, 구조, 현재 프로세스에 따라 다릅니다. 태그를 추가하기 전에 태그를 분석하기 위한 게이트키퍼 역할을 하는 단일 팀을 보유하는 것만큼이나 기본적인 작업일 수 있습니다. 팀에게 태그 요청을 제출하기 위한 양식을 제공하는 등 격식 있는 고급 방식을 사용할 수도 있습니다. 웹사이트에 있어야 하는 이유, 웹사이트에 표시되어야 하는 기간, 비즈니스에 어떤 이점을 제공하는지에 관한 맥락을 요청할 수 있습니다.
태그 거버넌스 프로세스
어떤 방식으로든 조직 내에서 태그를 검사하는 경우 다음 단계를 태그 수명 주기의 일부로 고려해야 합니다.
규정 준수
페이지에 태그를 추가하기 전에 법무팀의 철저한 심사를 거쳐 태그가 적용되려면 모든 규정 준수 요건을 충족하는지 확인해야 합니다. 여기에는 태그가 EU 개인 정보 보호법 (GDPR) 및 캘리포니아 소비자 개인 정보 보호법 (CCPA)을 준수하는지 확인하는 것이 포함될 수 있습니다.
이는 매우 중요합니다. 이 단계에 의문이 있다면 성능 관점에서 태그를 평가하기 전에 문제를 해결해야 합니다.
필수
두 번째 단계는 페이지에 특정 태그가 필요한지 여부를 확인하는 것입니다. 다음 논의 사항을 고려하세요.
- 태그가 활발하게 사용되고 있나요? 그렇지 않은 경우 삭제할 수 있나요?
- 태그가 사이트 전체를 로드한다면 이것이 필요한가요? 예를 들어 Google에서 A/B 테스트 모음을 분석하고 현재 방문 페이지만 테스트하는 경우, 이 페이지 유형에만 태그를 삽입할 수 있나요?
- 여기에 로직을 추가할 수 있나요? 실시간 A/B 테스트가 있는지 감지할 수 있나요? 이 경우 태그 추가를 허용하고, 그렇지 않은 경우에는 태그가 없는지 확인합니다.
소유권
명확한 사람 또는 팀을 태그 소유자로 지정하면 태그를 사전에 추적하는 데 도움이 됩니다. 일반적으로 태그를 추가한 사용자가 누구인지 볼 수 있습니다. 태그 옆에 담당자를 배치하면 향후 검토 및 감사에서 태그가 필요한지 여부를 다시 검토할 수 있습니다.
목적
네 번째 단계는 태그가 페이지에 추가된 이유를 사람들이 이해하도록 하여 부서 간 책임과 책임을 형성하기 시작합니다. 따라서 각 태그가 웹사이트로 어떤 정보를 가져오는지, 그리고 태그가 사용되는 이유를 여러 직종의 팀원이 이해할 수 있어야 합니다. 예를 들어 태그가 사용자 세션 작업을 기록하여 맞춤설정을 허용하는 경우 모든 팀이 그 이유를 알고 있나요?
또한 상업적 vs 성능 저하에 관한 논의가 있었나요? 수익을 가져오기 때문에 '필수'로 간주되는 태그가 있는 경우 속도 회귀로 인해 손실될 수 있는 수익에 대한 분석이 있었나요?
리뷰
가장 중요한 다섯 번째 단계는 태그를 정기적으로 검토하는 것입니다. 이는 웹사이트 크기, 사이트에 있는 태그 수, 처리 시간 (예: 주별, 월별, 분기별)에 따라 달라집니다. 이는 다른 웹사이트 애셋 (JS, CSS, 이미지 등)을 최적화하는 것과 동일한 방식으로 취급해야 하며 정기적으로 사전에 확인해야 합니다. 검토에 실패하면 태그 관리자가 '팽창'하여 페이지 속도가 느려질 수 있습니다. 페이지에서 필요한 기능을 회귀시키지 않으면서 성능 기준에 맞게 되돌리는 것은 복잡한 작업일 수 있습니다.
심사 과정을 거쳐 특정 페이지의 필요에 따라 분류된 태그의 최종 목록이 생성됩니다. 이제 기술 최적화 접근 방식을 자세히 살펴볼 수 있습니다. 또한 성능 예산 내에서 이 최종 목록의 태그 수를 정의할 수 있는 기회가 열립니다. 이는 Lighthouse CI 내에서 모니터링하고 성능별 목표 설정에 통합할 수 있습니다. 예를 들면 다음과 같습니다.
Google에서 자체적으로 최적화된 JS와 함께 방문 페이지에 태그를 5개 미만으로 유지하면 코어 웹 바이탈에서 총 차단 시간 (TBT)이 '양호'할 수 있습니다.