Addy Osmani

서드 파티 리소스 (예: 삽입, 스크립트)는 오늘날 웹 전반에서 매우 많이 사용됩니다. 소셜 미디어, 동영상, 분석, 실시간 채팅, 광고, A/B 테스트, 맞춤설정 등을 삽입할 수 있는 즉시 사용 가능한 솔루션을 제공합니다. 서드 파티 삽입은 최신 웹사이트의 필수적인 부분으로, 사이트 소유자는 표준 기능이지만 중요한 기능은 외부 제공업체에 맡기지 않고 핵심 기능에 집중할 수 있습니다.

웹페이지에서 자사와 타사가 모두 조화롭게 작동하면 페이지에서 우수한 사용자 환경을 제공할 수 있습니다. 하지만 이를 위해서는 엔지니어링팀과 비즈니스팀 모두의 상당한 노력이 필요하고 간과되는 경우가 많아 웹페이지 성능이 저하되고 코어 웹 바이탈과 같은 사용자 중심 측정항목에 부정적인 영향을 미치게 됩니다. 이는 양측 모두에게 해가 되고 비즈니스에서 기회를 놓칠 수 있습니다. 더 개선할 수 있는 방법이 있을까요?

Google은 서드 파티 스크립트 및 리소스를 사용하는 웹사이트의 성능이나 사용자 환경에 대한 성능 저하를 최소화하면서 원하는 비즈니스 가치를 제공하는 웹의 미래 비전을 갖고 있습니다. 이렇게 하면 이상적으로 사용자가 더 빠른 페이지 로드를 경험할 수 있습니다.

지난 한 해 동안 Google에서는 사이트 소유자에게 비즈니스 가치를 떨어뜨리지 않고도 서드 파티 스크립트의 해로운 영향으로부터 사용자 환경을 보호할 수 있는 다양한 가능성을 고려하고 논의 및 실험해 왔습니다.

이 게시물을 통해 몇 가지 실험에 대한 정보를 공유하고자 합니다. 이 과정이 사용자 에이전트, 비즈니스, 서드 파티 제공업체 간의 투명성과 가시성을 높이고 더 빠른 웹을 향한 길을 닦는 과정의 시작점이 되기를 바랍니다.

서드 파티에 대한 심층 분석

서드 파티는 사이트 외부의 제공업체가 제공하는 리소스입니다. 사이트 소유자가 직접 제어할 수 있는 것은 아니며 사이트 소유자의 승인 하에 제공됩니다. 서드 파티 리소스는 다음과 같습니다.

• 기본 사이트 출처와 다른 공유 및 공개 출처에서 호스팅됨
• 작성했거나 개별 사이트 소유자의 영향을 받지 않았습니다.
• 다양한 사이트에서 널리 사용됩니다.

광고를 통한 수익 창출에서 더 나은 마케팅 기회(소셜 미디어 삽입) 제공에 이르기까지 서드 파티는 다양한 비즈니스 목표를 제공합니다. 서드 파티의 일반적인 카테고리는 다음과 같습니다.

출처: 카테고리별 서드 파티.

이러한 서드 파티 스크립트 및 라이브러리를 통해 웹 개발자는 시간을 낭비하지 않고 검증된 솔루션을 활용하여 표준 기능을 구현할 수 있습니다. 따라서 서드 파티는 개발 시간을 줄이고 비즈니스가 제품을 더 빠르게 출시하거나 업그레이드할 수 있도록 지원합니다. 따라서 데스크톱 및 모바일의 모든 웹사이트 중 94% 이상이 서드 파티를 이용하는 것은 놀라운 일이 아닙니다.

서드 파티는 실적에 어떤 영향을 미치나요?

이상적으로는 서드 파티 개발자가 제공하는 특정 기능에 대한 주제별 전문가입니다. 대부분의 인기 있는 서드 파티는 여러 차례 반복 작업을 거쳤으며, 비즈니스 목표에 맞게 코드를 최적화할 수 있습니다. 비즈니스 목표에 맞게 코드를 최적화할 수도 있고 코드를 사용하는 페이지의 성능이 포함될 수도 있습니다. 하지만 가장 최적화된 서드 파티가 있더라도 실적에 영향을 미친다는 점은 알고 있습니다. 이러한 상황이 발생하는 주된 이유는 다음과 같습니다.

