프론트엔드 성능 진단｜Waterfall·Main Thread 30분 분류
웹사이트가 느릴 때 이미지 압축, 캐시 플러그인, JavaScript 지연을 한꺼번에 적용하면 무엇이 효과가 있었는지 알 수 없습니다. 먼저 지연이 네트워크 대기인지, 메인 스레드 작업인지, 화면 배치 변화인지 분류해야 합니다. 이 글은 Chrome 개발자 도구의 Network와 Performance 패널로 한 페이지를 30분 안에 진단하고 다음 작업을 정하는 순서입니다.
측정 조건을 먼저 고정한다
대표 URL 한 개와 모바일 또는 데스크톱 한 가지를 고릅니다. 로그인 여부, 네트워크 제한, CPU 제한, 캐시 사용 여부를 기록하고 같은 조건에서 3회 측정해 중앙값을 비교하세요. 개발자 도구의 Disable cache는 도구가 열린 동안에만 적용되므로 이 상태도 기록해야 합니다.
PageSpeed 점수 한 번만 보고 결론 내리지 않습니다. 실험실 측정은 재현과 변경 전후 비교에 좋고, 실제 사용자 데이터는 다양한 기기·회선·상호작용을 반영합니다. LCP·INP·CLS 기준과 현장 데이터 해석은 Core Web Vitals 30분 진단에서 별도로 확인할 수 있습니다.
30분 프론트엔드 진단 순서
| 시간 | 확인 화면 | 남길 기록 |
|---|---|---|
| 0~5분 | 테스트 조건 고정 | URL, 기기, 회선, CPU, 캐시 |
| 5~12분 | Network 워터폴 | 문서 대기, 큰 파일, 요청 사슬 |
| 12~22분 | Performance 기록 | Scripting, Layout, Paint, 긴 작업 |
| 22~27분 | 스크롤·클릭 재현 | 느린 상호작용, 화면 이동 시점 |
| 27~30분 | 원인 하나 선택 | 수정 후보, 확인 지표, 원복 기준 |
1단계: Network 워터폴로 대기 위치 찾기
Network 패널을 열고 기록을 지운 다음 페이지를 새로고침합니다. 먼저 HTML 문서 요청을 선택해 Timing을 봅니다. 문서 응답 대기가 길면 프론트엔드 파일을 줄이기 전에 서버 처리, 캐시, 네트워크 구간을 의심해야 합니다. 반대로 문서는 빠른데 CSS·폰트·이미지·스크립트 요청이 길게 이어지면 프론트엔드 요청 사슬을 좁힙니다.
표의 Size만 보지 말고 Waterfall의 시작 시점, 총 시간, Initiator를 함께 봅니다. 뒤늦게 시작되는 LCP 이미지나 폰트는 어떤 CSS·스크립트가 요청을 발견하게 했는지 확인합니다. 같은 파일의 중복 요청, 실패·리디렉션, 타사 도메인 연결 대기도 기록하세요.
2단계: Performance에서 메인 스레드 확인
Performance 패널에서 페이지 로드를 기록하고 Main 트랙을 펼칩니다. 넓은 막대는 오래 걸린 작업이며 Summary에서 Scripting, Rendering, Painting의 비중과 실행 파일을 확인할 수 있습니다. Insights 탭에 표시된 항목은 출발점으로 사용하되, 실제 타임라인과 요청 파일을 연결해 원인을 확인합니다.
Scripting이 길고 큰 번들이 반복 실행된다면 JS 번들 Coverage·코드 스플리팅 점검으로 이어갑니다. 광고·분석·채팅 등 타사 작업이 크면 외부 스크립트 async·defer 안전 적용을 참고하세요. Layout·Paint가 반복된다면 브라우저 렌더링 병목 진단으로 범위를 좁힙니다.
3단계: 실제 동작을 재현한다
페이지 로드가 끝났다고 진단을 멈추면 INP나 늦은 화면 이동을 놓칩니다. 기록을 시작한 상태에서 메뉴 열기, 검색, 상품 선택, 스크롤처럼 사용자가 자주 하는 동작을 한 번씩 수행하세요. 클릭 직후 긴 JavaScript 작업이 생기는지, 콘텐츠가 추가되며 Layout이 반복되는지, 크기가 없는 이미지 때문에 화면이 움직이는지 시간축으로 확인합니다.
이미지 전송량이 크거나 표시 크기보다 원본이 지나치게 크다면 워드프레스 이미지 최적화 점검으로 넘어갑니다. WebP나 AVIF 변환만 하기보다 크기 속성, 반응형 이미지, LCP 이미지 지연 로딩 여부를 먼저 확인하는 편이 안전합니다.
관찰 결과별 다음 작업
| 관찰한 신호 | 우선 원인 후보 | 다음 확인 |
|---|---|---|
| HTML 문서 대기가 김 | 서버 처리·캐시·DB | TTFB와 서버 로그 |
| 요청이 늦게 연쇄 시작 | 리소스 발견 지연 | Initiator와 요청 사슬 |
| Scripting 비중이 큼 | 큰 번들·타사 코드 | 실행 파일과 Coverage |
| Layout·Paint 반복 | DOM 변경·스타일 계산 | 이벤트 전후 타임라인 |
| 화면 이동이 발생 | 공간 미확보·늦은 삽입 | 이미지 크기와 삽입 요소 |
TIP: 한 번에 한 원인만 바꾼다
첫 번째 실험은 가장 큰 병목 하나만 대상으로 정합니다. 변경 전후에 같은 URL과 조건으로 3회 측정하고 중앙값, 요청 수, 전송량, 긴 작업, LCP·CLS를 기록하세요. 기능 오류가 생기거나 지표가 개선되지 않을 때 되돌릴 설정과 파일도 미리 적어 둡니다. 여러 최적화를 동시에 켜면 효과와 부작용의 원인을 다시 분리하기 어렵습니다.
마무리
프론트엔드 최적화는 기술 목록을 모두 적용하는 작업이 아닙니다. Network에서 문서 대기와 요청 사슬을 확인하고, Performance에서 메인 스레드의 Scripting·Layout·Paint를 읽은 뒤, 실제 클릭과 스크롤을 재현하세요. 이렇게 병목을 하나로 좁힌 다음 관련 세부 점검으로 넘어가야 변경 효과를 설명하고 안전하게 원복할 수 있습니다.
참고한 공식 문서
댓글 0
첫 댓글을 남겨보세요.