사이트 속도 60점에서 98점까지 올린 방법 — 실전 Technical SEO 기록

“예쁘게 만들었는데 왜 주문이 안 들어오죠?”

쇼피파이 스토어를 구축해드리면서 가장 많이 듣는 질문입니다.

고객사들은 현란한 영상과 고품질 사진으로 스토어를 아름답고 보기 좋게 만들면 자연스럽게 매출이 나올 거라고 생각합니다. 국내 대다수의 에이전시들도 그런 방향으로 제작합니다. 시각적으로 화려한 포트폴리오를 만들어야 다음 고객을 유치할 수 있으니까요.

문제는 이 스토어를 실제로 구매하는 사람은 미국의 시골 마을에 사는 소비자라는 점입니다.

2~3MB짜리 고품질 사진을 다운로드하는 데 4~5초씩 걸리는 환경에서, 슬라이드쇼 이미지 12개와 HD 영상을 동시에 로드하는 스토어가 어떻게 보일까요? 화면이 하얗게 멈춘 채 5초, 10초가 지나갑니다. 고객은 기다리지 않습니다. 뒤로가기를 누르고 다른 스토어로 갑니다.

한국은 인터넷이 빠르고 모바일 데이터도 빠르기 때문에 이 문제를 체감하기 어렵습니다. 서울에서 테스트하면 잘 뜨니까요. 하지만 실제 구매자가 있는 미국, 유럽, 호주의 네트워크 환경은 한국과 다릅니다.

그래서 이런 괴리가 생깁니다:

고객은 사이트가 느려서 이탈하는데
고객사는 왜 주문이 안 들어오는지 모릅니다
광고비를 더 쓰거나, 상품이 문제인가 고민합니다
정작 원인은 사이트 속도입니다

이 문제를 10년간 반복적으로 봐왔기 때문에, 쇼피드림에서는 스토어 제작 시 디자인과 속도를 동시에 잡는 것을 원칙으로 합니다.

사이트 속도는 곧 매출입니다

구글은 페이지 로딩 시간이 1초에서 3초로 늘어나면 이탈률이 32% 증가한다고 발표한 적이 있습니다. 5초가 넘으면 90%가 떠납니다.

그리고 구글 검색 순위에도 직접적인 영향을 줍니다. 구글은 Core Web Vitals(LCP, FCP, CLS, INP)를 공식 랭킹 신호로 사용하고 있습니다. 같은 품질의 콘텐츠라면 속도가 빠른 사이트가 검색 상위에 노출됩니다.

쇼피파이 스토어든, 자체 구축 사이트든, 원리는 동일합니다.

PageSpeed 점수, 무엇을 말해주는가

Google PageSpeed Insights에서 측정되는 핵심 지표:

FCP (First Contentful Paint) — 화면에 첫 번째 콘텐츠가 나타나는 시간. 사용자가 "뭔가 로딩되고 있다"고 느끼는 순간
LCP (Largest Contentful Paint) — 가장 큰 콘텐츠(보통 Hero 이미지나 메인 타이틀)가 완성되는 시간. 사용자가 "페이지가 다 떴다"고 느끼는 순간
CLS (Cumulative Layout Shift) — 로딩 중에 요소가 밀리는 정도. 버튼을 누르려는데 갑자기 밀려서 다른 걸 누르는 현상
TBT (Total Blocking Time) — 메인 스레드가 멈춰있는 시간. 스크롤이나 클릭에 반응하지 않는 시간

이 지표들은 쇼피파이, 워드프레스, 자체 구축 사이트 모두 동일하게 적용됩니다. 그리고 이 지표들은 실제 사용자 경험과 직결됩니다. 숫자가 아니라 "고객이 기다리는 시간"입니다.

실제 사례: 모바일 60점에서 98점까지

저희 사이트의 속도 최적화 과정을 공유합니다. 쇼피파이 스토어에서도 동일한 원리가 적용되므로, 원리에 집중해서 읽어주세요.

최적화 전 상태