1. 크기 및 스크립트 실행 비용: 서드 파티는 '단지' <script> 또는 <iframe> 요소를 페이지에 삽입하여 상당한 기능을 제공하려고 하는 경우가 많습니다. 이러한 요소는 크기가 크고 다운로드와 실행에 더 많은 시간이 소요되는 스크립트 및 리소스를 가져옵니다. 자바스크립트가 너무 많으면 기본 스레드를 더 오래 사용하고, 렌더링이 차단되며, 사용자 상호작용이 지연됩니다. 주요 서드 파티 업체 중 일부는 분석된 사이트의 50% 이상에서 기본 스레드를 42ms에서 1.6초로 차단하는 것으로 알려져 있습니다. 기본 스레드가 차단되면 사이트의 성능 점수에 영향을 미치는 측정항목 중 하나인 총 차단 시간 (TBT)이 높아집니다. 또한 사용자 상호작용에 대한 응답을 지연시키고 웹사이트의 응답성을 측정하는 데 사용되는 Interaction to Next Paint (INP) 측정항목의 성능을 저하시킵니다. 따라서 스크립트 실행 비용은 성능에 상당한 영향을 미칩니다.

2. 수: 평균적으로 웹사이트는 모바일과 웹에서 약 21개의 서드 파티를 사용합니다. 서드 파티 태그는 기술/개발팀에서 직접 관리하지 않는 태그 관리 도구에 의해 추가되는 경우가 많습니다. 필요하지 않은 태그는 다른 팀에서 검토 과정 없이 추가할 수 있으며 삭제되지 않습니다. 사용자 환경, 페이지 크기 또는 CPU 사용률에 상당한 영향을 미칠 수 있습니다. 거버넌스 프로세스를 확립하면 이러한 상황을 해결하고 개발자는 각 제공업체의 영향을 감사할 수 있습니다. 개발자가 성능에 미치는 영향, 이점, 비교를 위한 절충점이 포함된 특정 기능을 제공하는 모든 서드 파티에 사용할 수 있는 데이터를 준비해 두었다면 도움이 될 것입니다. 팀이 직면한 또 다른 과제는 많은 사이트에서 서드 파티 태그가 프로덕션에서만 실행되고 개발 환경에서는 실행되지 않기 때문에 개발자가 테스트하기가 더 어렵다는 것입니다.

3. 네트워크: 서드 파티는 서로 다른 출처에서 호스팅되므로 브라우저에서 콘텐츠를 다운로드하려면 더 많은 연결을 설정해야 합니다. 서로 다른 연결에서는 우선순위에 따라 다운로드를 조정할 수 없으므로 네트워크 경합이 발생합니다. 따라서 적절한 최적화가 고려되지 않으면 페이지 로드가 더 지연될 수 있습니다.

4. 시퀀싱: 서드 파티가 기본 스레드를 차단하고 더 중요한 리소스를 확보하기 위해 대역폭과 경쟁할 수 있습니다. 하지만 경우에 따라 페이지를 렌더링하는 데 필요한 중요한 리소스는 서드 파티입니다. 웹사이트가 여러 서드 파티를 사용하는 경우 퍼스트 파티 및 서드 파티 리소스의 최적의 시퀀싱이 필요합니다. 웹 개발자는 시퀀싱을 최적화하는 데 사용할 수 있는 다양한 옵션을 알고 있어야 합니다.

위와 같은 이유로 서드 파티는 Core Web Vitals의 일부 또는 전체에 영향을 미칠 수 있습니다. 대다수의 서드 파티는 최대 콘텐츠 렌더링 시간 (LCP) 및 최초 입력 반응 시간 (FID)에 부정적인 영향을 미칩니다. YouTube 삽입은 모바일 웹사이트의 10% 에서 4.5초, 연구 대상 웹사이트의 50% 에서 최소 1.6초 동안 기본 스레드를 차단합니다. 연결 속도가 느린 상태에서 이러한 스크립트 20개가 포함된 페이지를 방문하는 사용자가 불만을 느낀다고 상상해 보세요. thirdpartyweb.today의 다음 시각화는 현재 실적에 가장 큰 영향을 미치는 타사를 보여줍니다.

"상위 약 400만 개의 사이트 중 약 2,700개의 출처가 모든 스크립트 실행 시간의 약 57% 를 차지하며, 상위 50개 항목이 이미 약 47%를 차지하고 있습니다." - 서드 파티 웹

코어 웹 바이탈에서 측정한 바에 따르면, 빠르게 렌더링되고 합리적인 시간 내에 상호작용이 가능한 페이지는 우수한 사용자 경험을 제공하는 데 필수적입니다. 좋은 UX는 종종 웹사이트에서 좋은 비즈니스로 이어지며, 이는 서드 파티 이용자에게 좋은 비즈니스로 해석될 수 있습니다. 서드 파티의 영향을 줄이기 위해 협력하면 체인에 속한 모든 사람에게 이득이 될 수 있습니다.

