같은 검색 결과에서 옆 가게 사이트는 누르자마자 화면이 채워지는데, 우리 사이트는 흰 화면이 한 박자 머물다 뒤늦게 그림이 떠오른다. 그 한 박자 사이에 고객의 절반은 이미 뒤로가기를 누른다. 사이트 속도는 사장님의 막연한 느낌이 아니라, 구글이 정해 둔 코어 웹 바이탈(Core Web Vitals)이라는 세 가지 지표로 정확히 측정된다. 이 지표는 검색 순위에도 직접 반영된다. 작은 회사가 알아야 할 다섯 가지 원칙을 정리했다.
1. 점수 한 줄이 아니라 세 가지 지표를 본다
속도를 '몇 점'이라는 종합 점수 하나로만 보면 무엇을 고쳐야 할지 알 수 없다. 코어 웹 바이탈은 사용자가 실제로 체감하는 세 순간을 따로 측정한다.
- LCP(가장 큰 콘텐츠 표시): 첫 화면의 큰 이미지나 제목이 뜨기까지의 시간. 2.5초 안이 좋음.
- CLS(누적 레이아웃 이동): 화면이 로딩 중 덜컹대며 밀리는 정도. 0.1 이하가 좋음.
- INP(상호작용 응답성): 버튼을 눌렀을 때 반응하기까지의 시간. 200밀리초 안이 좋음.
2. 첫 화면의 가장 큰 그림(LCP)을 먼저 띄운다
고객이 가장 먼저 보는 것은 보통 히어로 영역의 큰 사진이나 제목이다. 이게 늦으면 사이트 전체가 느리게 느껴진다.
- 첫 화면 이미지는 preload로 우선 불러오고, 화면 아래 이미지는 lazy load로 미룬다.
- 웹폰트는 표시 지연을 막기 위해 font-display: swap을 적용한다.
- 서버 응답 자체가 느리면 캐시와 호스팅부터 점검한다. 코드보다 서버가 병목인 경우가 많다.
3. 화면이 덜컹대지 않게 만든다(CLS)
글을 읽으려는 순간 위에서 이미지나 배너가 뒤늦게 끼어들며 본문이 아래로 밀리는 경험은, 고객이 엉뚱한 버튼을 누르게 만들고 신뢰를 깎는다.
- 모든 이미지와 영상에 가로·세로 크기를 미리 지정해 자리를 잡아 둔다.
- 광고·배너·임베드 영역은 들어올 공간을 빈 박스로 먼저 확보한다.
- 버튼이나 폰트가 뒤늦게 바뀌며 레이아웃을 흔들지 않는지 확인한다.
4. 버튼이 곧바로 반응하게 한다(INP)
화면은 떴는데 버튼을 눌러도 한참 먹통이면 고객은 사이트가 멈춘 줄 안다. 대부분의 원인은 너무 무거운 자바스크립트다.
- 당장 필요 없는 스크립트는 뒤로 미루고, 쓰지 않는 플러그인은 걷어낸다.
- 채팅 위젯·통계·광고 태그를 무분별하게 쌓지 않는다. 하나하나가 응답을 늦춘다.
5. 측정은 '실제 고객' 기준으로 한다
내 컴퓨터와 빠른 사무실 와이파이에서는 모든 사이트가 빠르다. 정작 중요한 건 외부에서 모바일로 접속하는 진짜 고객의 환경이다.
- PageSpeed Insights에서 점수보다 '실사용자 데이터(현장 데이터)' 항목을 먼저 본다.
- 구글 서치 콘솔의 코어 웹 바이탈 보고서로 어떤 페이지가 '불량'인지 추적한다.
- 한 번 고치고 끝이 아니라, 콘텐츠가 쌓이고 기능이 늘면 다시 점검하는 주기를 둔다.
속도는 디자인이 아니라 매출의 문제다
0.1초의 지연이 이탈률 한 자리를 바꾸고, 그 이탈이 광고비를 새게 만든다. 코어 웹 바이탈은 사장님이 직접 코드를 만질 필요는 없지만, 무엇을 요구해야 하는지는 알아야 하는 기준이다. CYAN은 작은 회사 웹사이트를 만들 때 처음부터 이 세 지표를 염두에 두고 설계하고, 이미 운영 중인 사이트라면 어디서 한 박자가 새는지 진단해 드린다. 속도는 새로 만들 때 잡는 것이 가장 싸고, 나중에 잡을수록 비싸진다.