웹이 느릴 때 네트워크·이미지·JavaScript 병목 구분하기

측정 조건을 고정하고 로딩, 상호작용, 레이아웃 이동을 나눠 개선하는 절차입니다.

웹페이지가 느리다는 말에는 첫 화면이 늦는 문제, 클릭에 반응하지 않는 문제, 읽던 위치가 밀리는 문제가 섞여 있습니다. 하나의 성능 점수만 보고 이미지를 줄이거나 JavaScript를 압축하기 전에, 느린 순간을 사용자의 행동으로 설명해야 합니다.

같은 조건으로 재현하기

예를 들어 ‘상품 목록에서 검색 버튼을 누른 뒤 결과가 보일 때까지 오래 걸린다’고 기록합니다. 기기, 브라우저, 네트워크 제한, 로그인 여부, 캐시 상태를 고정합니다. 확장 프로그램과 개발용 빌드는 결과를 바꿀 수 있으므로 비교 조건에 포함합니다.

개발자 도구의 Network에서 요청 대기와 다운로드를 보고 Performance에서 메인 스레드 작업을 확인합니다. 한 번의 측정값보다 여러 번 실행했을 때 반복되는 병목을 찾습니다. 실사용 데이터와 실험실 측정은 수집 조건이 다르므로 숫자를 그대로 동일시하지 않습니다.

증상별 첫 확인 지점

LCP, INP, CLS는 서로 다른 사용자 경험을 보는 지표입니다. 지표 이름을 외우는 것보다 실제 느린 요소와 작업을 연결하는 편이 개선에 도움이 됩니다.

이미지와 번들을 바꿀 때 확인할 것

이미지에는 원본 비율에 맞는 width와 height를 지정하고, 표시 크기에 맞는 소스를 제공합니다. 아래는 마크업 형태를 설명하는 예제이며 실제 이미지 파일은 별도로 준비해야 합니다.

<img src="/images/guide-800.webp"
     width="800" height="450"
     alt="응답 대기 시간이 긴 요청을 표시한 네트워크 패널">

본문 아래의 이미지는 지연 로딩을 검토할 수 있지만, 첫 화면의 핵심 이미지에 일괄 적용하면 표시가 더 늦어질 수 있습니다. 그림 내용을 설명하지 않는 장식 이미지의 대체 텍스트는 별도 접근성 기준으로 판단합니다.

번들은 큰 라이브러리가 실제로 어느 화면에서 쓰이는지부터 확인합니다. 화면별 지연 로딩은 초기 다운로드를 줄일 수 있지만, 처음 기능을 열 때 추가 대기가 생깁니다. 분리 전후 초기 로딩과 기능 진입을 모두 비교합니다.

한 번에 한 병목을 바꾸기

이미지 크기, 코드 분할, 서버 쿼리를 동시에 바꾸면 원인을 설명하기 어렵습니다. 가장 큰 병목 한 가지를 수정하고 동일한 시나리오에서 다시 측정합니다. 측정값을 공개할 때는 조건과 한계를 함께 적습니다. 서버에서 시간이 소비된다면 API 지연 분석으로 이어서 확인합니다.

참고 자료

• web.dev: Web Vitals
• MDN: img 요소