PageSpeed Insights와 점수가 왜 다른가요?

측정 대상이 다릅니다. PageSpeed Insights는 헤드리스 브라우저를 띄워 Core Web Vitals(LCP·CLS·INP)를 보고하고, 실제 크롬 사용자의 필드 데이터도 포함합니다. 저희는 자체 요청으로 서버 응답과 내려받은 HTML을 측정합니다. 서버·페이로드 문제 진단에는 이 도구를, 렌더링과 실사용자 성능에는 PSI를 쓰세요.

TTFB는 얼마나 나와야 좋은 건가요?

구글의 '양호' 기준은 800ms이고, 300ms 아래면 확실히 빠른 편입니다. 1.5초를 넘는다면 캐시 없이 DB에서 페이지를 매번 만들고 있을 가능성이 거의 확실하므로 거기부터 보면 됩니다.

제 눈엔 빠른데 여기선 점수가 나쁘게 나옵니다

대개 이미 데워진 캐시에서, 서버와 지리적으로 가까운 위치에서, 데스크톱 회선으로 보고 계셔서입니다. 저희 측정은 다른 네트워크에서 날아가는 콜드 상태의 단일 요청입니다. 그 차이가 정확히 첫 방문 모바일 사용자가 겪는 경험입니다.

속도가 구글 순위에 영향을 주나요?

줍니다. 다만 크지 않습니다. Core Web Vitals는 실제 신호지만 주로 적합성이 비슷한 페이지들 사이의 동점 처리로 작동합니다. 속도의 더 큰 효과는 이탈률과 전환율 쪽이고, 보통은 그게 투자할 더 나은 이유입니다.

사이트 속도 측정

이 검사는 서버 쪽에서 통제 가능한 요소를 직접 측정합니다 — 서버가 응답하기까지 걸리는 시간, 내려보내는 HTML의 양, 압축·캐시 적용 여부, 첫 화면을 막는 리소스 개수. 실사용자 필드 데이터(Core Web Vitals)가 아니라 실험실 측정이므로, PageSpeed Insights와 비교하기 전에 아래 주의사항을 먼저 읽어보세요.

11%가 속도 55점 미만

분석한 웹사이트 959개 기준

공개 데이터베이스의 전체 사이트를 대상으로 집계했습니다.

왜 중요한가

TTFB는 실제로 고칠 수 있는 유일한 숫자입니다

속도 리포트의 나머지 항목은 전부 그 뒤에 따라옵니다. 서버가 첫 바이트를 보내는 데 1.5초가 걸린다면 이미지를 아무리 최적화해도 그 시간은 회수되지 않습니다 — 브라우저가 아직 일을 시작도 못 했으니까요. 동시에 값싼 조치에 가장 민감한 지표이기도 합니다. 캐시 적용, CDN 도입, 과부하 걸린 공유 호스팅 탈출만으로 70%씩 줄어드는 경우가 흔합니다.

속도는 순위 요소이긴 하지만 약합니다 — 대신 전환에는 강하게 작용합니다

Core Web Vitals는 비슷한 수준의 페이지들 사이에서 동점을 가르는 정도로 순위에 관여합니다. 콘텐츠 적합성이 압도적으로 큽니다. 신경 써야 하는 진짜 이유는 반대편의 돈입니다. 이탈률은 1초에서 3초 구간에서 가파르게 올라가고, 한국 모바일 4G 환경의 쇼핑객이 정확히 가장 먼저 이탈하는 집단입니다. 속도는 'SEO에도 도움이 되는 매출 지표'로 다루는 게 맞습니다.

고치는 방법

1. 다른 걸 손대기 전에 HTML부터 캐시하세요
요청마다 DB에서 페이지를 새로 만들고 있다면 그게 곧 TTFB입니다. 전체 페이지 캐싱(Cloudflare, Varnish, 워드프레스 캐시 플러그인, 또는 정적 생성)은 1200ms 응답을 90ms로 바꿔놓고, 대개 코드 재작성이 아니라 설정 변경 수준입니다.
2. 압축을 켜세요
HTML·CSS·JS에 gzip이나 brotli를 적용하면 전송량이 보통 70–80% 줄어듭니다. nginx/Apache에서는 지시어 한 줄, 관리형 호스팅에서는 토글 하나입니다. 2026년에 압축 안 된 HTML을 내보내는 사이트는 거의 전부 실수로 그러고 있는 겁니다.
3. 스크립트를 임계 경로에서 빼내세요
`<head>`에 있는 모든 `<script src>`와 스타일시트가 첫 화면을 늦춥니다. 렌더 전에 실행될 필요가 없는 스크립트에는 `defer`, 독립적인 외부 태그에는 `async`를 붙이세요. 그리고 그 태그들이 뭔지 점검하세요 — 채팅 위젯, 히트맵, 중복 설치된 애널리틱스가 '이미지도 없는데 느린 사이트'의 대표적 원인입니다.
4. 모든 이미지에 width·height를 지정하세요
속도 자체보다 레이아웃 안정성(CLS) 때문입니다. 크기가 없으면 브라우저가 공간을 미리 확보하지 못해, 이미지가 로드될 때마다 콘텐츠가 튑니다. 실제 용량 절감은 화면 아래 이미지의 `loading="lazy"`와 최신 포맷(WebP/AVIF)으로 잡으세요.

설명 말고, 그냥 고쳐드릴까요?

콘텐츠 레벨에서 되는 부분은 저희가 직접 적용합니다. 서버 영역(압축·캐시·응답 시간)은 호스팅사에 전달할 설정 지시서로 드립니다. 둘 다 같은 고정가에 포함됩니다.

고정가 보기 →

자주 묻는 질문

PageSpeed Insights와 점수가 왜 다른가요?: 측정 대상이 다릅니다. PageSpeed Insights는 헤드리스 브라우저를 띄워 Core Web Vitals(LCP·CLS·INP)를 보고하고, 실제 크롬 사용자의 필드 데이터도 포함합니다. 저희는 자체 요청으로 서버 응답과 내려받은 HTML을 측정합니다. 서버·페이로드 문제 진단에는 이 도구를, 렌더링과 실사용자 성능에는 PSI를 쓰세요.
TTFB는 얼마나 나와야 좋은 건가요?: 구글의 '양호' 기준은 800ms이고, 300ms 아래면 확실히 빠른 편입니다. 1.5초를 넘는다면 캐시 없이 DB에서 페이지를 매번 만들고 있을 가능성이 거의 확실하므로 거기부터 보면 됩니다.
제 눈엔 빠른데 여기선 점수가 나쁘게 나옵니다: 대개 이미 데워진 캐시에서, 서버와 지리적으로 가까운 위치에서, 데스크톱 회선으로 보고 계셔서입니다. 저희 측정은 다른 네트워크에서 날아가는 콜드 상태의 단일 요청입니다. 그 차이가 정확히 첫 방문 모바일 사용자가 겪는 경험입니다.
속도가 구글 순위에 영향을 주나요?: 줍니다. 다만 크지 않습니다. Core Web Vitals는 실제 신호지만 주로 적합성이 비슷한 페이지들 사이의 동점 처리로 작동합니다. 속도의 더 큰 효과는 이탈률과 전환율 쪽이고, 보통은 그게 투자할 더 나은 이유입니다.