서버 측 Google Tag Manager를 활용한 웹사이트 페이지 속도 개선

서버 측 Google Tag Manager의 첫 번째 버전이 출시되었을 때, 마케터와 웹 개발자가 주목한 핵심 이점 중 하나는 웹사이트 페이지 속도 최적화였습니다. 추적 스크립트를 더 이상 하드코딩하지 않고 Google Tag Manager를 통해 추가할 수 있게 되면서 이러한 개선이 가능해질 것으로 기대되었습니다. 

이 글에서는 태그를 GTM 웹 컨테이너에서 서버 컨테이너로 이전할 때 GTM PageSpeed에 어떤 영향을 미치는지, 실제 데이터는 어떻게 나타나는지, 설정 방식에 따라 어떤 접근법이 더 적합한지 보여드립니다.

일찍이 2016년에 Google은 이상적인 웹사이트 로딩 시간이 3초라고 밝혔습니다. 동시에 모바일 페이지가 완전히 로드되는 데는 평균 22초가 소요됩니다. 

오늘날 사람들은 데스크톱 기기보다 휴대전화를 더 많이 사용하며, 스마트폰은 전체 인터넷 트래픽의 50% 이상을 차지합니다. 하지만 Google에 따르면 휴대폰 전환율은 데스크톱보다 낮습니다. 그렇기 때문에 성과 기준을 충족하는 데 있어 웹사이트 로딩 속도가 필수적인 역할을 합니다.

사용자가 빠른 사이트 경험을 기대한다는 것은 잘 알려진 사실입니다. 랜딩 페이지가 너무 느리면 사용자는 페이지를 닫거나 장바구니를 포기하고 경쟁사 사이트로 이동합니다. 모바일 중심의 오늘날, 빠르게 로드되는 사이트를 구축하는 것은 매우 중요합니다. 사용자는 어떤 블로그든 빠르게 열어 글을 읽고, 새 옷을 사고, 호텔 리뷰를 확인하는 등의 작업을 신속하게 할 수 있기를 원합니다.

Amazon의 연구에 따르면 페이지 응답 속도가 1초 지연될 때마다 전환율이 1% 감소합니다. 이는 연간 16억 달러의 매출 손실에 해당합니다.

보시다시피 무거운 페이지가 로드되기를 기다리게 만드는 것은 어떤 기업에게든 막대한 비용을 초래할 수 있습니다. 

Google Tag Manager를 통해 추가하는 모든 태그는 사용자의 브라우저에서 JavaScript로 실행됩니다. 각 스크립트는 페이지가 로드되기 전이나 후에 다운로드, 파싱 및 실행되어야 하므로 시간이 걸립니다.

모든 GTM 설정이 동일하게 작동하는 것은 아니며, 여기서 대부분의 혼란이 발생합니다. 컨테이너가 웹으로 구현되는지 서버로 구현되는지에 따라 GTM이 브라우저에 부하를 더할지 아니면 줄여줄지가 결정됩니다. 웹 컨테이너에서는 추가하는 모든 태그(애널리틱스, 광고 픽셀, 채팅 위젯, 히트맵)가 방문자의 브라우저에서 직접 로드되고 실행되는 스크립트입니다.

각 스크립트는 메인 스레드, 대역폭, 렌더링 시간과 같은 동일한 한정된 자원을 두고 경쟁합니다. 태그를 많이 쌓을수록 GTM 자체는 가벼운 컨테이너임에도 불구하고 Google Tag Manager가 성능에 미치는 영향은 복합적으로 커집니다.

서버 측 GTM은 태그가 실행되는 위치를 바꿉니다. 클라이언트 측에서 수십 개의 서드파티 스크립트가 실행되는 대신, 서버 컨테이너가 데이터를 수신하여 클라우드에서 마케팅 및 애널리틱스 플랫폼으로 전달합니다. 브라우저는 수십 개의 서로 다른 서드파티 도메인이 아닌 자체 서버와만 통신하면 됩니다. 이것이 바로 웹 설정과 서버 설정 간의 Google Tag Manager PageSpeed 격차가 크게 벌어지는 핵심 이유입니다.

