사이트 속도, 무엇으로 어떻게 점검하나.

속도 이야기를 하면 “점수 몇 점이에요?”부터 묻습니다. 그런데 같은 페이지를 두 번 재도 점수가 다르게 나오면 당황하죠. 점수는 측정 환경에 따라 출렁이는 신호일 뿐입니다. 제가 속도를 볼 때 진짜로 보는 건 두 가지입니다. 하나, 무엇이 페이지를 무겁게 하고 있나. 둘, 실제 방문자가 빠르다고 느끼고 있나. 도구는 이 두 질문에 답하려고 씁니다.

속도는 무엇으로 점검하나요?

도구는 세 개면 충분합니다. 역할이 겹치지 않고 서로 보완합니다.

• PageSpeed Insights — 주소만 넣으면 끝. 실사용자 데이터(필드)와 측정 데이터(랩)를 한 화면에서 보여주고, 무엇을 고치면 좋은지 제안까지 줍니다. 가장 먼저 여기서 시작합니다.
• Lighthouse(크롬 개발자도구 내장) — 내 브라우저에서 직접 돌려 자세한 항목을 파고들 때. 수정하고 바로 다시 돌려 보기 좋습니다.
• 구글 서치콘솔 · 코어 웹 바이탈 보고서 — 한 페이지가 아니라 사이트 전체가 실사용자 기준으로 좋은지/개선 필요인지를 그룹으로 보여줍니다. 추세 확인용입니다.

정리하면 한 페이지를 지금 보려면 PageSpeed, 자세히 파려면 Lighthouse, 사이트 추세는 서치콘솔입니다.

무엇이 페이지를 무겁게 하나요?

현장에서 보면 순서가 거의 일정합니다. 대부분 이미지가 가장 무겁고, 그다음이 자바스크립트, 그다음이 폰트입니다. CSS는 보통 상대적으로 가볍습니다. 그래서 개선도 무거운 것부터 손대는 게 효율이 좋습니다. 아래에서 ‘최적화’를 적용했을 때 무엇이 얼마나 가벼워지는지 상대 비중으로 직접 확인해 보세요.

위 막대는 상대 비중 예시지만, 패턴은 실제와 같습니다. 이미지를 적정 크기·차세대 포맷·지연 로딩으로 다루는 것만으로 보통 가장 큰 폭이 줄고, 안 쓰는 폰트 굵기/스크립트를 덜어내면 나머지가 따라옵니다.

필드 데이터와 랩 데이터, 무엇이 다른가요?

이 둘을 헷갈리면 엉뚱한 결론을 냅니다.

• 필드 데이터(실사용자) — 최근 일정 기간 실제 방문자들의 경험을 모은 값. 진짜 체감에 가깝지만, 방문자가 적으면 데이터가 부족해 안 보일 수 있습니다.
• 랩 데이터(측정) — 정해진 기기·네트워크로 그 순간 한 번 잰 값. 재현·비교에 좋아 ‘고치고 다시 재기’에 적합하지만, 내 빠른 컴퓨터 기준이라 실사용자보다 후하게 나올 수 있습니다.

그래서 같이 씁니다. “정말 나아졌나?”는 필드로 판단하고, “무엇을 고칠까?”는 랩으로 찾습니다. 개선을 했는데 랩 점수만 좋아지고 필드가 그대로면, 실사용자 환경(느린 폰·네트워크)에서의 문제를 놓친 것입니다.

측정과 개선은 어떤 순서로 하나요?

순서가 곧 효율입니다.

1. 측정 — PageSpeed Insights로 현재 상태와 가장 무거운 요소를 본다.
2. 한 가지 개선 — 영향이 가장 큰 것 하나(대개 이미지)부터 고친다.
3. 재측정 — 다시 재서 효과를 확인한다. 효과가 있으면 다음으로.
4. 추세 확인 — 며칠~몇 주 뒤 서치콘솔 필드 데이터로 실사용자 기준 개선을 확인한다.

핵심은 한 번에 하나씩입니다. 여러 개를 동시에 바꾸면 무엇이 효과였는지, 혹은 무엇이 새 문제를 만들었는지 알 수 없습니다.

그래서 점수에 집착하면 안 되는 이유

점수는 비교와 동기부여엔 좋습니다. 하지만 점수를 ‘목표’로 삼으면 사용자에게 의미 없는 항목을 손대느라 시간을 씁니다. 90점짜리 느린 사이트도, 80점짜리 빠른 체감 사이트도 있습니다. 진짜 질문은 늘 같습니다. 방문자가 기다리다 떠나지 않는가, 행동(문의·구매)으로 이어지는가. 도구는 그 답을 찾는 수단이지, 도구의 숫자가 목적이 아닙니다.

측정에서 ‘이미지가 제일 무겁다’가 확인되면, 제가 가장 먼저 적용하는 건 거의 정해져 있습니다. 차세대 포맷·반응형·지연 로딩을 한 묶음으로 넣습니다.

<!-- 차세대 포맷 + 반응형 + 지연 로딩 -->
<img src="hero-800.webp"
     srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
     sizes="(max-width:600px) 100vw, 800px"
     width="800" height="450"   <!-- 크기 명시 → 레이아웃 밀림(CLS) 방지 -->
     loading="lazy" decoding="async" alt="설명">

<!-- 첫 화면 핵심 이미지는 lazy 대신 우선 로드 -->
<link rel="preload" as="image" href="hero-800.webp">

단, 첫 화면에 보이는 큰 이미지에까지 loading="lazy"를 걸면 오히려 LCP가 늦어집니다. 화면 밖 이미지만 지연하는 게 핵심입니다.

도구와 지표를 헷갈리면 엉뚱한 걸 고치게 됩니다. 어떤 도구로 무엇을 보고, 코어 웹 바이탈의 ‘좋음’ 기준선이 무엇인지 한 표에 둡니다.

‘무엇을 고칠까’는 랩(Lighthouse)으로 찾고, ‘정말 나아졌나’는 필드(서치콘솔 CWV)로 판단합니다. 기준선은 일반 공개 권장값입니다.