초기 표시와 이후 반응의 지연
병원 홈페이지가 느리다는 느낌에는 첫 화면이 늦게 나타나는 문제와, 화면이 나타난 뒤 클릭이나 입력에 늦게 반응하는 문제가 섞일 수 있습니다. 큰 이미지 외에도 외부 채팅·분석·영상 도구가 추가한 요청과 JavaScript 실행이 원인 후보가 됩니다. 화면에 있는 요소의 수를 세는 것만으로 실제 병목을 확정하기 어렵습니다. 해당 사이트의 네트워크와 실행 부담을 구분해 확인해야 합니다.
web.dev는 서드 파티 JavaScript를 외부 공급업체에서 제공하며 사이트에 삽입하는 스크립트로 설명합니다. 채팅 서비스, 영상 플레이어, 분석 스크립트, 소셜 공유 버튼, 실험 도구와 도우미 라이브러리 등이 여기에 포함될 수 있습니다. 한 서비스는 방문자에게 유용한 기능을 제공하면서도 자원을 요청하고 코드를 실행합니다. 기능이 유용하다는 판단과 그 기능의 성능 부담은 각각 확인할 문제입니다.
첫 화면을 표시하는 데 필요한 자원이 통과하는 경로를 web.dev는 중요한 렌더링 경로로 설명합니다. 여기에 동기식 외부 스크립트가 있으면 나머지 문서를 읽고 구성하는 과정이 지연될 수 있습니다. 공급업체 서버에서 자원을 보내지 못하면 요청이 시간 초과될 때까지 표시가 차단되는 경우도 안내합니다. 눈에 보이는 그림이 작아도 이 경로에서 대기하는 자원이 있으면 초기 표시가 느릴 수 있습니다.
반면 JavaScript를 파싱하고 실행하는 데 CPU가 많이 사용되면 화면 표시 이후의 상호작용이 지연될 수 있습니다. 긴 작업이 기본 스레드를 점유하면 다른 작업을 처리할 시간이 늦어집니다. 다운로드 용량이 크다는 사실과 실행 시간이 길다는 사실은 같은 측정이 아닙니다. 파일을 가져오는 단계와 가져온 코드를 처리하는 단계를 구별하면 어떤 종류의 지연을 확인할지 정할 수 있습니다.
| 느리게 느껴지는 상황 | 원인 후보 | 대조할 정보 |
|---|---|---|
| 첫 내용이 나타나기까지 대기 | 렌더링 경로의 요청과 차단 | 요청 순서와 콘텐츠 표시 시점 |
| 화면 이후 조작 반응 지연 | CPU 부담과 긴 작업 | 스크립트 파싱·실행 시간 |
| 영상 등 삽입 기능이 늦게 나타남 | 외부 자원 응답 | 해당 공급업체의 요청 |
| 재방문에도 자원을 계속 요청 | 캐싱 조건 | 반복 요청과 응답 설정 |
외부 요청과 중복 자원의 부담
외부 서버에 연결하는 과정에는 파일을 받는 시간만 있는 것이 아닙니다. web.dev는 DNS 조회와 리디렉션, 서버와의 왕복 과정이 네트워크 부담에 포함될 수 있다고 설명합니다. 여러 서버로 요청이 분산되면 연결을 설정하는 일도 늘어날 수 있습니다. 이미지의 저장 용량을 줄였는데도 느린 상태가 남는다면 외부 연결의 수와 실제 응답을 구분해 확인할 수 있습니다.
외부 스크립트가 다른 이미지나 동영상도 불러올 수 있습니다. 화면에 삽입한 코드가 짧더라도 이후 요청하는 자원은 별개입니다. web.dev는 최적화되지 않은 이미지와 영상, 충분하지 않은 압축을 네트워크 부담의 원인으로 설명합니다. 편집 화면에 들어 있는 코드의 줄 수를 전체 전송량으로 취급하지 않고 그 코드가 추가로 요청하는 파일까지 확인해야 합니다.
캐싱이 충분하지 않으면 브라우저가 자원을 다시 가져오기 위해 요청을 더 많이 보낼 수 있습니다. 같은 파일을 재사용하는 조건과 전송할 때 압축하는 조건은 서로 다릅니다. 캐싱은 재사용과 반복 요청에 관계되고 압축은 전송되는 자원의 크기에 관계됩니다. 둘 다 외부 자원에서 발생할 수 있으므로 사이트의 자체 이미지 설정만으로 모든 응답 조건을 통제할 수 있다고 가정하지 않습니다.
여러 삽입 기능이 같은 프레임워크나 라이브러리를 각각 가져오는 경우도 공식 문서의 원인 후보에 해당합니다. 기능별로 다른 공급업체를 선택했더라도 필요한 기반 코드가 겹칠 수 있습니다. web.dev는 서로 다른 공급업체에서 같은 기능을 중복 사용하지 말고 중복 스크립트를 정기적으로 감사해 정리하도록 권장합니다. 기능을 유지할지 판단하는 일과 같은 기반 자원을 여러 번 요청하는지 확인하는 일을 나눌 수 있습니다.
분석이나 실험을 위한 도구는 화면에 직접 보이지 않을 수 있습니다. A/B 테스트 스크립트는 사용자가 어느 실험에 속하는지 정하고 올바른 대안을 활성화하는 동안 렌더링을 지연시키기도 합니다. 공식 문서는 비동기식 실험 스크립트도 콘텐츠 표시를 막을 수 있다고 설명합니다. 보이지 않는 코드는 화면의 그림 개수에서 드러나지 않으므로 전송과 실행 자료를 통해 식별해야 합니다.
| 측정에서 발견한 조건 | 추가로 확인할 대상 | 개선 판단 |
|---|---|---|
| 특정 외부 출처의 대기 시간이 큼 | 연결·응답·리디렉션 | 공급과 연결 조건 검토 |
| 같은 기반 코드가 여러 번 요청됨 | 기능별 종속 라이브러리 | 중복 제공 여부 검토 |
| 파일이 반복해서 새로 전송됨 | 캐싱과 압축 설정 | 재사용과 전송 조건 구분 |
| 실험 처리까지 본문 표시가 지연됨 | 실험 스크립트의 표시 제어 | 적용 방식과 대상 검토 |
원인 후보를 비교하는 조건
web.dev는 Chrome DevTools, PageSpeed Insights, WebPageTest 같은 무료 도구로 부담이 큰 스크립트를 식별하도록 안내합니다. 네트워크 자료에서는 요청과 전송을 분석하고 실행 자료에서는 파싱·컴파일·평가에 걸리는 시간을 확인할 수 있습니다. 같은 느림을 설명하더라도 두 자료가 답하는 질문이 다르므로 분석 결과를 한 숫자로만 읽지 않습니다.
WebPageTest의 도메인 분류는 출처별 총 바이트와 요청 수를 구분해 보여 주는 기능으로 소개됩니다. 많은 요청을 하는 출처와 큰 파일을 보내는 출처가 반드시 같지는 않습니다. 실제 사용하는 외부 기능의 연결 도메인을 식별하면 전체 페이지에 섞인 자원을 출처별로 대조할 수 있습니다. 도메인의 이름만으로 유해하거나 불필요한 기능이라고 판정하는 작업은 아닙니다.
의심되는 자원을 차단한 상태와 차단하지 않은 상태를 비교하는 방법도 공식 문서에 있습니다. 네트워크 요청 차단은 해당 요청을 사용할 수 없을 때 페이지가 어떻게 동작하는지 확인하는 수단입니다. 실제 기능을 삭제하기 전에 원인 후보의 영향을 조사하는 테스트이며, 테스트에서 빨라졌다는 이유만으로 이용에 필요한 기능을 곧바로 제거할 결정과는 구별합니다.
빠른 데스크톱과 네트워크에서는 비용이 큰 스크립트의 영향이 작게 나타날 수 있습니다. web.dev는 실제 조건을 에뮬레이션하기 위해 네트워크와 CPU 제한을 적용하도록 권장합니다. 또한 일부 스크립트가 로딩마다 다른 자원을 가져오는 경우를 고려해 세 번 이상 측정하라고 안내합니다. 이는 원문의 측정 권장사항이며 병원 홈페이지의 합격 점수나 시간 기준을 정한 규칙은 아닙니다.
일부 iframe의 긴 작업은 기본 스레드를 차단하고 이벤트 처리를 지연시킬 수 있습니다. 문서는 긴 작업의 기여 분석 정보로 어떤 프레임에서 작업이 발생했는지 확인하는 방법을 설명합니다. 삽입 영상의 화면 크기만 점검하는 일과 그 프레임 안의 스크립트가 실행하는 일을 분석하는 것은 다른 범위입니다. 사용자 조작이 늦는 문제에는 실행의 출처도 원인 후보가 됩니다.
연결 설정 시간이 긴 경우에는 리소스 힌트도 검토할 수 있습니다. web.dev는 dns-prefetch로 외부 도메인의 DNS 조회를 미리 수행하고 preconnect로 HTTPS 연결의 추가 단계를 준비하는 방법을 설명합니다. 이 조치는 연결을 설정하는 시간을 줄이려는 목적이며 다운로드한 코드의 실행량을 줄이는 방법과는 다릅니다. 어떤 단계가 오래 걸리는지 대조한 결과에 맞춰 적용 대상을 정합니다.
오래된 삽입 코드에서 document.write()를 사용하면 일관되지 않은 동작과 디버깅의 어려움이 생길 수 있다고 문서는 안내합니다. Chrome DevTools의 경고와 Lighthouse의 관련 진단은 이런 사용을 찾는 데 도움이 됩니다. 현재 사이트에서 해당 방식이 실제 사용되는지 먼저 식별해야 하며, 과거 API가 원인이라는 설명을 측정 없이 모든 느린 화면에 적용하지 않습니다.
자주 묻는 질문
async와 defer를 넣으면 모두 해결되나요?
web.dev는 두 속성이 문서 파싱과 스크립트 실행의 시점을 바꾸지만 모든 문제를 해결하지는 않는다고 설명합니다. async는 다운로드 후 실행하는 동안 파싱이 차단되고 defer는 파싱 완료 뒤 실행합니다. 비동기 로딩이 가능한지는 사용하는 스크립트의 문서와 종속 조건도 확인해야 합니다.
태그 관리자로 합치면 부담이 사라지나요?
문서는 태그 관리자가 로드를 간소화할 수 있지만 태그와 자동 이벤트 리스너가 너무 많으면 요청과 실행 부담이 증가할 수 있다고 설명합니다. 관리 도구를 사용한다는 사실과 실제 등록된 태그의 수·역할을 구별합니다.
스크립트를 직접 호스팅하면 항상 유리한가요?
직접 호스팅하면 DNS 시간이나 캐싱 헤더 등 로딩 조건을 더 세부적으로 관리할 수 있습니다. 반면 API 변경과 보안 수정의 자동 업데이트를 받지 못하는 문제가 있다고 문서는 안내합니다. 전송 조건만 확인하고 갱신 부담을 제외한 결정을 내리지 않습니다.
외부 서버의 장애와 일반 차단 테스트는 같나요?
WebPageTest의 단일 장애점 테스트는 천천히 시간 초과되는 조건을 시뮬레이션합니다. 도메인 차단과 달리 공급업체에 부하가 심하거나 일시적으로 이용할 수 없는 상황을 조사하는 데 유용하다고 문서는 설명합니다. 두 테스트는 서로 다른 실패 조건입니다.
아래쪽 영상은 나중에 로드해도 되나요?
문서는 처음에 즉시 보지 않는 외부 자원을 지연 로드할 수 있다고 안내합니다. 다만 불안정한 연결의 영향을 받는 JavaScript가 포함될 수 있어 주의가 필요합니다. 분석 스크립트를 너무 늦게 불러오면 중요한 데이터를 놓칠 수도 있으므로 자원의 목적에 맞춰 판단합니다.