HTML 응답이 빨라도 첫 화면은 늦게 보일 수 있다. 이때는 화면에서 늦게 나타나는 이미지나 글자를 먼저 찾아야 한다. 그다음 파일 요청과 화면 표시 중 어디에서 기다리는지 확인하면 바꿀 설정을 좁힐 수 있다.
HTML은 페이지의 내용과 구조를 담은 문서다. 브라우저는 이 문서를 읽으며 이미지와 글꼴 같은 파일을 추가로 받는다. CSS는 배치와 모양을 정하고, JavaScript는 메뉴나 슬라이드 같은 동작을 처리한다. HTML이 빨리 도착해도 이 과정이 끝날 때까지 화면의 일부가 비어 있을 수 있다.
HTML 응답 자체가 느리다면 성능 점검 1편부터 확인하는 편이 좋다. 이 글에서는 HTML 다음에 생기는 지연을 살펴보고자 한다.
늦게 보이는 이미지나 글자부터 찾을 것
먼저 문제가 보이는 공개 글 한 개를 고른다. 로그아웃 상태로 열고, PC와 모바일 중 어느 쪽이 느린지 기록해야 한다. 기기를 바꾸면 화면 구성도 달라질 수 있다.
PageSpeed Insights에 그 주소를 입력한 뒤 모바일 결과를 열어 보자. 성능 진단에서 LCP 요소와 LCP breakdown에 해당하는 항목을 찾으면 된다. 표시 이름은 도구 버전과 언어에 따라 달라질 수 있다.
LCP는 첫 화면에서 가장 큰 이미지나 텍스트 영역이 표시되는 시점을 나타내는 지표다. 블로그에서는 대표 이미지가 해당할 수도 있고, 큰 제목이나 본문 영역이 해당할 수도 있다. 보고서가 가리킨 요소가 실제 페이지의 어디인지 먼저 확인해야 한다. LCP 공식 설명
예를 들어 제목은 금방 보이는데 큰 사진 자리가 한동안 비어 있다면 사진부터 조사하면 된다. 반대로 사진은 보이는데 제목 글자가 늦게 나타난다면 글꼴과 글자 표시 방식을 확인할 차례다. 이 예는 확인 순서를 설명하기 위한 상황이며 이번에 측정한 결과는 아니다.
요청 시작·다운로드·화면 표시를 나누어 볼 것
이미지가 늦게 보인다고 해서 파일 용량부터 줄여야 하는 것은 아니다. 이미지 요청을 늦게 시작했을 수도 있다. 다운로드가 끝났는데 다른 작업 때문에 화면에 그리지 못하는 경우도 있다.
| 보고서 항목 | 쉽게 풀면 | 먼저 확인할 것 |
|---|---|---|
| Resource load delay | 이미지 요청을 시작하기까지 기다림 | 지연 로딩, CSS 배경 이미지, 스크립트가 나중에 넣는 이미지 |
| Resource load duration | 이미지 파일을 받는 데 걸림 | 실제 받은 파일의 크기와 전달 경로 |
| Element render delay | 파일을 받은 뒤 화면에 표시하기까지 기다림 | CSS, 스크립트 실행, 요소를 숨기는 효과 |
보고서에서 가장 길게 나타난 구간부터 확인하는 편이 좋다. 다운로드 시간이 짧다면 이미지를 더 압축해도 큰 차이가 없을 수 있다. 텍스트가 LCP 요소일 때는 이미지 파일을 받는 과정과 똑같이 해석해서는 안 된다. LCP 구간별 진단
이미지는 실제 받은 파일과 요청 시점을 확인할 것
파일을 늦게 요청한다면
지연 로딩은 당장 보이지 않는 이미지를 나중에 받도록 하는 기능이다. 긴 글 아래쪽 사진에는 도움이 된다. 하지만 처음부터 보여야 하는 큰 이미지에 적용되면 표시가 늦어질 수 있다.
LCP로 확인한 이미지에 지연 로딩이 걸려 있다면 그 이미지부터 예외로 지정해야 한다. 사용하는 테마나 최적화 플러그인의 이미지 지연 로딩 설정에서 제외 기능을 찾아보면 된다. 아래쪽 이미지까지 한꺼번에 지연 로딩을 해제할 필요는 없다. 첫 화면 이미지와 지연 로딩
슬라이더가 실행된 뒤 이미지를 넣는 구성도 확인해야 한다. 시험 페이지에서 슬라이더 대신 일반 이미지 블록을 넣어 비교해 보면 원인을 좁힐 수 있다. 다만 CSS 배경 이미지나 스크립트로 삽입한 이미지까지 워드프레스가 모두 자동 최적화해 주는 것은 아니다.
파일을 받는 시간이 길다면
편집기에서 작게 보인다고 작은 파일을 받는 것은 아니다. 워드프레스 이미지 블록의 해상도 설정에서 원본 크기를 그대로 선택했는지 확인해야 한다. 파일의 가로·세로 크기와 전송 용량은 서로 다른 값이다. 고해상도 화면에서는 표시 폭보다 큰 이미지가 필요할 수도 있다.
실제 파일은 Chrome 개발자 도구의 Network에서 확인할 수 있다. 개발자 도구를 연 상태에서 페이지를 새로고침하고 Img로 걸러 보자. 해당 이미지를 선택하면 요청 주소와 전송 정보를 확인할 수 있다. Timing에서는 대기와 다운로드에 걸린 시간을 나누어 볼 수 있다. Network 사용 안내
메모리나 디스크 캐시에서 가져온 파일은 새로 다운로드한 경우와 나누어 기록해야 한다. 다운로드 비용을 비교할 때는 개발자 도구의 Disable cache를 켜서 시험할 수 있다. 이 설정은 개발자 도구를 열어 둔 동안 브라우저 캐시에 적용된다. CDN이나 서버 캐시까지 비우는 기능은 아니다.
여러 이미지 주소 중 실제 선택된 파일 찾기
이미지를 우클릭해 검사를 누른다. Elements에서 선택된 요소가 <img>인지 확인한다. Console에서 아래 읽기 전용 표현식을 실행하면 브라우저가 선택한 주소를 볼 수 있다.
$0.currentSrc$0은 개발자 도구에서 현재 선택한 요소다. currentSrc는 브라우저가 선택한 이미지 주소다. 이 값만으로 다운로드 성공 여부까지 알 수는 없다. Network의 응답 상태도 함께 확인해야 한다. currentSrc 설명
불필요하게 큰 파일을 받고 있다면 이미지 블록의 크기 선택부터 조정하는 편이 좋다. WordPress는 미디어 이미지에 화면 크기별 후보를 넣을 수 있다. 실제 출력은 테마와 플러그인의 영향도 받는다. WordPress 이미지 출력 속성
원본을 교체하거나 썸네일을 갱신해야 한다면 이미지 변경 후 확인 순서를 따르면 된다.
글자가 늦게 보이면 폰트 요청을 확인할 것
웹폰트는 브라우저가 별도로 받는 글꼴 파일이다. 파일이 도착하기 전까지 글자를 잠시 숨길지, 기기에 있는 대체 글꼴로 먼저 보여줄지는 폰트 표시 설정에 따라 달라진다. 웹폰트를 받기 전의 글자 표시
Network에서 Font로 걸러 보고 어떤 파일을 요청했는지 확인해야 한다. 현재 쓰는 글꼴과 굵기부터 대조하면 된다. 한글 폰트는 글자들을 여러 파일로 나눠 제공하기도 하므로 파일 개수만으로 낭비라고 판단해서는 안 된다.
선로딩은 파일을 미리 받으라는 지시다. 폰트를 바꿨는데 이전 선로딩이 남아 있으면 예전 파일도 받을 수 있다. 기존 선로딩 24개가 남았던 사례에서 당시 확인 과정과 결과를 볼 수 있다.
글꼴을 기다리느라 글자가 비어 있다면 font-display: swap 적용을 검토할 수 있다. 대체 글꼴로 먼저 표시한 뒤 웹폰트로 바꾸는 방식이다. 교체할 때 줄바꿈이나 배치가 움직일 수 있으므로 제목과 본문을 함께 확인해야 한다. 폰트를 추가로 선로딩하기 전에 기존 요청과 표시 방식을 먼저 점검하는 편이 좋다. 웹폰트 표시와 로딩 권장 사항
파일을 다 받았다면 화면을 그리는 작업을 살필 것
CSS는 요소의 크기와 위치, 모양을 정한다. 첫 화면에 필요한 CSS를 기다리면 표시가 늦어질 수 있다. PageSpeed나 Chrome의 Render-blocking requests 항목은 이런 요청을 찾는 출발점이다. 여기에 나왔다고 파일을 바로 삭제해서는 안 된다. 화면 구성에 필요한 코드일 수 있다. 화면 표시를 지연시키는 요청
JavaScript는 내려받은 뒤 실행하는 데도 시간이 든다. 브라우저의 메인 스레드는 스크립트 실행과 화면 작업을 함께 담당한다. 스크립트가 이 작업 흐름을 오래 차지하면 화면 표시나 입력 처리가 늦어질 수 있다. 긴 작업과 메인 스레드
이 구간은 Network만으로 판단하기 어렵다. Chrome의 Performance에서 새로고침을 포함한 기록을 남기는 편이 좋다. 화면 캡처와 작업 내역을 함께 보면 파일이 도착한 뒤 무엇을 기다렸는지 조사할 수 있다. 처음에는 결과 전체를 해석하려 하지 말고, 늦게 보인 요소와 그 직전의 긴 작업부터 살펴보면 된다. Performance 기록 안내
특정 플러그인의 기능을 쓰지 않는 페이지에서도 파일이 로드된다면 페이지별 제외 설정을 검토해 볼 만하다. 시험 환경에서 기능 하나를 끄고 같은 페이지를 다시 측정해야 한다. 요청이 사라졌는지 확인한 뒤 화면이 빨라졌는지도 비교해야 한다.
예를 들어 스크립트 지연 옵션을 켠 뒤 모바일 메뉴가 눌리지 않는다면 그 변경은 유지하면 안 된다. 방금 켠 옵션을 되돌려 동작부터 복구해야 한다. 이후 메뉴에 필요한 스크립트를 제외하는 방법을 제품 문서에서 확인하면 된다.
Coverage에 사용되지 않은 코드가 보여도 자동으로 지워서는 안 된다. 그 기록에서 메뉴를 열지 않았다면 메뉴용 코드가 미사용으로 잡힐 수 있다. 메뉴·검색·폼을 실제로 조작한 뒤 판단해야 한다. Coverage의 측정 범위
한 가지 변경만 적용하고 같은 조건에서 비교할 것
이번에 확인한 원인 하나만 바꾸는 편이 좋다. 이미지 크기와 폰트, 스크립트 설정을 한꺼번에 바꾸면 무엇이 효과가 있었는지 구분하기 어렵다.
- 변경 전 URL과 느린 요소를 기록한다. 기기·네트워크·브라우저 캐시 조건도 남긴다.
- 설정 하나를 바꾸고 공개 페이지가 새 내용을 받는지 확인한다.
- 같은 조건으로 여러 번 비교한다. LCP 요소 자체가 바뀌었는지도 확인한다.
- PC·모바일에서 메뉴·검색·폼과 이미지 표시를 확인한다.
- 반복해서 개선되고 기능도 정상이라면 변경을 유지한다. 효과가 불분명하거나 기능이 깨졌다면 되돌린다.
예를 들어 이미지 요청은 빨라졌는데 LCP가 그대로라면, 다음에는 다운로드 이후의 표시 지연을 확인해야 한다. 실제 결과를 아래처럼 한 줄씩 남겨 두면 다음 시험에서 같은 설명을 되풀이할 필요가 없다.
페이지 / 기기 / 측정 조건:
늦게 보인 요소:
이번에 바꾼 설정 한 가지:
변경 전후 결과:
메뉴·검색·폼 확인:
유지 또는 원복:새 이미지나 설정이 공개 화면에 반영되지 않았다면 캐시 갱신 글에서 확인 순서를 이어가면 된다. HTML 응답이 다시 병목으로 드러났다면 페이지 캐시 적용 판단으로 돌아가야 한다.