Google은 Google 태그 관리자, YouTube 삽입, ReCaptcha 등 일반적으로 사용되는 여러 서드 파티 스크립트를 제공한다는 점을 잘 알고 있습니다. Google에서는 많은 스크립트가 코어 웹 바이탈의 성능에 보다 가벼운 영향을 미칠 수 있음을 인지하고 있으며, 가능한 경우 이러한 영향을 개선할 방법을 모색하기 위해 노력하고 있습니다.

Chrome이 어떻게 도움이 되나요?

서드 파티 리소스의 실적이 저조하면 생태계의 기본 역학을 크게 바꿔야 하는 개발자에게는 많은 어려움이 있습니다. Chrome은 다음과 같은 성과를 달성하기 위해 이 영역을 탐색하려고 합니다.

1. 사용자 경험이나 비즈니스 성과를 떨어뜨리지 않으면서 웹에서 서드 파티 리소스를 로드하는 더 나은 방법을 찾아보세요.

   파트너, 비즈니스, 제3자, 개발자와 협력하지 않으면 이러한 노력을 크게 진척할 수 없음을 잘 알고 있습니다. 가능성에 대해 논의하고 공개 설명 및 사양을 통해 아이디어를 교환할 수 있는 열린 장을 만들고자 합니다. 개발자는 의견을 제공하고 이러한 제안 중 많은 사항이 미치는 영향을 테스트할 시간을 갖게 됩니다.

2. 서드 파티 스크립트 사용자는 도구 및 현장의 비용에 대한 기여 분석을 개선하고, 사용 경로를 명확하고 잘 정리된 경로로 사용하고, 작성 시간 동안 더 나은 인센티브를 제공하여 기본적으로 최적의 상태로 유지할 수 있도록 지원합니다.

   Google은 사용자 에이전트, 프레임워크, 서드 파티 스크립트와 같은 모든 레이어를 개선하여 서드 파티가 성능에 미치는 영향을 줄이고자 합니다. 또한 Google은 사이트 소유자가 삽입된 각 스크립트에 대한 권장사항을 채택할 수 있도록 충분한 정보를 제공하고, 가능한 경우 더 빠른 대안도 제공하고자 합니다.

제안된 접근 방식

Google은 이러한 결과를 달성하기 위한 3가지 접근 방식을 제안합니다.

1. **RUM 및 Chrome의 개발자 도구를 통해 개발자가 서드 파티에 따른 영향을 더 자세히 파악할 수 있도록 합니다.**

   RUM은 웹 성능 모니터링 API를 통해 사용할 수 있는 실제 사용자 측정항목 데이터 (필드 데이터라고도 함)를 나타냅니다. Chrome의 개발자 도구에는 Lighthouse, Chrome DevTools, Chrome 사용자 환경 보고서가 포함됩니다. Google에서는 사이트 개발자가 모든 페이지에서 사용하는 모든 서드 파티의 영향을 이해할 수 있도록 사용 가능한 API 및 도구를 개선할 것을 제안합니다. 또한 도구를 통해 영향을 완화하기 위해 취할 수 있는 조치 (예: 퍼사드 지연 또는 퍼사드 사용)에 관해 알리고 절충안이 있는 다른 잠재적 솔루션 (다른 서드 파티 또는 DIY)도 살펴봅니다. Web Performance Monitoring API의 경우 사용자의 개인 정보 보호와 보안을 손상시키지 않으면서 교차 출처 리소스의 적용 범위를 확장할 수 있는 방법을 모색하고 있습니다.

