느린 웹사이트, 서버보다 서드파티 스크립트를 먼저 의심해야 한다

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

광고 캠페인을 시작한 날부터 랜딩 페이지가 느려졌는데 개발팀은 서버 사용률이 낮다고 말합니다. 이런 상황에서 서버를 증설하면 비용은 늘어도 체감 속도는 그대로일 수 있습니다. 문제의 범인은 분석 도구, 채팅 상담, 광고 픽셀처럼 브라우저에서 실행되는 서드파티 스크립트일 가능성이 큽니다.

웹사이트는 서버가 HTML을 빨리 보내는 것만으로 완성되지 않습니다. 방문자의 기기는 내려받은 코드의 해석과 실행, 화면 배치까지 처리해야 합니다. 디지털의 기본 개념처럼 정보가 수치와 신호로 변환되는 과정까지 생각하면, 웹 성능 역시 서버 응답 하나가 아니라 전달과 처리의 연쇄로 봐야 합니다.

서버가 빠른데 화면은 늦게 뜨는 이유

응답 시간과 체감 속도는 서로 다른 문제입니다

서버 로그에 200ms가 찍힌다고 해서 사용자가 0.2초 만에 페이지를 보는 것은 아닙니다. HTML을 받은 브라우저는 CSS와 자바스크립트를 추가로 요청하고, 코드를 분석한 뒤 화면을 그립니다. 이때 외부 도메인의 광고 태그나 행동 분석 SDK가 메인 스레드를 오래 점유하면 버튼이 보이면서도 눌리지 않거나 스크롤이 끊기는 현상이 나타납니다.

흔한 실수는 속도가 느리다는 신고를 받자마자 인스턴스 사양부터 올리는 것입니다. 먼저 서버 응답 지연과 브라우저 렌더링 지연을 분리해야 합니다. 개발자 도구의 네트워크 탭에서 최초 문서 응답은 빠른데 로딩 종료 시점이 길다면, 서버보다 프런트엔드 리소스와 외부 스크립트를 살펴볼 차례입니다.

• 최초 문서부터 늦음: 데이터베이스 조회, 서버리스 콜드 스타트, 캐시 누락을 점검합니다.
• 문서는 빠르지만 빈 화면이 지속됨: 렌더링을 막는 CSS와 동기식 자바스크립트를 확인합니다.
• 화면은 보이지만 조작이 늦음: 긴 자바스크립트 작업과 과도한 태그 실행을 의심합니다.
• 특정 사용자만 느림: 저사양 모바일 기기, 느린 통신망, 지역별 CDN 차이를 재현합니다.

성능 장애를 찾을 때는 서버가 몇 초 걸렸는지가 아니라, 사용자가 언제 내용을 보고 언제 버튼을 누를 수 있었는지를 기준으로 삼는 편이 정확합니다.

추측 대신 15분 만에 범인을 좁히는 순서

시크릿 창과 개발자 도구로 기준선을 만듭니다

첫 측정은 확장 프로그램의 영향을 줄이기 위해 시크릿 창에서 진행합니다. 개발자 도구를 열고 네트워크 속도를 모바일 환경에 가깝게 제한한 다음 새로고침하세요. 한 번의 좋은 결과만 믿지 말고 같은 페이지를 최소 3회 측정해 중앙값을 적어야 캐시와 일시적인 통신 변동에 덜 흔들립니다.

그다음 요청 목록을 도메인별로 묶어 봅니다. 자사 도메인이 아닌 요청 가운데 용량이 크거나 실행 시간이 긴 항목을 표시하고, 태그 관리자에서 해당 태그를 하나씩 비활성화해 다시 측정합니다. 브라우저의 성능 기록에서 긴 작업 직전에 등장한 스크립트 이름도 단서가 됩니다. 파일 용량이 작아도 반복 실행이나 DOM 탐색이 많으면 느릴 수 있다는 점을 놓치지 마세요.

1. 문제가 재현되는 URL, 기기, 브라우저, 네트워크 조건을 기록합니다.
2. 태그를 끄지 않은 상태에서 3회 측정해 기준값을 남깁니다.
3. 채팅, 히트맵, 광고, A/B 테스트 도구 순으로 한 종류씩 중지합니다.
4. 각 변경 뒤 같은 조건에서 3회 측정하고 화면 반응 차이를 비교합니다.
5. 가장 큰 개선을 만든 태그를 단독으로 다시 켜 원인을 재확인합니다.

증상과 원인을 대응시키면 조사 시간이 줄어듭니다

측정 화면에 생소한 용어가 많다면 IT 용어의 배경을 함께 확인하되, 도구가 보여 주는 종합 점수만 목표로 삼지는 마세요. 실제 전환 경로에서 버튼 반응과 입력 지연이 개선됐는지가 더 중요한 검증 기준입니다.

삭제하지 않고도 서드파티 스크립트를 가볍게 만드는 법

모든 태그를 첫 화면에 실행할 이유는 없습니다

