WooCommerce 성능 조사는 거의 언제나 같은 장면에서 시작됩니다. 상점 주인은 이미 더 빠른 호스팅으로 옮겼고, 캐시 플러그인을 설치했고, 이미지 최적화 도구까지 샀습니다. 그런데도 사이트는 여전히 느립니다. 그래서 WooCommerce는 원래 무거운 물건이라고 결론 내리고 그쯤에서 포기합니다.

WooCommerce가 회사 소개용 사이트보다 무거운 것은 사실입니다. 모든 페이지가 장바구니를 안고 다닐 수 있는 이상 그 부담은 피할 수 없습니다. 하지만 로딩에 육 초가 걸리는 상점이 겪는 문제는 그 부담이 아닙니다. 훨씬 구체적인 무언가가 벌어지고 있고, 제 경험상 그것은 거의 언제나 네 가지 중 하나입니다.

요약: 상점이 느린 이유는 장바구니와 결제 페이지를 페이지 캐시에 올릴 수 없기 때문이고, 옵션 테이블이 자동으로 읽히는 쓰레기 데이터로 비대해졌기 때문이며, 상품 쿼리가 인덱스 없는 메타데이터 테이블을 훑기 때문이고, 서른 개의 플러그인이 각자 자기 스크립트를 모든 페이지에 얹기 때문입니다. 호스팅은 가장 먼저 바꿀 것이 아니라 가장 나중에 바꿀 것입니다.

상점이 블로그와 다른 이유

한 가지 차이만 이해하면 WooCommerce 성능에서 벌어지는 일의 대부분이 설명됩니다.

블로그 글은 모든 방문자에게 동일하므로 한 번 만들어 캐시에서 모두에게 내보낼 수 있습니다. 회사 소개용 사이트가 어떻게 만들었든 대체로 빠른 이유가 그것입니다. 상점은 모든 페이지에서 그렇게 할 수 없습니다. 장바구니는 개인의 것이기 때문입니다. 방문자가 상품 하나를 담는 순간부터 그 페이지는 공유된 사본이 아니라 그 사람의 상태를 비춰야 합니다.

그 결과 장바구니, 결제, 계정 페이지는 페이지 캐시를 완전히 우회하고 요청마다 PHP와 데이터베이스 쿼리를 실행합니다. 그리고 느림이 곧바로 돈으로 이어지는 곳도 바로 그 페이지들입니다. 느린 카테고리 페이지는 구경하던 사람을 잃게 하지만, 느린 결제 페이지는 이미 사기로 마음먹은 사람을 잃게 합니다.

그래서 쓸모 있는 질문은 결코 우리 사이트가 빠른가가 아닙니다. 장바구니에 상품을 담고 로그인한 방문자에게 우리 사이트가 얼마나 빠른가입니다. 그 상태를 콕 집어 측정하십시오. 매출이 걸린 상태가 그것이고, 합성 속도 테스트가 놓치는 상태도 정확히 그것입니다.

실제로 잘못된 네 가지

과적재된 옵션 테이블. WordPress는 요청마다 한 무더기의 옵션을 읽어 들이고, 플러그인은 거기에 마음껏 행을 더합니다. 제거된 플러그인이 자기 행을 남기고 떠나는 것은 예외가 아니라 관행에 가깝습니다. 오래된 상점에서는 이 테이블이 수십 메가바이트의 자동 로드 데이터로 자라며, 결제 페이지를 포함한 모든 페이지 조회에서 그것이 읽힙니다. 눈에 보이지 않고, 계속 쌓이며, 투자 대비 회수가 가장 큰 수정 가운데 하나입니다. 자동으로 읽히는 옵션의 총 용량부터 확인하십시오. 킬로바이트가 아니라 메가바이트 단위라면 진짜 시간을 찾아낸 것입니다.

인덱스 없는 메타데이터를 향한 상품 쿼리. WooCommerce는 오랫동안 상품 속성과 가격, 재고를 다른 모든 것과 공유하는 범용 메타데이터 테이블에 저장해 왔습니다. 큰 카탈로그를 거르거나 정렬한다는 것은 그 테이블을 반복해서 조인한다는 뜻입니다. 상품이 수백 개면 아무도 눈치채지 못합니다. 수만 개가 되면 카테고리와 필터 페이지는 기어가기 시작합니다. 최근 WooCommerce 버전은 바로 이 압력을 덜기 위해 주문 데이터를 전용 테이블로 옮겼고, 주문 이력이 긴 상점에서 그 저장 방식을 켜는 것만으로도 대개 값어치를 합니다.

플러그인과 외부 호출

임계 경로에 올라탄 플러그인 과잉. 문제는 개수 자체인 경우가 드뭅니다. 문제는 대부분의 플러그인이 필요한 곳에서만이 아니라 모든 페이지에서 자기 CSS와 JavaScript를 실어 보낸다는 점입니다. 한 페이지에서만 쓰는 예약 플러그인이 결제 페이지에서도 자기 자원을 불러옵니다. 해결책은 멋이 없습니다. 각 플러그인이 무엇을 싣는지 점검하고, 자기 페이지 밖에서는 자원을 내리고, 기능을 설명할 수 없는 것은 지우십시오.