항목	수치	의미
성능 점수	60점	느린 사이트
FCP	5.1초	첫 콘텐츠가 5초 후에야 보임
LCP	20.7초	메인 콘텐츠가 20초 후에야 완성
이미지	695KB 절감 가능	불필요하게 큰 이미지
폰트	1.7MB 이상	사용하지 않는 폰트까지 로드
렌더링 차단	2,820ms	3초 가까이 아무것도 못 보여줌

LCP 20.7초라는 건 미국의 느린 네트워크에서 메인 이미지가 20초 뒤에야 보인다는 뜻입니다. 한국에서 테스트하면 빠르게 뜨니까 모르고 넘어갈 수 있지만, 실제 구매자 환경에서는 치명적입니다.

이미지 최적화 — 가장 확실하고 안전한 첫 단계

사이트 속도 개선에서 이미지 최적화는 거의 항상 첫 번째로 해야 하는 작업입니다. 레이아웃이 깨질 위험이 거의 없고, 효과가 즉각적이기 때문입니다.

실제로 고객사 스토어를 분석해보면, 속도 문제의 절반 이상이 이미지에서 옵니다. 상품 사진을 DSLR 원본 그대로 올리거나, Hero 배너에 5MB짜리 이미지를 넣는 경우가 흔합니다.

WebP 변환

JPG/PNG 이미지를 WebP로 변환하면 평균 60~80% 용량이 줄어듭니다. 화질 차이는 육안으로 거의 구분되지 않습니다.

쇼피파이에서는 2020년부터 자동 WebP 변환을 지원하고 있지만, 테마에서 직접 업로드한 이미지나 커스텀 섹션의 이미지는 수동 최적화가 필요한 경우가 많습니다.

저희 사이트에서는 슬라이드쇼 12개 + 배경 이미지 3개를 WebP로 변환해서 평균 65~87% 용량을 줄였습니다.

이미지 사이즈 최적화

화면에 200px 크기로 표시되는 이미지에 1000px짜리 원본을 내려보내면 순수한 네트워크 낭비입니다. 미국의 느린 4G 환경에서는 이 차이가 몇 초의 로딩 시간으로 이어집니다.

실제 표시 크기의 1.5~2배 정도로 리사이즈하면 레티나 디스플레이에서도 선명하면서 용량은 크게 줄어듭니다.

쇼피파이에서는 Liquid 필터({{ image | image_url: width: 400 }})를 활용하면 서버에서 자동으로 리사이즈된 이미지를 제공합니다. 이걸 제대로 활용하는 스토어가 생각보다 적습니다.

Lazy Loading 적용

화면에 바로 보이지 않는 이미지는 스크롤할 때 로드하면 됩니다. 첫 화면에 있는 이미지만 즉시 로드하고, 나머지는 나중에 로드합니다.

저희 사이트에서는 슬라이드쇼 첫 이미지만 즉시 로드하고 나머지 11개는 lazy loading으로 처리해서 초기 로드 부담을 크게 줄였습니다.

이미지 최적화만으로 695KB → 78KB, 약 89% 절감 효과를 봤습니다.

폰트 최적화 — 의외로 큰 병목

폰트가 사이트 속도에 얼마나 영향을 주는지는 직접 겪어봐야 체감됩니다.

사용하지 않는 폰트 제거

한글 폰트는 글리프 수가 많아서 파일 하나가 수백 KB에서 1MB를 넘기기도 합니다.

저희 사이트에서는 타이틀용으로 사용하던 한글 폰트 하나가 1.1MB였습니다. 실제로는 4글자에만 쓰이고 있었습니다. 이걸 제거하고 기존 본문 폰트로 대체했더니 1.1MB가 절감됐습니다.

쇼피파이에서도 테마에 포함된 커스텀 폰트가 과도하게 로드되는 경우가 많습니다. Theme settings에서 사용하지 않는 폰트를 제거하거나 시스템 폰트로 대체하면 상당한 속도 개선이 가능합니다.

폰트 통합

같은 폰트의 Regular, Medium, SemiBold, Bold를 각각 별도 파일로 로드하면 네트워크 요청이 4배로 늘어납니다. Variable Font 하나로 통합하면 요청 수가 줄고, 모바일에서 체감 차이가 큽니다.