광고 성과 측정이나 고객 상담 도구는 사업에 필요하므로 무조건 삭제하기 어렵습니다. 대신 실행 시점을 사용자 행동과 페이지 목적에 맞춰 나누면 됩니다. 예를 들어 상담 위젯은 첫 화면이 안정된 뒤 불러오고, 후기 페이지에서만 쓰는 히트맵은 결제 페이지에서 실행하지 않도록 범위를 제한할 수 있습니다.

async는 외부 파일을 병렬로 내려받아 준비되는 즉시 실행하고, defer는 HTML 해석이 끝난 뒤 문서 순서에 따라 실행합니다. 두 속성을 무작정 붙이면 의존성 순서가 깨질 수 있으므로 라이브러리와 이를 사용하는 코드의 관계부터 확인하세요. 태그 관리자 안에서 여러 태그가 같은 라이브러리를 중복으로 내려받는지도 살펴야 합니다.

• 경로 제한: 전환 태그는 완료 페이지, 지도 SDK는 매장 페이지에서만 실행합니다.
• 행동 기반 로딩: 채팅 버튼을 누르거나 해당 영역 근처로 스크롤했을 때 위젯을 호출합니다.
• 동의 이후 실행: 필수 기능이 아닌 분석·광고 태그는 이용자 선택과 연결합니다.
• 시간 제한: 외부 서비스가 응답하지 않아도 핵심 콘텐츠와 구매 버튼은 계속 작동하게 만듭니다.
• 대체 UI: 실시간 채팅이 실패하면 이메일 문의 링크나 전화번호를 즉시 표시합니다.

속도 개선 뒤 데이터 누락도 함께 검사합니다

태그를 지연시키면 페이지는 빨라져도 방문 직후 이탈한 사용자의 이벤트가 줄어들 수 있습니다. 전환 이벤트가 중복 전송되거나 동의 전 광고 쿠키가 생성되는 문제도 생길 수 있습니다. 따라서 배포 전후로 페이지 조회, 장바구니, 결제 완료 같은 핵심 이벤트의 건수와 순서를 별도 테스트해야 합니다.

마케팅팀에는 단순히 태그가 느리다고 통보하기보다, 태그를 끈 상태에서 반응 시간이 얼마나 줄었고 어떤 데이터가 영향을 받는지 보여 주세요. 그러면 삭제와 유지의 논쟁을 속도, 매출 기여도, 데이터 품질이라는 공통 기준으로 바꿀 수 있습니다.

외부 스크립트에는 반드시 세 가지를 물어야 합니다. 어느 페이지에서 필요한가, 언제 실행돼야 하는가, 실패해도 핵심 업무가 계속되는가입니다.

반나절 예산으로 성능 부채를 관리하는 운영 방식

무료 진단과 유료 작업의 경계를 숫자로 잡습니다

소규모 스타트업이라면 첫 진단에 큰 예산을 배정할 필요는 없습니다. 개발자 1명이 30분 동안 재현 조건을 만들고, 60분 동안 태그별 측정을 수행한 뒤, 30분 동안 마케팅 담당자와 유지 여부를 결정하는 식으로 시작할 수 있습니다. 단순 지연 로딩과 경로 제한은 보통 2~4시간의 구현·검증 묶음으로 계획하면 현실적입니다.

다만 결제, 로그인, 개인정보 동의와 연결된 스크립트는 수정 비용보다 장애 위험이 큽니다. 이 영역은 테스트 환경과 실제 환경에서 각각 확인하고, 배포 직후 30~60분 동안 오류율과 전환 이벤트를 관찰하세요. 외주를 맡긴다면 작업 시간만 견적받지 말고 측정 보고서, 이벤트 검증, 원복 방법까지 산출물에 넣어야 비용 비교가 가능합니다.

1. 매주 15분: 새로 추가된 외부 도메인과 태그 수를 확인합니다.
2. 매월 1시간: 주요 랜딩 페이지 3개를 모바일 조건에서 각 3회 측정합니다.
3. 분기별 2~4시간: 사용하지 않는 태그를 삭제하고 담당자와 만료일을 갱신합니다.
4. 배포당 30분: 로그인, 문의, 결제 등 핵심 경로를 직접 통과하며 이벤트를 확인합니다.

태그 하나에도 담당자와 만료일을 붙이세요

성능 문제는 한 번 고친다고 끝나지 않습니다. 캠페인이 바뀔 때마다 새로운 픽셀과 실험 도구가 쌓이기 때문입니다. 태그 목록에 소유자, 사용 목적, 적용 URL, 추가 날짜, 삭제 예정일을 기록하면 담당자가 퇴사한 뒤에도 정리할 근거가 남습니다.

운영 기준은 복잡할 필요가 없습니다. 초기 조사 2시간, 수정과 검증 최대 4시간, 월간 점검 1시간을 기본 단위로 잡고, 외부 스크립트 수는 핵심 페이지별 10개 이하를 첫 관리 목표로 삼아 보세요. 숫자를 초과하면 서버 증설비를 결제하기 전에 태그의 사업 가치와 실행 시점을 다시 검토하는 것이 비용과 시간을 함께 아끼는 출발점입니다.