캐시되지 않은 외부 호출. 실시간 배송료, 세금 조회, 환율 변환, 외부 시스템 재고 확인은 모두 페이지 로드 안쪽에 네트워크 요청을 하나 집어넣습니다. 그 공급자가 느리면 결제가 느려지고, 그 공급자가 멈추면 결제도 멈춥니다. 요청 경로에 있는 모든 외부 호출에는 타임아웃과 캐시와 대체 동작이 필요합니다. 이 설계 없이 연동을 늘리면 남의 장애가 그대로 내 매출의 장애가 됩니다. 서드파티 API 연동 안내에서 이 부분을 어떻게 만들어야 하는지 다룹니다.

실제로 도움이 되는 것들, 순서대로

아래 순서대로 진행하십시오. 하나를 손볼 때마다 다음 측정이 알려 주는 내용이 달라지기 때문입니다.

페이지 캐시가 아니라 오브젝트 캐시. 페이지 캐시는 HTML 페이지 전체를 내보내는 물건이라 장바구니나 결제를 도울 수 없습니다. 영구 오브젝트 캐시는 데이터베이스 쿼리 결과를 메모리에 담아, 페이지 캐시가 건드리지 못하는 바로 그 페이지들을 빠르게 만듭니다. 상점에서는 대개 이것이 단일 항목으로 가장 큰 개선이고, 동시에 가장 자주 건너뛰는 단계입니다. 이미 깔아 둔 캐시 플러그인이 할 일을 다 했다는 인상을 주기 때문입니다.

데이터베이스 정비. 만료된 트랜지언트를 지우고, 삭제된 상품과 주문이 남긴 고아 메타데이터를 걷어 내고, 글 리비전을 줄이십시오. 몇 년을 영업한 상점에서는 이것만으로도 데이터베이스의 상당 부분이 사라지는 일이 흔합니다. 한 번 하고 끝낼 일이 아니라 정기 작업으로 일정에 넣으십시오.

그다음이 호스팅. 캐시와 데이터베이스가 정리된 뒤라면 호스팅은 정말로 중요해집니다. PHP 버전, 쓸 수 있는 메모리, 데이터베이스가 같은 장비에 있는지, 다른 입주자와 자원을 다투는 공유 호스팅에 있는지가 그렇습니다. 그러나 위의 것들을 고치기 전에 호스트를 옮기는 일은 문제를 더 비싼 주소로 이사시키는 것에 지나지 않습니다.

자원은 마지막. 이미지 포맷, 지연 로딩, 스크립트 지연 실행은 할 만한 가치가 있고 대부분의 안내서가 여기서 시작합니다. 다만 그것들이 개선하는 것은 이미 어느 정도 빠르게 나가던 페이지의 로딩 경험입니다. 첫 바이트를 보내기까지 PHP 안에서 사 초를 쓰는 결제 페이지에는 거의 아무것도 해 주지 못합니다.

WooCommerce 성능을 제대로 측정하는 법

합성 점수는 다른 어떤 집단보다 상점 주인을 크게 오도합니다. 그러니 의도를 갖고 측정하십시오.

로그인한 상태에서 장바구니에 물건이 담긴 상태를 시험하십시오. 대부분의 도구는 익명 방문자가 홈페이지에 닿는 장면을 재는데, 그것은 사이트를 통과하는 가장 빠른 경로이며 결제에 대해서는 거의 아무것도 말해 주지 않습니다.

서버 시간과 프런트엔드 시간을 나누십시오. 서버가 HTML을 만드는 데 삼 초를 쓴다면 어떤 이미지 최적화도 그 페이지를 구하지 못합니다. 첫 바이트까지의 시간이 문제의 어느 절반을 안고 있는지, 따라서 위의 어떤 처방이 해당되는지 알려 줍니다.

가능하다면 실험실 데이터보다 현장 데이터를 쓰십시오. 실제 회선과 실제 휴대폰을 쓰는 실제 방문자는 데이터센터에서 돌린 테스트와 다른 그림을 그리며, Core Web Vitals가 평가하는 것은 전자입니다. 지표를 제대로 읽는 방법은 WordPress 성능 감사 가이드 에서, 기준선이 실제로 무엇을 요구하는지는 2026년 Core Web Vitals 에서 다룹니다.

마지막으로, 느린 요청이 벌어지는 동안 데이터베이스를 직접 들여다보십시오. 한 번의 페이지 로드에서 같은 쿼리가 이백 번 실행된 쿼리 로그는 범인을 즉시 지목합니다. 그리고 그 양상은 상품 데이터를 각자 따로 요청하는 플러그인을 여럿 돌리는 상점에서 대단히 흔합니다.

이 작업에 드는 비용

아래 가격은 중간 규모 상점에 대한 영국 에이전시의 전형적인 요율입니다.

구체적인 원인을 짚어 내고 우선순위가 매겨진 수정 목록과 전후 측정치를 제공하는 성능 감사는 보통 900파운드에서 2,500파운드입니다. 이는 진단 성격의 계약이며 따로 사 둘 값어치가 있습니다. 남은 작업이 일주일짜리인지 한 달짜리인지 알려 주기 때문입니다.

