웹사이트 속도가 매출을 바꾸는 이유

웹사이트를 새로 만들 때 가장 많이 듣는 요청은 "예쁘게 만들어 주세요"입니다. 반대로 몇 달 뒤에 가장 많이 듣는 이야기는 "왜 문의가 안 늘까요"입니다. 두 질문 사이에는 의외로 자주 지목되지 않는 원인이 하나 놓여 있습니다. 속도입니다. 디자인은 눈에 보이니 쉽게 이야기되지만, 느림은 방문자가 조용히 떠나는 방식으로만 드러납니다.

느린 사이트는 항의하지 않습니다. 그냥 사람들이 돌아 나갑니다. 그래서 운영자는 문제를 늦게 알아차립니다. 이 글에서는 "속도가 중요하다"는 당연한 말을 넘어서, 무엇을 어떻게 재고 무엇부터 손대면 되는지를 개발 용어 없이 정리했습니다. 끝까지 읽고 나면 우리 사이트의 상태를 직접 확인하고, 개선 요청을 구체적인 언어로 할 수 있게 됩니다.

1초는 생각보다 비싸다

사람이 화면을 기다리는 인내심은 놀랄 만큼 짧습니다. 여러 실측 연구가 공통적으로 보여 주는 것은, 로딩이 1초에서 3초로 늘어나는 사이에 이탈이 눈에 띄게 증가한다는 사실입니다. 3초를 넘기면 상당수의 방문자는 결과를 보기 전에 뒤로 가기를 누릅니다. 광고비를 들여 데려온 방문자라면, 그 이탈은 그대로 비용이 됩니다.

중요한 건 이 손실이 균등하게 발생하지 않는다는 점입니다. 가장 먼저 떠나는 사람은 처음 방문한 사람, 즉 아직 우리를 신뢰할 이유가 없는 사람입니다. 단골은 조금 느려도 기다립니다. 새로운 고객은 기다리지 않습니다. 그래서 속도 문제는 "전체 트래픽이 조금 줄어드는" 문제가 아니라, "신규 고객이 유독 안 남는" 문제로 나타납니다.

느린 사이트에서 가장 먼저 이탈하는 사람은, 우리가 가장 얻고 싶었던 첫 방문자입니다.

여기에 검색 노출이 겹칩니다. 구글은 오래전부터 페이지 경험을 순위 신호 중 하나로 쓴다고 밝혀 왔습니다. 속도가 단독으로 순위를 뒤집지는 않지만, 콘텐츠 품질이 비슷한 두 페이지 사이에서는 저울을 기울입니다. 느린 사이트는 방문자를 잃고, 그 결과로 노출까지 잃습니다. 손실이 두 번 발생하는 구조입니다.

코어 웹 바이탈, 개발 용어 없이 읽기

구글은 사용자가 체감하는 속도를 세 가지 지표로 정리했습니다. 코어 웹 바이탈(Core Web Vitals)이라고 부릅니다. 이름은 낯설지만 각각이 묻는 질문은 아주 상식적입니다.

LCP — "가장 중요한 게 언제 보이나"

화면에서 가장 큰 요소, 보통 대표 이미지나 큰 제목이 언제 나타나는지를 잽니다. 방문자가 "아, 로딩됐네"라고 느끼는 순간과 거의 일치합니다. 2.5초 이내가 양호, 4초를 넘기면 개선이 필요합니다. 대개 원인은 하나입니다. 대표 이미지가 너무 무겁습니다.

INP — "눌렀을 때 바로 반응하나"

버튼이나 메뉴를 눌렀을 때 화면이 반응하기까지 걸리는 시간입니다. 200밀리초 이내면 "즉각 반응한다"고 느끼고, 그보다 느리면 한 번 더 누르게 됩니다. 두 번 눌린 신청 버튼은 중복 문의가 되고, 사용자에게는 고장으로 기억됩니다.

CLS — "읽는 중에 화면이 밀리지 않나"

글을 읽으려는 순간 이미지나 광고가 뒤늦게 로딩되면서 내용이 아래로 밀리는 현상입니다. 누르려던 버튼이 어긋나 다른 것이 눌리는 경험이 여기서 나옵니다. 셋 중 방문자를 가장 확실하게 짜증나게 만드는 지표이고, 동시에 고치기는 가장 쉬운 편입니다. 이미지에 가로·세로 크기를 미리 지정해 두면 브라우저가 자리를 비워 둡니다.

기준은 언제나 모바일, 그리고 첫 방문

속도를 점검할 때 가장 흔한 착각은 "내 컴퓨터에서 빠르니 괜찮다"입니다. 사무실 데스크톱은 유선 인터넷에 연결되어 있고, 브라우저에는 이미 우리 사이트의 이미지가 캐시로 남아 있습니다. 즉 우리는 항상 두 번째 방문자로 사이트를 봅니다. 가장 유리한 조건에서요.

