사이트 속도는 이렇게 잡습니다 — 코어 웹 바이탈 실무

코어 웹 바이탈이라는 게 도대체 뭔가요?

저희가 사이트를 만들 때 가장 먼저 챙기는 게 코어 웹 바이탈입니다. 구글이 '사용자가 실제로 느끼는 빠르기'를 숫자 세 개로 정리한 지표인데요, 어렵게 들리지만 뜻은 단순합니다. LCP는 화면에서 가장 큰 콘텐츠(보통 대표 이미지나 큰 제목)가 보이기까지 걸리는 시간입니다. 2.5초 안에 떠야 좋다고 봅니다. INP는 방문자가 버튼이나 메뉴를 누른 뒤 화면이 반응하기까지의 지연으로, 200밀리초 안이면 답답하지 않습니다. CLS는 로딩 중 화면이 얼마나 밀리느냐로, 0.1 이하가 안정적입니다.

세 숫자를 따로 외울 필요는 없습니다. 정리하면 빨리 뜨고, 누르면 바로 반응하고, 읽는 도중 화면이 점프하지 않는다 — 이 세 가지를 기계가 채점한 게 코어 웹 바이탈입니다. 사람이 "이 사이트 답답하네"라고 느끼는 순간을 숫자로 바꿔 놓은 것이라고 보면 됩니다.

속도가 검색이나 매출에 진짜 영향을 주나요?

두 갈래로 영향을 줍니다. 첫째는 검색입니다. 구글은 페이지 경험을 순위 신호 중 하나로 쓰고, 코어 웹 바이탈이 거기 들어갑니다. 다만 저희는 "속도만 잡으면 1등 한다"고 말하지 않습니다. 콘텐츠 품질이 더 큰 요인이라, 속도는 같은 품질일 때 갈리는 가점에 가깝습니다.

둘째, 더 즉각적인 영향은 이탈과 전환입니다. 페이지가 늦게 뜨면 방문자는 기다리지 않고 뒤로 갑니다. 광고비를 써서 데려온 사람이라도, 첫 화면이 안 뜨는 몇 초 사이에 그냥 나갑니다. 즉 느린 사이트는 같은 방문자 수로 더 적은 문의·구매를 만듭니다. 그래서 저희는 속도를 '기술 점수'가 아니라 '새는 매출을 막는 일'로 다룹니다. 이 관점은 프런트엔드를 만드는 방식에서 더 풀어 두었습니다.

가장 먼저 손대는 곳은 어디인가요?

거의 항상 이미지입니다. 무거운 사이트를 열어 보면 전체 용량의 절반 이상이 이미지인 경우가 흔합니다. 저희가 하는 일은 세 가지입니다. 첫째, JPG·PNG를 WebP나 AVIF로 바꿉니다. 같은 화질에서 용량이 크게 줄어 가장 효과가 빠릅니다. 둘째, 표시 크기에 맞게 줄여서 내보냅니다. 화면에서 가로 400px로 보일 사진을 카메라 원본 2000px 그대로 올리는 일이 정말 많은데, 이것만 고쳐도 LCP가 눈에 띄게 좋아집니다.

셋째, lazy 로딩입니다. 스크롤을 내려야 보이는 아래쪽 이미지는 처음부터 받지 않고, 화면에 가까워질 때 불러옵니다. 반대로 첫 화면의 대표 이미지는 오히려 우선 로딩으로 당겨서 LCP를 빠르게 만듭니다. "전부 lazy"가 아니라, 첫 화면은 당기고 나머지는 미루는 게 핵심입니다.

폰트랑 스크립트는 왜 줄이라고 하나요?

외부에서 불러오는 것 하나하나가 다 '추가 통화'이기 때문입니다. 멋진 웹폰트를 두세 종 쓰면 그만큼 파일을 더 받아야 하고, 폰트가 늦게 도착하면 글자가 깜빡이거나(FOUT) 잠깐 안 보입니다. 저희는 꼭 필요한 굵기만 골라 넣고, 가능하면 폰트 파일을 우리 서버에서 직접 제공해 외부 호출을 줄입니다.

스크립트는 더 무겁습니다. 채팅 위젯·광고·분석 태그·각종 플러그인을 무심코 다 붙이면, 이 코드들이 브라우저를 점유해 INP를 망칩니다. 누르긴 눌렀는데 화면이 한 박자 늦게 반응하는 사이트는 대개 스크립트가 너무 많은 경우입니다. 그래서 저희는 "이 스크립트가 정말 필요한가, 지금 당장 필요한가"를 따져 첫 로딩에서 빼거나 뒤로 미룹니다. 이 절제가 저희가 만든 사이트들이 가벼운 이유입니다.

