PageSpeed Insights로 페이지 속도 확인하고 고치기
구글 PageSpeed Insights에 페이지를 넣어 보니 모바일 점수는 주황색 54, 자바스크립트와 이미지, 캐시에 관한 경고가 길게 늘어서 있고, 데스크톱은 92점이라 무엇을 믿어야 할지 헷갈립니다. 한 페이지짜리 사이트라면 이 보고서의 대부분은 신경 쓰지 않아도 됩니다. 중요한 숫자는 몇 개뿐이고, 작은 정적 페이지의 해결책은 대개 짧고 순서도 정해져 있습니다.
검사 돌리기
pagespeed.web.dev를 열고, 공개된 페이지의 전체 주소를 붙여 넣은 뒤 Analyze(분석)를 누릅니다. 페이지는 인터넷에 올라가 있어야 합니다. 내 컴퓨터에 있는 파일이나 로그인해야 보이는 페이지는 검사하지 못합니다. 결과는 모바일과 데스크톱이 따로 나옵니다. 모바일부터 보십시오. 모바일 검사는 모바일 통신망의 중급 휴대폰을 흉내 내기 때문에 공유된 링크로 들어오는 방문자의 실제 환경에 더 가깝고, 거의 언제나 점수가 더 낮습니다.
필드 데이터와 실험실 데이터는 다릅니다
보고서는 두 부분으로 나뉘는데, 이 둘을 섞어 읽는 데서 혼란이 대부분 생깁니다.
- 필드 데이터는 Chrome 사용자 경험 보고서(CrUX)에서 옵니다. 지난 28일 동안 그 페이지를 방문한 실제 Chrome 사용자의 측정값으로, 방문자가 실제로 겪은 속도입니다. 구글 문서에 따르면 페이지 방문이 충분하지 않으면 사이트 전체(도메인) 데이터로 대신하고, 그것도 부족하면 필드 데이터를 보여 주지 않습니다. 새로 만든 작은 사이트라면 여기에 데이터가 없는 것이 정상이고, 문제가 있다는 뜻이 아닙니다.
- 실험실 데이터는 Lighthouse가 통제된 가상 환경에서 페이지를 한 번 불러와 잰 값입니다. 0~100점 성능 점수와 개선 제안 목록이 여기서 나옵니다. 원인을 찾는 데 유용하지만 가상 방문 한 번이라서, 돌릴 때마다 점수가 몇 점씩 오르내립니다.
점수 구간은 90점 이상이 좋음, 50~89점이 개선 필요, 50점 미만이 나쁨입니다. 필드 데이터가 통과인데 실험실 점수가 70점이라면 실제 방문자는 불편 없이 보고 있는 것입니다. 필드 데이터가 없다면 실험실 데이터를 기준으로 삼으십시오.
LCP, INP, CLS
이 세 지표가 구글이 말하는 코어 웹 바이탈(Core Web Vitals)입니다. 각각 방문의 75번째 백분위수로 평가합니다. 즉 방문 네 번 중 세 번이 기준을 넘어야 하고, 세 지표가 모두 좋음이면 코어 웹 바이탈 평가를 통과합니다. web.dev와 PageSpeed Insights 문서에 실린 기준값은 다음과 같습니다.
| 지표 | 재는 것 | 좋음 | 개선 필요 | 나쁨 |
|---|---|---|---|---|
| LCP(최대 콘텐츠 페인트) | 첫 화면에서 가장 큰 이미지나 글 덩어리가 다 나타나는 시점 | 2.5초 이하 | 4초까지 | 4초 초과 |
| INP(다음 페인트까지의 상호작용) | 누르기·클릭·키 입력 뒤 화면이 눈에 띄게 반응하기까지 걸리는 시간 | 200ms 이하 | 500ms까지 | 500ms 초과 |
| CLS(누적 레이아웃 이동) | 불러오는 동안 내용이 얼마나 들썩이는지 | 0.1 이하 | 0.25까지 | 0.25 초과 |
INP는 실제 조작이 있어야 잴 수 있어서 필드 데이터에만 나옵니다. 실험실 부분에는 대신 총 차단 시간(Total Blocking Time)이 나오는데, 불러오는 동안 스크립트가 브라우저를 붙잡고 있는 시간입니다. 이 값이 높으면 실제 사용자의 INP도 대개 나쁩니다.
단순한 페이지에서 LCP 요소는 거의 언제나 히어로 이미지나 큰 제목이고, 실험실 부분의 진단 항목에 대개 어떤 요소인지 나옵니다. 그러면 어느 파일을 봐야 하는지 바로 알 수 있습니다.
작은 사이트를 느리게 만드는 흔한 원인
너무 큰 이미지. 폭 800픽셀로 보여 줄 자리에 휴대폰에서 찍은 4MB 사진을 넣는 것이 LCP가 느린 가장 흔한 이유입니다. 히어로가 나타나려면 브라우저가 그 파일을 다 받아야 합니다. PageSpeed Insights도 대개 이미지 관련 제안에 이런 파일을 올리고, 얼마나 줄일 수 있는지 추정치를 함께 보여 줍니다.
웹 글꼴. 글꼴 파일도 하나하나가 내려받을 파일이고, 한글 글꼴은 수천 자를 담고 있어 큽니다. 두 가지 글꼴을 굵기 세 개씩 불러오는 페이지는 글자가 나타나기 전에 수백 KB의 글꼴을 기다리거나, 글꼴이 도착하면서 글줄이 다시 흘러 바뀝니다.
외부 스크립트. 채팅 상담 위젯, 분석 태그, 지도 삽입, 동영상 플레이어, SNS 피드, 그리고 AI가 만든 페이지에 흔히 들어 있는 Tailwind CDN 스크립트입니다. 모두 내가 통제하지 못하는 코드를 내려받아 실행합니다. LCP보다 총 차단 시간과 INP에 더 큰 영향을 줍니다.
크기가 적히지 않은 이미지. <img>에 width와 height 속성이 없으면 브라우저는 자리를 얼마나 비워 둘지 모릅니다. 그래서 사진이 도착하는 순간 아래 글이 밀려 내려가는데, 이것이 CLS입니다. 불러온 뒤에 위에서 밀고 들어오는 배너나 쿠키 안내도 같은 문제를 만듭니다.
효과가 큰 순서대로 고치기
- 이미지 크기를 줄이고 압축합니다. 대개 이것 하나로 가장 큰 효과를 봅니다. 각 이미지를 실제로 보이는 가장 큰 폭 정도로 줄이고(전체 폭 배너는 1200~1920픽셀, 본문 이미지는 그보다 작게), WebP나 JPEG로 품질 75~85 정도에서 압축합니다. Finipix 같은 도구를 쓰면 여러 장을 브라우저 안에서 한 번에 처리할 수 있고, 본문 이미지, 히어로 · 배너, 썸네일 프리셋도 있습니다. 자세한 순서는 웹용 이미지 용량 줄이기에, 형식 고르기는 웹 이미지 형식과 크기에 정리했습니다.
- 모든 이미지에 width와 height를 적습니다. 이미지의 실제 픽셀 크기를
width="1200" height="800"처럼 적고, CSS에는height: auto를 두어 화면에 맞게 줄어들게 합니다. 브라우저가 이 비율로 자리를 미리 잡아 두므로 CLS 대부분이 해결됩니다. - 히어로 이미지는 지연 로딩하지 않습니다.
loading="lazy"는 아래쪽 이미지에는 좋지만, LCP 이미지에 붙이면 측정 대상 자체를 늦춥니다. 첫 화면의 큰 이미지에서는 빼십시오. - 글꼴을 덜어 냅니다. 글꼴 세 종류에 굵기 다섯 개가 아니라 한 종류에 굵기 두 개로 줄입니다. Google Fonts 링크에는
&display=swap을, 직접 쓴@font-face에는font-display: swap을 넣으면 대체 글꼴로 글자가 먼저 보입니다. 한글 글꼴과 서브셋은 웹 페이지 글꼴의 원리와 바꾸는 법에서 다룹니다. - 외부 스크립트를 하나씩 따져 봅니다. 아무도 쓰지 않는 위젯은 지웁니다. 꼭 필요한 게 아니라면 지도 삽입은 지도로 연결되는 정적 이미지로, 동영상 삽입은 영상으로 연결되는 썸네일로 바꿉니다.
- 나머지는 그다음에. 쓰지 않는 CSS, 캐시 헤더, 서버 응답 시간 같은 제안은 작은 정적 페이지에서는 영향이 작고, 일부는 내 파일이 아니라 호스팅 설정에 달린 문제입니다.
고친 다음에
필드 데이터는 최근 28일 동안의 실제 방문을 계속 모으는 방식이라 변경이 반영되기까지 최대 28일이 걸립니다. 실험실 점수는 바로 바뀝니다. 작은 페이지라 필드 데이터가 없다면 모바일 실험실 점수 90점대, LCP 2.5초 미만, CLS 0에 가까운 값을 목표로 하고 거기서 멈추십시오. 그 이상은 내용을 다듬는 데 시간을 쓰는 편이 낫습니다. 새 버전을 올리기 전에는 랜딩 페이지 공개 전 체크리스트도 확인해 보십시오.
내 파일로 바로 해 보려면 Finipage 편집기를 여세요. 브라우저에서 돌아가고 파일은 내 기기 밖으로 나가지 않습니다.