실제 방문자의 다수는 지하철에서, 걸으면서, 몇 년 된 스마트폰으로 처음 우리 사이트를 엽니다. 그래서 점검은 모바일과 첫 방문을 기준으로 해야 합니다. 브라우저의 시크릿 창을 쓰면 캐시 없는 첫 방문 상태를 재현할 수 있습니다.

숫자로 확인하려면 두 가지 도구면 충분합니다.

• PageSpeed Insights — 주소만 넣으면 모바일·데스크톱 점수와 세 지표를 함께 보여 줍니다. 실제 사용자 데이터가 쌓인 사이트라면 실측값도 함께 나옵니다.
• Search Console 의 페이지 경험 보고서 — 우리 사이트를 방문한 실제 사용자의 데이터를 페이지 그룹별로 보여 줍니다. 어떤 유형의 페이지가 문제인지 찾는 데 좋습니다.

점수 하나에 매달릴 필요는 없습니다. 90점을 100점으로 만드는 노력보다, 40점을 70점으로 올리는 개선이 매출에는 훨씬 크게 남습니다. 목표는 만점이 아니라 "방문자가 기다리지 않는 상태"입니다.

대개 여기서 느려진다

수많은 사이트를 열어 보면 느림의 원인은 놀랍도록 비슷합니다. 그리고 대부분 큰 재작업 없이 고칠 수 있는 것들입니다.

• 원본 그대로 올린 이미지 — 가장 흔하고, 효과도 가장 큽니다. 스마트폰으로 찍은 5MB 사진이 그대로 올라가 있으면, 화면에는 작게 보여도 전송량은 그대로입니다. 화면 크기에 맞게 줄이고 WebP 같은 최신 형식으로 바꾸면 용량이 10분의 1 수준으로 떨어지는 일이 흔합니다.
• 너무 많은 외부 스크립트 — 광고, 통계, 채팅 위젯, 폰트, 히트맵… 하나씩 추가할 때는 가벼워 보이지만 합치면 무게가 됩니다. 특히 INP 를 망치는 주범입니다. 6개월 넘게 아무도 보지 않은 도구가 있다면 그것부터 지우세요.
• 웹폰트 과다 — 서체 두 종을 굵기별로 모두 불러오면 글자가 뜨기 전 화면이 비어 있게 됩니다. 실제로 쓰는 굵기만 남기고, 한글 폰트는 필요한 문자만 잘라 쓰는 편이 좋습니다.
• 크기가 지정되지 않은 이미지 — CLS 의 거의 유일한 원인입니다. 폭과 높이만 적어 주면 해결됩니다.
• 느린 호스팅 — 서버가 첫 응답을 늦게 주면 그 뒤 모든 최적화가 무의미해집니다. 방문자와 가까운 지역에서 응답하는지, 정적 파일이 CDN 을 타는지 확인해 볼 가치가 있습니다.

이번 주에 해 볼 수 있는 것

전면 개편을 기다릴 필요는 없습니다. 순서대로 하나씩만 해도 체감이 달라집니다.

• 1. 재기 — PageSpeed Insights 에 가장 중요한 세 페이지(홈, 대표 서비스, 문의)를 넣고 모바일 점수를 기록해 둡니다. 개선 전 숫자가 있어야 효과를 말할 수 있습니다.
• 2. 가장 무거운 이미지 한 장 줄이기 — 보통 홈의 대표 이미지입니다. 이 한 장만 제대로 줄여도 LCP 가 눈에 띄게 좋아지는 경우가 많습니다.
• 3. 안 쓰는 스크립트 지우기 — 예전 통계 도구, 쓰지 않는 채팅 위젯, 시험용으로 붙였던 태그를 걷어냅니다.
• 4. 이미지에 크기 지정하기 — 화면이 밀리는 현상이 사라집니다.
• 5. 다시 재기 — 같은 페이지를 같은 조건으로 다시 측정해 차이를 확인합니다.

이 다섯 단계는 대개 하루 안에 끝나고, 그 뒤로는 새 콘텐츠를 올릴 때 이미지만 신경 쓰면 유지됩니다. 속도는 한 번 만드는 성질이 아니라 관리하는 성질입니다. 글을 하나 올릴 때마다 무거운 사진 한 장이 늘어난다면, 반년 뒤 사이트는 다시 느려집니다.

빠른 사이트는 신뢰의 문제다

속도를 기술 문제로만 보면 우선순위에서 늘 밀립니다. 하지만 방문자 입장에서 로딩은 첫인상입니다. 문이 잘 열리지 않는 가게에서 우리는 제품을 의심하게 됩니다. 웹사이트도 같습니다. 빠르게 열리는 사이트는 "이 회사는 일을 꼼꼼히 한다"는 신호를 말없이 보냅니다.

ononc 는 사이트를 만들 때 이미지 최적화와 코어 웹 바이탈을 기본값으로 두고 작업합니다. 이미 운영 중인 사이트의 속도가 신경 쓰이신다면 현재 상태부터 함께 점검해 보셔도 좋습니다. 무엇을 고치면 무엇이 좋아지는지, 숫자로 확인할 수 있게 정리해 드립니다.