캐싱이랑 압축은 뭘 하는 건가요?

둘 다 '같은 걸 두 번 보내지 않기'와 '작게 보내기'입니다. 캐싱은 한 번 받은 이미지·CSS·폰트를 방문자 브라우저에 저장해 두는 겁니다. 그러면 다음 페이지나 재방문 때 다시 받지 않아 거의 즉시 뜹니다. 저희는 자주 안 바뀌는 파일에는 긴 캐시를, 자주 바뀌는 파일에는 짧은 캐시를 걸어 둡니다.

압축은 서버가 파일을 보낼 때 gzip이나 brotli로 묶어 작게 만드는 겁니다. 글자로 된 파일(HTML·CSS·JS)은 압축이 특히 잘 들어서, 설정 한 번으로 전송량이 크게 줄어듭니다. 둘 다 한 번 제대로 걸어 두면 이후로는 자동으로 작동하는, 가성비가 가장 높은 작업입니다.

화면이 밀리는 건 어떻게 막나요?

CLS, 즉 레이아웃이 밀리는 현상은 크기를 모르는 요소가 늦게 끼어들 때 생깁니다. 이미지에 가로·세로 칸을 미리 잡아두지 않으면, 사진이 도착하는 순간 그만큼 아래 내용을 밀어냅니다. 글을 읽다가, 또는 버튼을 누르려는 순간 화면이 점프해 엉뚱한 걸 누르게 되는 그 경험이 바로 CLS입니다.

막는 법은 의외로 단순합니다. 모든 이미지·동영상에 width·height(또는 aspect-ratio)를 지정해 자리를 미리 비워 둡니다. 광고나 임베드처럼 늦게 오는 요소에도 빈 공간을 확보해 둡니다. 폰트가 바뀌며 글이 출렁이지 않게 대체 폰트의 자리도 맞춰 둡니다. 저희는 이걸 디자인 단계부터 약속으로 정해 두기 때문에, 완성 후 화면이 튀는 일이 거의 없습니다.

속도는 어떻게 측정하고 확인하나요?

비싼 도구 없이 무료로 충분합니다. PageSpeed Insights에 주소를 넣으면 LCP·INP·CLS 점수와 "무엇을 고치면 몇 초 빨라지는지"를 모바일·데스크톱으로 나눠 보여줍니다. 저희는 작업 전후로 이걸 찍어 변화를 확인합니다. 구글 서치 콘솔의 코어 웹 바이탈 보고서는 실제 방문자 데이터로 페이지를 '좋음/개선 필요/나쁨'으로 묶어 줍니다.

중요한 건 두 가지를 같이 본다는 점입니다. PageSpeed는 한 번 측정한 실험실 값이라 깔끔하게 나와도, 실제 방문자(느린 기기·약한 통신)의 서치 콘솔 데이터는 다를 수 있습니다. 실험실과 실사용자를 겹쳐 봐야 진짜 문제가 보입니다. 속도는 검색 노출과도 맞닿아 있어, 저희는 SEO 작업과 한 흐름으로 같이 다룹니다. 일하는 전체 순서가 궁금하면 우리는 이렇게 합니다를 보시면 됩니다.

참고로 저희가 측정 결과를 정리할 때 쓰는 표 형태는 이렇습니다. 아래는 권장 기준과 판정 방식을 보여주는 예시 출력으로, 실제 점수는 사이트마다 다릅니다.

$ psi check https://example.kr --strategy=mobile

  지표    측정(예시)   권장 기준      판정
  ─────────────────────────────────────────────
  LCP     2.3 s        ≤ 2.5 s        좋음
  INP     180 ms       ≤ 200 ms       좋음
  CLS     0.14         ≤ 0.10         개선 필요  ← 이미지 자리 미지정

  # 다음 작업: 미디어에 width/height 지정 → CLS 재측정
  # 권장 기준은 구글 공개 값, 측정치는 형식 예시입니다.

같은 콘텐츠라도 무게가 다르면 결과가 달라집니다. 저희가 속도에 공을 들이는 이유는, 그 차이가 곧 문의 한 건·구매 한 건의 차이로 이어지기 때문입니다.