저희 사이트에서 폰트 4개를 1개로 통합했더니, 파일 크기는 비슷했지만 네트워크 요청이 3개 줄었습니다. 모바일 환경에서 동시 요청 수 감소는 생각보다 큰 차이를 만듭니다.

외부 폰트 서비스 의존 제거

Google Fonts를 사용하면 외부 서버에 연결해야 합니다. DNS 조회, TCP 연결, CSS 다운로드, 폰트 다운로드까지 체인이 길어집니다.

저희 사이트에서는 Google Fonts를 제거하고 폰트를 같은 서버에서 호스팅하도록 변경했더니 렌더링 차단이 750ms 줄었습니다.

쇼피파이에서는 Shopify CDN에서 폰트를 제공하므로 이 문제가 비교적 적지만, 커스텀 테마에서 Google Fonts를 직접 로드하는 경우에는 동일한 문제가 발생합니다.

CSS 최적화 — 한 번 실패하고 배운 것

관리자 페이지용 CSS, 퀴즈 페이지용 CSS가 모든 페이지에서 로드되고 있었습니다. 메인 페이지에서는 한 줄도 사용하지 않는 CSS가 40KB 이상 불필요하게 로드되고 있었습니다.

이걸 각 페이지에서 필요한 CSS만 로드하도록 분리했습니다.

여기서 한 번 실패했습니다. CSS 파일 이름만 보고 "이 페이지에서만 쓰겠지"라고 판단하고 분리했더니, 견적서 페이지와 관리자 페이지 레이아웃이 완전히 깨져버렸습니다. 다른 페이지에서도 해당 CSS를 사용하고 있었던 겁니다.

두 번째에는 CSS 사용처를 전수 조사한 뒤 작업해서 성공했습니다.

교훈: CSS 분리는 반드시 사용처를 전수 조사한 후 진행해야 합니다. 쇼피파이에서도 테마 커스터마이징 시 CSS를 정리할 때 같은 주의가 필요합니다. 특히 Dawn 같은 기본 테마에서 커스텀 섹션을 추가할 때, CSS 의존성을 파악하지 않으면 다른 페이지가 깨지는 경우가 있습니다.

보이지 않는 진짜 원인 — 이게 에이전시 실력의 차이입니다

이미지, 폰트, CSS를 다 최적화했는데도 점수가 62점에서 올라가지 않았습니다.

LCP 요소가 엉뚱한 곳을 가리키고 있었다

Lighthouse 리포트를 자세히 분석해보니, LCP 요소가 Hero 이미지가 아니라 텍스트 요소로 잡히고 있었습니다.

원인은 Hero 슬라이드쇼의 초기 상태가 투명(opacity: 0)으로 설정되어 있었기 때문입니다. 애니메이션 효과를 위해 처음에는 숨겨놓고 JavaScript가 실행된 후에 보여주는 구조였습니다. 브라우저 입장에서는 "보이지 않는 요소"이므로 아무리 이미지를 최적화해도 LCP 후보에서 제외된 것입니다.

첫 번째 슬라이드만 초기 상태에서 바로 보이도록 수정했더니, LCP가 20.7초에서 6초대로 떨어졌습니다.

이런 문제는 이미지 압축으로는 절대 해결되지 않습니다. 렌더링 구조 자체를 이해해야 찾을 수 있는 문제입니다. 이미지를 아무리 작게 만들어도, 브라우저가 "이건 안 보이는 요소"라고 판단하면 의미가 없습니다.

쇼피파이에서도 같은 사례를 자주 봅니다. Hero 배너에 fade-in 애니메이션을 적용하면 Lighthouse가 해당 이미지를 LCP로 인식하지 못합니다. 많은 테마들이 시각적 효과를 위해 이런 구조를 사용하는데, 이것이 속도 점수를 크게 떨어뜨리는 원인이 됩니다.

외부 스크립트가 렌더링을 완전히 막고 있었다

아이콘 라이브러리를 외부 CDN에서 "페이지 로드 전에 반드시 실행"하는 방식으로 로드하고 있었습니다. 모바일 환경에서 외부 서버에 접속해서 92KB 스크립트를 다운로드하는 동안 사이트 전체가 멈추는 상태였습니다.