흔한 수정, 즉 오브젝트 캐시, 데이터베이스 정리, 플러그인 자원 점검, 외부 호출 캐시화를 구현하는 일은 그동안 얼마나 쌓였는지에 따라 대개 2,000파운드에서 6,000파운드입니다.

더 깊은 작업은 그것이 진짜 개발이기 때문에 비용이 올라갑니다. 큰 카탈로그를 인덱스가 있는 저장 방식으로 옮기거나, 메타데이터를 훑는 필터 시스템을 다시 만들거나, 느린 플러그인을 목적에 맞춘 맞춤 구현으로 대체하는 일은 보통 6,000파운드에서 20,000파운드 사이입니다.

이 모든 숫자보다 중요한 숫자는 느림이 당신에게 물리는 값입니다. 결제 이탈은 로딩 시간과 함께 측정 가능한 수준으로 늘어나므로, 의미 있는 매출을 내는 상점이라면 결제 페이지 하나만으로도 감사 비용을 정당화할 수 있습니다.

점수가 아니라 상점을 고치십시오

Mecanik은 WordPress 개발 서비스 의 일부로 WooCommerce 성능 작업을 하며, 홈페이지가 아니라 로그인한 결제 경로를 측정하는 데서 시작합니다. 상점이 실제로 돈을 잃는 곳이 거기이기 때문입니다.

호스트 교체를 권하기 전에 자동으로 읽히는 옵션, 주문 저장 방식, 쿼리 양상, 외부 호출을 먼저 봅니다. 그리고 개선이 주장이 아니라 검증 가능한 것이 되도록 전후 측정치를 모두 드립니다. 설정이 잘못돼서가 아니라 상점이 플랫폼을 넘어섰기 때문에 느린 것이라면 그 말씀도 드립니다. 그 경계가 어디인지는 Shopify와 맞춤 이커머스 비교 에서 다룹니다. 성장 자체를 계획하는 단계라면 이커머스 사업 확장 글이 주변 결정을 정리해 줍니다.

URL과 상점이 보유한 대략적인 상품 수와 주문 수를 보내 주시면, 위의 네 가지 원인 가운데 어느 쪽에 해당할 가능성이 가장 높은지 알려 드리겠습니다.

관련 게시물: WordPress 해킹: 악성코드 제거와 복구 가이드 , 영국 이커머스 비즈니스 규모 확장 가이드: 2026년 데이터베이스 고속화와 에지 최적화 전략 , Drupal 개발자 채용: 단가, 역량, 검증 방법 , 2026년 영국에서 웹사이트 비용은 얼마인가요? .

자주 묻는 질문

캐시 플러그인을 써도 WooCommerce가 느린 이유는 무엇인가요? 장바구니, 결제, 계정 페이지에는 페이지 캐시를 적용할 수 없습니다. 이 페이지들은 방문자 각자의 상태를 비춰야 하기 때문입니다. 이들은 요청마다 PHP와 데이터베이스 쿼리를 실행하므로, 속도를 올리려면 페이지 캐시가 아니라 오브젝트 캐시와 데이터베이스 작업이 필요합니다.

호스팅을 좋은 곳으로 옮기면 WooCommerce 성능이 해결되나요? 일부만 해결되며 첫 번째 조치가 되어서는 안 됩니다. 옵션 테이블이 비대하고 쿼리에 인덱스가 없고 플러그인이 모든 곳에서 자원을 불러온다면, 좋은 호스팅은 같은 문제를 조금 더 빠르게, 더 비싼 값에 굴릴 뿐입니다. 캐시와 데이터베이스를 먼저 고치고 그다음 호스팅을 다시 평가하십시오.

WooCommerce에서 플러그인은 몇 개부터 너무 많은가요? 개수보다 각각이 무엇을 불러오는지가 더 중요합니다. 자기 페이지에서만 자원을 싣는 얌전한 플러그인 스무 개는, 사이트 전체에 스크립트를 뿌리는 여덟 개보다 해가 적습니다. 각 플러그인이 결제 페이지에 무엇을 더하는지 점검하고, 목적을 아무도 말하지 못하는 것은 지우십시오.

WooCommerce 속도 최적화 비용은 얼마인가요? 우선순위가 매겨진 수정 목록을 포함한 진단 감사는 보통 900파운드에서 2,500파운드입니다. 오브젝트 캐시, 데이터베이스 정리, 자원 점검 같은 흔한 수정의 구현은 대개 2,000파운드에서 6,000파운드이며, 카탈로그나 필터 재작업은 6,000파운드에서 20,000파운드에 이를 수 있습니다.

WooCommerce 성능은 어떻게 측정해야 하나요? 익명으로 홈페이지를 여는 대신, 장바구니에 상품을 담고 로그인한 방문자로 시험하십시오. 서버 응답 시간과 프런트엔드 렌더링을 나누어 어느 절반이 느린지 확인하십시오. 그리고 실험실 점수에만 기대지 말고 실제 방문자에게서 나온 현장 데이터를 쓰십시오.