사이트 속도가 매출에 미치는 영향: 숫자로 보는 성능

속도는 편의가 아니라 매출입니다

느린 사이트는 문이 뻑뻑한 가게와 같습니다. 아무도 안에 무엇이 있는지 궁금해하지 않고 옆 가게로 들어갑니다.

Google의 Core Web Vitals 기준은 여기에 분명한 선을 긋습니다. 최대 콘텐츠 렌더링 시간(LCP)은 2.5초 미만이어야 하고, 레이아웃 이동(CLS)은 0.1 미만이어야 하며, 상호작용 지연은 200밀리초를 넘지 않아야 합니다. 이 기준은 임의로 정한 것이 아니라 실제 사용자 행동에서 도출된 것입니다.

모바일에서는 1초가 늘어날 때마다 포기하는 사람이 늘어납니다. 그리고 그 손실은 조용히 일어납니다. 사이트가 느려서 사지 않았다고 말해 주는 사람은 아무도 없습니다.

튀르키예의 현황

현장에서 보면 중소기업 사이트의 상당수가 모바일에서 여는 데 5초 이상 걸립니다. 원인은 대개 같은 세 가지로 나뉩니다.

최적화되지 않은 이미지. 카메라에서 바로 올린 4 MB 사진 한 장만으로도 페이지가 무너집니다. 같은 이미지를 알맞은 크기의 WebP로 바꾸면 150 KB가 될 수 있습니다.

무거운 테마와 플러그인. 기성 테마는 쓰지도 않는 기능 수십 가지를 함께 가져옵니다. 플러그인이 스무 개 설치된 사이트에서는 모든 페이지가 필요 없는 파일까지 내려받습니다.

성능이 낮은 호스팅. 사용자를 과도하게 수용한 공유 호스팅 요금제에서는 서버의 첫 응답 시간만으로도 몇 초가 걸릴 수 있습니다.

어디서부터 시작할까요

먼저 측정하십시오. PageSpeed Insights에 사이트를 넣고 모바일 탭을 보십시오. 데스크톱 점수는 착각을 불러옵니다. 그다음 아래 순서대로 작업하십시오.

이미지. WebP로 전환하고, 실제 표시 크기로 제공하며, 화면 아래쪽에 있는 이미지는 지연 로딩하십시오. 대부분의 사이트에서는 이 단계만으로도 페이지 용량이 절반으로 줄어듭니다.

글꼴. Google Fonts에서 불러오는 글꼴 패밀리마다 연결과 대기 시간이 추가됩니다. 글꼴은 자체 서버에서 제공하고 실제로 쓰는 굵기만 불러오십시오.

렌더링 차단 파일. 화면 상단을 그리는 데 필요하지 않은 CSS와 JavaScript는 나중에 불러와야 합니다.

캐싱과 압축. 서버에서 Brotli 압축과 올바른 캐시 헤더를 설정하면 코드를 한 줄도 바꾸지 않고 측정 가능한 개선 효과를 얻을 수 있습니다.

속도의 SEO 측면

속도만으로 1위에 오를 수는 없습니다. 여전히 콘텐츠와 권위가 더 중요합니다. 하지만 Core Web Vitals는 품질이 비슷한 두 페이지 사이에서 승부를 가르는 요소입니다.

진짜 영향은 간접적입니다. 느린 페이지에서 이탈한 방문자는 Google에 그 결과가 유용하지 않았다는 신호를 보냅니다. 이런 행동이 쌓이면 순위가 떨어집니다.

또 하나의 실질적인 문제가 있습니다. Google도 사이트를 크롤링하는 데 시간을 씁니다. 느린 사이트에서는 크롤링 예산으로 더 적은 페이지를 처리하게 되고, 새 콘텐츠의 색인이 늦어집니다. 200페이지 규모의 업종 사이트라면 이 차이가 눈에 띕니다.

현실적인 목표

모든 사이트를 100/100점으로 만드는 것은 가능하지도, 필요하지도 않습니다. 의미 있는 목표는 모바일 PageSpeed 점수 90점 이상, 실제 사용자 기준 LCP 2.5초 미만입니다.

저희는 납품하는 모든 프로젝트에서 오픈 전에 이 측정을 진행하고 결과를 서면으로 고객에게 전달합니다. 견적을 받을 때 같은 것을 요구하십시오. “납품 시점의 모바일 PageSpeed 점수는 몇 점입니까?” 이 질문에 숫자로 답하지 못하는 업체는 속도를 전혀 고려하지 않은 것입니다.