2020년 Google은 Google Tag Manager 및 Tag Manager 360용 서버 컨테이너를 출시했습니다. 이를 통해 광고주는 사이트의 서드파티 태그를 클라우드 서버에 호스팅된 새로운 서버 컨테이너로 이전할 수 있습니다. 이렇게 하면 웹사이트 로딩 속도가 빨라지고 추적이 더 정확해지며 데이터의 보안이 강화됩니다. 태그를 서버 컨테이너로 이동하면 다음과 같은 Google PageSpeed 오류를 해결하는 데 도움이 됩니다: "서드파티 코드의 영향 줄이기 — 서드파티 코드가 메인 스레드를 550ms 동안 차단했습니다".

웹 컨테이너에서 서버 컨테이너로 태그를 이전하면 태그가 브라우저 내부가 아닌 서버 컨테이너에서 직접 로드됩니다. 이렇게 하면 페이지 로딩이 빨라져 사용자 경험에 긍정적인 영향을 미칩니다. 이처럼 더 빠른 페이지 로딩 속도, 고객 데이터에 대한 강화된 보안, 그리고 더 많은 데이터 관리 도구를 확보할 수 있습니다. 이는 추적 정확도를 저하시키지 않으면서 서버 측 Google Tag Manager가 웹사이트 성능을 어떻게 향상시킬 수 있는지를 보여주는 가장 명확한 사례 중 하나입니다.

서버 컨테이너의 태그는 서버로 전송된 정보에만 접근할 수 있습니다. 사용자가 사이트에 입력한 다른 정보에는 접근할 수 없습니다. 그리고 이러한 태그는 자체 서버 컨테이너에 배치되므로, 태그가 어떤 정보를 수집하고 그 정보가 어디로 전송되는지 명확히 파악할 수 있습니다.

모든 태그가 페이지 속도에 동일한 영향을 미치는 것은 아니며, 이는 마이그레이션이 모든 성능 문제를 해결해 줄 것이라고 가정하기 전에 반드시 염두에 두어야 할 중요한 차이점입니다. 가벼운 애널리틱스 스니펫과 무거운 리타겟팅 광고 픽셀은 둘 다 똑같은 '단순한 태그'일지라도 로딩 시간에 미치는 영향은 전혀 다릅니다. 가장 큰 영향을 미치는 태그는 대체로 네트워크 요청을 여러 번 발생시키거나, 추가 스크립트를 로드하거나, 특정 이벤트가 아닌 모든 페이지 로드 시 실행되는 태그입니다.

이를 직접 확인할 수 있는 가장 확실한 방법은 마이그레이션 전후의 Google Tag Manager PageSpeed Insights 보고서를 확인하고, 결과의 서드파티 코드 섹션을 직접 비교해 보는 것입니다.

이번 실험에서는 데모 웹사이트를 사용하여 GTM 웹 컨테이너를 통해 태그를 추가했을 때와 GTM 서버 컨테이너를 통해 추가했을 때의 Google PageSpeed 결과를 비교했습니다. 모든 태그가 Google PageSpeed에 동일한 영향을 미치는 것은 아닙니다. 이 실험을 진행하면서 클라이언트가 가장 많이 사용하는 태그이자 서버 컨테이너로 이전할 수 있는 태그인 Facebook, Bing, Active Campaign을 선정했습니다.

GTM 서버 컨테이너에는 GA4용 기본 태그가 포함되어 있습니다. GTM 서버 측 컨테이너를 사용하여 GA4 추적을 설정하는 방법에서 자세한 정보를 확인할 수 있습니다. 또한 Facebook 픽셀을 서버 환경으로 이전하는 데 도움이 되는 맞춤 템플릿도 제작했습니다. 

다음은 Google 속도 테스트 결과입니다. Google 페이지 속도 점수는 모바일에서 95점, 데스크톱에서 100점을 기록했습니다. 

저희는 서버 컨테이너에 GA4, Facebook(기본 및 전환 추적), Hubspot 및 Klaviyo 태그를 설치했습니다.

픽셀을 웹 컨테이너로 옮기자 Google PageSpeed 결과가 56점으로 떨어졌습니다. 

태그를 Google Tag Manager 서버 컨테이너로 이전하면 사이트 속도가 향상됩니다. 그 영향의 정도는 사용하는 태그에 따라 달라집니다. 본 테스트에서는 고객들이 가장 많이 사용하는 태그(GA4, Facebook 및 Active Campaign )를 서버 측으로 이전했을 때 명확하고 측정 가능한 차이가 나타났습니다.