이걸 필요한 아이콘만 직접 포함하는 방식으로 변경해서 외부 요청을 완전히 제거했습니다.

쇼피파이에서는 불필요한 앱 스크립트가 이 역할을 합니다. 앱을 10개 설치하면 10개의 외부 스크립트가 동시에 로드됩니다. 사용하지 않는 앱이 여전히 스크립트를 로드하고 있는 경우도 많고, 앱을 삭제해도 스크립트가 테마 코드에 남아있는 경우도 있습니다. 저희가 고객사 스토어를 점검할 때 이런 "좀비 스크립트"를 정리하는 것만으로도 1~2초 개선되는 경우가 있습니다.

브라우저에 보내는 데이터 줄이기

웹 페이지는 HTML이 먼저 로드되고, JavaScript와 CSS가 나중에 실행됩니다. 문제는 실제로 필요하지 않는 코드까지 전부 다운로드해야 한다는 점입니다.

저희 사이트에서는 실제로 인터랙션이 필요한 부분(슬라이드쇼, 아코디언 메뉴)만 분리하고, 나머지 정적 콘텐츠는 서버에서 완성된 HTML만 보내도록 구조를 변경했습니다.

결과: 브라우저로 전송되는 코드가 175KB에서 156KB로 줄었습니다.

쇼피파이에서도 동일한 원리가 적용됩니다. 테마에 포함된 JavaScript 중 실제로 해당 페이지에서 사용하지 않는 코드가 많습니다. 특히 jQuery 기반 오래된 테마나, 무거운 슬라이더 라이브러리를 사용하는 경우 JavaScript만 수백 KB에 달하는 경우가 있습니다.

Analytics 지연 로드

Google Analytics, Facebook Pixel 같은 분석/추적 스크립트는 사이트를 보여주는 데 필요한 코드가 아닙니다. 페이지가 다 로드된 후에 실행되도록 지연 로드를 적용하면 초기 렌더링 속도가 개선됩니다.

쇼피파이에서도 Google Tag Manager, Meta Pixel, TikTok Pixel, Klaviyo 등 트래킹 스크립트가 많이 쌓이면 같은 문제가 발생합니다. 가능하면 GTM 하나로 통합 관리하고, 초기 로드에서 제외하는 것이 좋습니다.

실패에서 배운 것

모든 최적화가 성공한 건 아닙니다.

"최적화"가 항상 좋은 건 아닙니다

이미지 자동 최적화 시스템을 적용했더니 오히려 점수가 떨어졌습니다. 원본 이미지가 이미 19KB 수준으로 충분히 작았기 때문에, 최적화 처리 과정의 오버헤드가 절감량보다 컸습니다. 특히 애니메이션이 있는 Hero 영역에서 렌더링 타이밍이 지연됐습니다.

즉시 롤백했고 점수가 복구됐습니다.

이미 충분히 최적화된 부분에 추가 최적화를 적용하면 오히려 역효과가 날 수 있습니다. 매번 측정하고 확인하는 과정이 필수입니다. "이렇게 하면 빨라질 거야"라는 추측이 아니라, 실제 데이터로 검증해야 합니다.

최종 결과

항목	최적화 전	최적화 후	변화
성능 점수	60	98	+38
FCP	5.1초	1.0초	-80%
LCP	20.7초	2.0초	-90%
CLS	0	0.001	완벽
Speed Index	6.3초	3.1초	-51%

미국의 느린 4G + 저사양 모바일 기기를 기준으로 측정한 결과입니다. 실제 사용자 환경에서는 이보다 더 빠르게 느껴집니다.

속도 최적화 체크리스트

사이트 속도를 개선하고 싶다면 아래 순서로 확인해보세요. 쇼피파이 스토어에도 그대로 적용됩니다.