2. **기업에 제3자 리소스를 효율적으로 로드할 수 있는 적절한 방법을 제공하세요.**

   Google에서는 사용자에게 더 나은 로드 경험을 제공하기 위해 자사 및 타사 리소스가 로드되는 방식을 더 지능적으로 절충하도록 브라우저가 보다 지능적으로 절충하도록 장려하는 새로운 표준을 제안하고자 합니다. 후반부에서는 서드 파티 삽입을 기본적으로 지연 로드하거나, 사용자가 가장 관심을 가질 만한 초기 콘텐츠에는 그다지 중요하지 않은 서드 파티 리소스에 다른 리소스 우선순위를 적용하는 등의 몇 가지 제안을 살펴보겠습니다. 이들은 이 공간에서 평가 중인 일부 아이디어에 불과하며 웹 성능 전문가 및 더 넓은 커뮤니티와 협력하여 이 작업을 발전시킬 수 있기를 바랍니다.

   이와 비슷하게 Google은 JavaScript 프레임워크 및 콘텐츠 관리 시스템 (CMS)에서 이러한 문제를 해결할 수 있기를 바랍니다. Aurora 및 WordPress Performance Team과 같은 프로젝트를 통해 알려진 로드 문제를 해결하는 기본 제공 기본값의 중요성을 배웠습니다. 프레임워크와 CMS에 기본 적용된 기본 원칙이 기업을 안전한 길로 안내합니다. 휴리스틱을 적용하여 페이지 로드와 CWV를 최적화할 수 있는 힌트로 사용자 에이전트 (예: Chrome)에도 유용할 수 있습니다. 이러한 힌트는 사용자 에이전트가 페이지 수명 주기에서 특정 서드 파티가 언제, 어떻게 로드되어야 하는지 결정하는 데 도움이 됩니다. 예를 들어 Next.js 스크립트 구성요소에는 페이지가 대화형이 된 후 서드 파티 스크립트를 로드하는 기본 기본 기능이 있습니다.

3. **투명성 개선을 통해 실적에 미치는 영향을 줄일 수 있도록 서드 파티 인센티브를 제공하세요.**

   현재 서드 파티 개발자는 스크립트가 전체 사이트에 미치는 영향을 파악하는 데 필요한 가시성이 부족합니다. Google은 이 문제를 해결하고 이러한 제공업체가 영향을 분석하고 동일한 가치를 제공하는 시장 내 다른 제품과 비교할 수 있는 도구를 제공할 계획입니다. 또한 데이터를 사용하여 영향을 미치는 원인을 진단하고 업스트림에서 완화할 수 있도록 돕고자 합니다. Google이 성공하기 위해서는 Google이 작성한 업체를 포함하여 모든 제3자가 이를 언급해야 합니다.

도전과제

이러한 규모의 노력에는 어려움이 따릅니다. 우리가 고려해야 할 몇 가지 주요 과제는 다음과 같습니다.

• 제3자는 광고, 분석, 태그 관리, 유틸리티 등과 관련된 공통적인 문제입니다. 영역마다 고유한 요구사항과 장단점을 고려해야 합니다. 예를 들면 다음과 같습니다.
  • 광고 로드를 최적화하는 결정은 수익과 사용자 환경 간의 절충에 따라 달라집니다. 너무 초기에 가치 있는 콘텐츠를 차단하고 너무 늦으면 사용자가 보지 못하게 될 수 있습니다.
  • 애널리틱스 스크립트는 페이지 크기를 늘리되 비즈니스에 대한 사용자 액션에 대한 중요한 데이터를 제공합니다.

Google은 다양한 카테고리의 제3자와 협력하고, 관련된 미묘한 차이를 이해하고, 절충점을 해결하고, 모두에게 효과적인 인센티브를 개발하기를 희망합니다. 전략이 효과를 발휘하기 위해서는 모든 분야의 법인과 개별적으로 협력해야 한다는 것을 알고 있습니다. 여기에는 Google 태그 관리자, Google Ads, YouTube와 같은 내부 파트너가 포함됩니다.

1. Google에서는 사이트 개발자와 서드 파티 개발자 모두에게 더욱 상세한 저작자를 제공하고자 합니다. 이를 위해서는 영향을 측정하는 데 가장 관련성이 높은 데이터를 식별하고, 데이터의 정확성과 세부 기여도를 분석하고, 올바른 방향을 제시하기 위해 성실한 노력을 기울여야 합니다. 따라서 경쟁사와 비교하여 타사의 실적을 계산하는 방법은 궁극적으로 모두에게 투명해야 합니다.

2. 퍼스트 파티 리소스와 서드 파티 리소스의 로드 우선순위를 지정하기 위해 적절한 균형을 유지하는 데 도움이 되는 최적화를 적용할 수 있도록 Chrome을 개선할 것을 제안합니다. 중요한 변경사항은 모든 브라우저에서 표준으로 사용할 수 있게 되지만 시간이 걸립니다. 예를 들어 <img> 및 <iframe> 요소의 loading 속성은 2019년부터 Chrome/Edge에서 사용할 수 있었지만 2022년에 Safari에서만 사용할 수 있게 되었습니다. 기능이 표준화될 때까지 서드 파티 리소스 사용자는 다른 브라우저에도 최적화되었는지 확인해야 합니다. 해당하는 경우 가이드에서 이를 강조하여 도움을 드리도록 하겠습니다.

