태그 매니저 화면에서 태그를 하나 추가하는 데는 1분이 걸리지 않습니다. 승인도 배포도 필요 없고, 화면상으로는 목록에 줄 하나가 늘 뿐입니다. 추가가 이렇게 싼데 비용은 보이지 않는다는 것이 이 문제의 구조입니다.
스크립트 하나가 지나가는 단계
외부 스크립트는 우리 서버가 아닌 다른 도메인에서 옵니다. 그래서 먼저 그 도메인을 찾고 보안 연결을 맺는 과정이 필요합니다. 그다음 파일을 내려받습니다. 여기까지는 파일 크기와 회선의 문제입니다.
중요한 것은 그다음입니다. 브라우저는 내려받은 자바스크립트를 파싱하고 실행해야 하고, 이 작업은 메인 스레드에서 일어납니다. 메인 스레드는 화면을 그리고 터치와 클릭에 반응하는 바로 그 스레드입니다. 스크립트가 그 위에서 오래 도는 동안 페이지는 보이기는 하는데 눌러도 반응하지 않는 상태가 됩니다. 사용자가 가장 짜증을 내는 상태이고, 방문자는 이것을 “느리다” 가 아니라 “먹통이다” 로 기억합니다.
여기에 더해 많은 태그가 다른 스크립트를 다시 불러옵니다. 우리가 넣은 것은 한 줄인데 실제로 로드되는 파일은 여러 개인 경우가 흔하고, 그래서 태그 매니저의 목록만 봐서는 실제 부하를 알 수 없습니다.
쉽게 더해지고 어렵게 보이는 구조
마지막 줄이 특히 함정입니다. 개발 · 스테이징 환경에는 마케팅 태그가 없는 경우가 많아, 개발자가 보는 페이지와 고객이 보는 페이지가 다른 페이지입니다. “우리 쪽에서는 빠른데요” 라는 대답은 거짓말이 아니라 다른 화면을 본 것입니다.
비용을 직접 재는 방법
얼마나 손해인지 인용하지 말고 얼마인지 재세요. 절차는 단순합니다.
같은 랜딩 페이지 URL 을 같은 기기 프로파일로 3회 측정해 중앙값을 냅니다. 그다음 브라우저 개발자 도구의 요청 차단 기능으로 문제의 스크립트 도메인을 막고, 같은 조건으로 다시 3회 잽니다. 두 중앙값의 차이가 그 태그의 값입니다 — 우리 사이트에서, 우리 조건에서 나온 값입니다.
측정이 끝나면 선택지는 셋입니다. 없앤다(끝난 캠페인의 태그), 늦춘다(첫 화면 렌더 뒤 또는 사용자 상호작용 뒤 로드), 남긴다(비용을 알고 감수한다). 세 번째도 정당한 선택입니다 — 중요한 것은 모르고 내는 비용을 알고 내는 비용으로 바꾸는 것입니다.
스스로 점검할 도구는 무료 도구에 있고, 태그 정리와 캐시 · 서버 설정을 함께 정비하는 작업은 최적화 지원 사업에서 한 건으로 다룹니다.
다음 회차
페이지가 가벼워졌다면 이제 사람이 실제로 무언가를 해야 합니다. 다음 회차는 폼입니다 — 필드 하나하나가 자기 자리를 어떻게 증명하는지 다룹니다.