지도, 폰트, 통계, 채팅, 광고 스크립트 등 외부 서비스는 분명 편리하다. 하지만 그 편리함 뒤에는 숨겨진 비용이 있다. 바로 로딩 시간이다. 외부 스크립트를 하나씩 추가할 때마다, 방문자의 브라우저는 내 서버가 아닌 제3자의 서버에 별도 요청을 보내야 한다. 그리고 그 서버가 느리거나, 일시적으로 응답이 지연되거나, 심지어 잠깐이라도 다운되는 순간—내 사이트 전체가 그 시간만큼 기다리게 된다.

-외부 스크립트가 속도를 늦추는 구조적 이유

웹 페이지가 로딩되는 과정을 생각해보자. 브라우저는 HTML을 위에서부터 아래로 읽으며 필요한 리소스를 요청한다. 이때 외부 스크립트 태그를 만나면, 기본적으로 해당 파일을 완전히 내려받을 때까지 페이지 렌더링을 잠시 멈춘다. 이것을 “렌더 블로킹(render blocking)”이라고 부른다.

더 나아가, 외부 스크립트는 단순히 파일 하나를 불러오는 것으로 끝나지 않는 경우도 많다. 구글 폰트를 예로 들면, 페이지가 구글 서버에 연결 요청을 보내고 → DNS를 조회하고 → TCP 연결을 맺고 → 폰트 CSS를 받아오고 → 그 안에 명시된 실제 폰트 파일을 다시 요청하는 과정이 순차적으로 일어난다. 이 전체 왕복에 드는 시간이 수백 밀리초에 달할 수 있다.

– 실제 영향은 얼마나 될까?

구글 폰트 하나, 채팅 스크립트 하나가 페이지 로딩 시간을 0.5초~1초씩 늘리는 경우는 흔하다. 여기에 광고 스크립트, 히트맵 툴, SNS 공유 버튼 스크립트, 인터콤 같은 고객 지원 위젯까지 더해지면 외부 스크립트만으로도 2~3초의 로딩 지연이 발생하는 것은 어렵지 않다.

실제로 PageSpeed Insights나 WebPageTest로 사이트를 분석해보면, “서드파티 코드의 영향 줄이기”라는 항목이 빈번하게 경고로 표시되는 이유가 여기 있다.

– 모바일 환경에서는 영향이 훨씬 크다

데스크톱 환경에서는 크게 느껴지지 않던 외부 스크립트 지연이, 모바일에서는 체감이 완전히 달라진다. 이유는 두 가지다.

첫째, 네트워크 환경이 불안정하다. LTE나 5G라도 건물 안, 지하철 내부, 혼잡한 공공장소에서는 신호가 약해진다. 이런 환경에서 외부 서버와의 연결이 한 번이라도 지연되면, 그 영향이 모든 관련 요소에 파급된다.

둘째, 스마트폰의 CPU 성능이 데스크톱보다 낮다. 자바스크립트를 파싱하고 실행하는 데 드는 시간 자체가 더 길기 때문에, 외부 스크립트 하나하나가 체감 속도에 더 직접적으로 영향을 미친다.

구글이 발표한 데이터에 따르면, 모바일 사용자의 53%는 페이지 로딩에 3초 이상 걸리면 떠난다. 외부 스크립트가 2초를 잡아먹고 있다면, 그 한계선은 생각보다 훨씬 가깝다.

– Core Web Vitals와의 직접적 연관

구글의 Core Web Vitals 지표에서도 외부 스크립트는 직접적인 악영향을 준다.

LCP(Largest Contentful Paint)는 페이지에서 가장 큰 콘텐츠 요소가 화면에 표시되기까지 걸리는 시간이다. 외부 폰트가 늦게 로딩되면 텍스트가 그 시간만큼 늦게 표시되고, 이는 LCP 점수를 직접 낮춘다.

FID(First Input Delay)는 사용자가 버튼을 클릭하거나 링크를 탭했을 때 브라우저가 반응하기까지 걸리는 시간이다. 무거운 외부 스크립트가 메인 스레드를 점유하고 있으면, 사용자 입력에 즉각 반응할 수 없다. 클릭을 해도 아무 반응이 없는 그 답답한 순간이 FID가 낮은 상태다.

INP(Interaction to Next Paint)는 FID를 보완하는 최신 지표로, 페이지 전체 세션 동안 발생하는 모든 상호작용의 응답 속도를 측정한다. 외부 스크립트가 주기적으로 백그라운드 연산을 수행한다면 INP 점수 역시 나빠진다.

이 세 지표는 단순히 점수에 그치지 않는다. 구글 검색 알고리즘이 SEO 순위를 결정하는 데 직접 반영되는 신호다.

– 어떻게 개선할 수 있을까?

우선 현재 사이트에 어떤 외부 스크립트가 몇 개나 있는지 파악하는 것이 첫걸음이다. Chrome DevTools의 Network 탭에서 필터를 “JS”로 설정하면 외부 도메인에서 불러오는 스크립트 목록을 한눈에 볼 수 있다. 생각보다 많은 수에 놀라는 경우가 흔하다.

파악이 되었다면, 각 스크립트에 대해 세 가지 질문을 던져보자.
“이것이 정말 필요한가?”, “더 가벼운 대안은 없는가?”, “로딩 시점을 뒤로 미룰 수 있는가?”

구체적인 실천 방법은 다음과 같다.

구글 폰트는 자체 호스팅으로 전환하는 것이 가장 효과적이다. `google-webfonts-helper` 같은 도구를 사용하면 원하는 폰트 파일을 내려받아 자신의 서버에서 직접 서빙할 수 있다. 외부 DNS 조회와 연결 비용이 사라지고, 캐싱도 훨씬 자유롭게 제어할 수 있다.

통계 툴은 경량 버전을 고려해볼 만하다. Google Analytics 4 대신 Plausible이나 Fathom 같은 도구는 스크립트 크기가 훨씬 작고, 외부 연결도 단순하다. 방문자 수와 페이지뷰 정도만 파악하면 충분하다면, 수십 킬로바이트짜리 GA 스크립트 대신 1킬로바이트 수준의 경량 분석 툴로도 충분하다.

채팅 위젯은 즉시 로딩할 필요가 없는 대표적인 스크립트다. 페이지가 완전히 로딩된 이후에 지연 로딩(lazy loading)하거나, 사용자가 채팅 버튼 위로 마우스를 올렸을 때 비로소 불러오도록 설정하면 초기 로딩 속도에 미치는 영향을 크게 줄일 수 있다.

광고 스크립트는 가장 무거운 축에 속한다. 여러 광고 네트워크를 동시에 운영하고 있다면, 실제 수익 기여도를 측정해보고 효율이 낮은 것은 과감히 제거하는 것이 현명하다.

`async`와 `defer` 속성도 잊지 말자. 외부 스크립트 태그에 `async` 또는 `defer`를 추가하는 것만으로도 렌더 블로킹을 방지할 수 있다. 모든 외부 스크립트에 이 두 속성 중 하나가 붙어 있는지 반드시 확인하자.

– 핵심 포인트

외부 스크립트는 꼭 필요한 것만 남기고, 불필요한 것은 과감히 제거하는 것이 속도 최적화의 마지막이자 가장 실천적인 단계다. 자체 호스팅 전환, 경량 대안 도입, 지연 로딩 적용—이 세 가지 전략을 조합하면 외부 스크립트로 인한 로딩 지연을 절반 이상 줄이는 것도 충분히 가능하다. 속도 최적화에서 코드를 추가하는 것보다 제거하는 용기가 훨씬 강력한 무기가 되는 순간이 바로 여기다.