3. 이 프로젝트를 실행하려면 특정 요구사항을 이해하는 데 도움이 될 뿐만 아니라 실험 솔루션을 대규모로 테스트하고, 필요에 따라 피드백을 제공하고, 반복하고, 즉흥적으로 진행하기 위해 파트너 및 개발자와 소통해야 합니다. 이러한 변경을 계획하여 테스트와 평가에 합당한 기간을 감안해야 합니다.

초기 표준 제안

Google은 서드 파티 로드 프로세스를 최적화하는 데 사용할 수 있는 기능을 개발하기 위해 몇 가지 초기 실험을 수행했습니다. 관찰된 결과에 만족하며 현재 이러한 두 가지 기능에 대해 논의할 수 있습니다.

LazyEmbeds

이전에는 Chrome에서 라이트 모드 사용자를 위해 오프스크린 <img> 및 <iframe> 요소를 지연 로드했습니다. 이 기능은 서드 파티 삽입으로 확인된 <iframe> 요소의 로드를 지연하기 위해 모든 사용자에게로 확장될 수 있으며, 사용자가 이 요소 근처로 스크롤할 때까지 가능합니다. 이렇게 하면 페이지의 다른 부분 로드 속도를 높이고, Core Web Vitals를 개선하고, 메모리 사용량을 줄이고, 데이터를 절약할 수 있습니다.

다음은 LazyEmbeds를 사용하여 페이지에서 YouTube 동영상을 지연 로드하는 데모입니다. 일반적으로 YouTube 동영상 1개를 삽입하면 페이지에 500~600KB의 자바스크립트가 추가됩니다. 우리는 LazyEmbeds를 사용하여 14 개의 이러한 동영상 삽입으로 블로그 게시물을 최적화하려고 했습니다. 그 결과 페이지 로드 시간과 데이터 절약 측면에서 좋은 성과를 보였습니다.

이 작업에 관해 자세히 알아보려면 설명 및 blink-dev의 intent-to-experiment 대화목록과 실험 확장 프로그램을 참고하세요.

타겟팅된 서드 파티 제한

타사 스크립트는 전체적인 감독 프로세스 없이 다양한 팀에서 추가하는 경우가 많습니다. The Telegraph의 엔지니어링 팀은 "모든 사람이 단체의 수익을 얻을 페이지에 '해당 태그'를 사용하고 싶어한다"고 밝혔습니다. 이로 인해 성능 영향을 관리하는 부담이 지속적으로 증가할 수 있습니다.

타겟팅된 서드 파티 스크립트 제한은 매우 특정한 종류의 서드 파티를 제한하여 영향을 완화할 것을 제안합니다. 이렇게 하면 브라우저에서 주요 콘텐츠 및 중요한 서드 파티를 조기에 로드할 수 있으며, 나중에 안전하게 로드할 수 있는 서드 파티는 제한됩니다.

RUM API 개선

또한 서드 파티 실적 평가와 관련된 정보를 포함하도록 RUM API를 향상하는 방안을 고려하고 있습니다. 개선사항에는 다음이 포함됩니다.

1. <iframe> 보고: Google은 교차 프레임 보고에 Performance Timeline API를 활용할 수 있는 솔루션을 개발 중입니다. 이렇게 하면 최상위 페이지 작성자가 페이지에 삽입된 협력 중인 서드 파티 iframe의 실적 데이터를 검사할 수 있습니다.

2. 긴 작업 속성: RUM의 Long Tasks API는 사이트 소유자가 기본 스레드를 장기간 묶고 상호작용을 지연하는 장기 작업을 식별하는 데 도움이 됩니다.

추가 업데이트

Google은 아직 이러한 아이디어를 많이 실험하고 있으며 진행하면서 변경사항을 적용할 수 있도록 GitHub 설명 및 사양 초안을 게시할 수 있기를 바랍니다. Google과 협력하거나 의견을 남기려는 제3자 및 사이트 소유자는 이를 통해 토론에 기여할 수 있습니다. 또한 서드 파티는 코어 웹 바이탈/INP 데이터에 부정적인 영향을 미치지 않도록 코어 웹 바이탈 및 INP 측정항목을 최적화하는 데 집중할 수도 있습니다. 현재 업데이트를 적극적으로 찾는 분들은 blink-dev 그룹의 게시물을 참고하세요.

이 문제를 더 깊이 탐구하고 알게 된 내용에 대해 커뮤니티와 소통하기를 기대합니다.

리이나 소호니 카스처, 제레미 와그너, 질베르토 코치, 켄지 바휴, 코우헤이 우에노, 켄타로 하라, 알렉스 N. 호세, 멜리사 미첼, 요아브 바이스, 순야 시시도, 미노루 치카무네가 의견과 기여를 해주셨습니다.