이미지가 WebP로 변환되어 있는가?
이미지 사이즈가 실제 표시 크기에 맞는가? (DSLR 원본 그대로 올리지 않았는가?)
스크롤 아래 이미지에 lazy loading이 적용되어 있는가?
사용하지 않는 폰트가 로드되고 있지 않은가?
외부 서버에서 폰트를 가져오고 있지 않은가?
Hero 영역의 메인 콘텐츠가 초기 렌더링 시 바로 보이는가? (fade-in 때문에 숨겨져 있지 않은가?)
사용하지 않는 앱/플러그인 스크립트가 남아있지 않은가?
삭제한 앱의 "좀비 스크립트"가 테마 코드에 남아있지 않은가?
분석 스크립트(GA, GTM, Pixel)가 지연 로드되어 있는가?
불필요한 CSS가 모든 페이지에서 로드되고 있지 않은가?

이 체크리스트의 절반만 해결해도 체감 속도가 크게 달라집니다.

자주 묻는 질문

사이트가 빠르면 매출이 정말 오르나요?

직접적인 인과관계를 증명하기는 어렵지만, 속도가 느려서 이탈하는 고객을 줄이는 효과는 확실합니다. 특히 광고를 통해 유입된 고객이 사이트 로딩을 기다리다 이탈하면, 광고비가 그대로 낭비됩니다. 같은 광고비를 쓰더라도 사이트가 빠르면 전환율이 높아집니다.

쇼피파이 스토어의 속도도 개선할 수 있나요?

네. 이미지 최적화, 폰트 정리, 불필요한 앱 스크립트 제거, Hero 영역 렌더링 최적화 등은 쇼피파이에서도 동일하게 적용됩니다. 다만 쇼피파이는 서버 인프라를 직접 제어할 수 없어서 서버 응답 시간이나 CDN 설정 같은 부분은 제한됩니다. 테마 코드와 앱 구성을 최적화하는 것이 핵심입니다.

속도 최적화를 하면 디자인이 안 좋아지지 않나요?

잘 하면 디자인 변화 없이 속도만 개선할 수 있습니다. 이미지 포맷 변경, 폰트 로드 방식 변경, 코드 로드 순서 변경 등은 시각적으로 차이가 없습니다. 다만 애니메이션이나 Hero 구조를 건드리면 UX가 달라질 수 있어서 전문적인 판단이 필요합니다.

한 번 최적화하면 영구적인가요?

아닙니다. 새로운 기능 추가, 앱 설치, 이미지 업로드, 테마 업데이트 등으로 속도가 다시 느려질 수 있습니다. 특히 쇼피파이에서 새 앱을 설치할 때마다 스크립트가 추가되므로, 정기적으로 점검하는 것이 중요합니다.

PageSpeed 점수가 왜 측정할 때마다 다른가요?

Lighthouse는 에뮬레이션된 네트워크 환경에서 측정하기 때문에 같은 사이트라도 5~10점 정도 편차가 생길 수 있습니다. 한 번의 측정에 일희일비하기보다 3회 측정 평균으로 판단하는 게 좋습니다.

성능 최적화가 SEO에 실제로 도움이 되나요?

네. 구글은 Core Web Vitals를 공식 랭킹 신호로 사용합니다. 특히 모바일 검색에서 같은 수준의 콘텐츠라면 페이지 경험이 좋은 사이트가 상위에 노출됩니다. 속도가 빠르면 이탈률이 줄어들고 체류 시간이 늘어나서 간접적으로도 SEO에 도움이 됩니다.

사이트 속도 최적화는 “이미지 좀 줄이면 되겠지” 수준이 아닙니다. 렌더링 구조, 폰트 로딩 순서, 스크립트 실행 타이밍, CSS 의존성까지 전체를 이해해야 제대로 된 개선이 가능합니다.

특히 쇼피파이로 해외 판매를 하는 경우, 한국에서 테스트할 때와 실제 구매자 환경에서의 체감 속도 차이를 반드시 인식해야 합니다. 서울에서 빠르다고 미국 시골에서도 빠른 게 아닙니다.

쇼피드림에서는 10년간의 쇼피파이 구축 경험을 기반으로, 디자인과 속도를 동시에 잡는 Technical SEO를 진행하고 있습니다. "예쁜데 느린 사이트"가 아니라 "예쁘고 빠른 사이트"를 만드는 것이 저희가 가장 잘하는 일입니다.

→ 사이트 속도 최적화 / Technical SEO 문의하기

관련 글:

Shopify Payments 사용을 위한 미국 LLC 설립 방법