WooCommerce 상품 페이지는 대체로 무난하게 로드됩니다. 그런데 상점 페이지, 카테고리 목록, 검색 결과는 그렇지 않은 경우가 많고, 개별 상품은 멀쩡해 보이기 때문에 상점 운영자들이 자주 놀랍니다. 차이는 산수입니다. 상품 페이지는 대표 이미지 한 장을 보여 줍니다. 스물네 개 상품을 보여 주는 카테고리 페이지는 최소 스물네 장을, 마우스 오버 효과와 갤러리 미리보기까지 세면 흔히 그 두 배를 보여 줍니다.

이 곱셈이 바로 카탈로그 페이지가 대개 상점에서 가장 느린 곳인 이유이자, 동시에 상업적으로 가장 중요한 페이지인 이유입니다. 방문자가 도착한 시점과 살 것을 찾는 시점 사이에 놓여 있기 때문입니다.

느린 카탈로그 대부분의 공통 패턴: 테마가 WordPress가 생성한 적 없는 썸네일 크기를 요청하고, 브라우저는 원본 전체를 내려받아 페이지 안에서 축소합니다. 스물네 개 상품이 각각 2메가바이트 사진을 삼백 픽셀로 표시하려고 보내면 오십 메가바이트짜리 카테고리 페이지가 되고, 캐시를 아무리 얹어도 점수는 나쁩니다.

카탈로그 페이지가 다르게 동작하는 이유

목록 페이지에서는 상품 페이지에 없는 세 가지가 겹칩니다.

분량. 그리드의 상품마다 최소 한 건의 이미지 요청이 생깁니다. WooCommerce 기본 설정은 페이지당 열여섯 개나 스물네 개를 보여 주는 경우가 많고, 규모가 큰 상점은 페이지 넘김을 줄이려고 그 수를 더 올립니다.

오버 이미지와 갤러리 이미지. 많은 테마가 마우스 오버 전환을 위해 상품마다 두 번째 이미지를 미리 불러옵니다. 이는 페이지의 이미지 수를 조용히 두 배로 만들고, 두 번째 이미지는 상호작용 전에는 보이지 않으므로 초기 렌더링에 아무 기여도 하지 않으면서 같은 대역폭을 씁니다.

레이아웃 불안정. 이미지 자리를 미리 잡아 두지 않는 그리드는 각 이미지가 도착할 때마다 밀립니다. 상품 페이지라면 한 번의 밀림은 견딜 만합니다. 스물네 칸 그리드에서는 누적된 움직임이 나쁜 Cumulative Layout Shift 점수를 만들고, 클릭하려는 순간 페이지가 튀는 경험으로 느껴집니다.

그 결과 카탈로그 페이지는 상품 페이지에 없는 이유로 Core Web Vitals에서 떨어지고, 상품 템플릿을 최적화해도 그쪽에는 아무 도움이 되지 않습니다.

대부분의 원인인 크기 불일치

WordPress는 업로드 시 이미지 크기 묶음을 생성합니다. WooCommerce는 그 위에 자체 크기를 등록합니다. 테마는 거기에 또 등록합니다. 브라우저가 실제로 받는 것은 템플릿이 그중 어떤 크기를 요청하는지, 그리고 그 크기가 존재하는지에 달려 있습니다.

실패 방식은 조용합니다. 상품 업로드 이후에 등록된 크기를 테마가 요청하면 WordPress는 그것을 생성한 적이 없으므로 원본 전체로 되돌아갑니다. 브라우저가 맞춰 축소하므로 페이지는 여전히 제대로 보입니다. 다만 썸네일을 보여 주려고 수 메가바이트를 옮기고 있을 뿐입니다.

도구 없이도 알아챌 수 있습니다. 카테고리 페이지를 열고 네트워크 패널을 연 뒤 이미지 요청을 크기순으로 정렬하십시오. 전송 크기가 원본 업로드 무게의 일부가 아니라 그에 가깝다면 잘못된 크기가 전달되고 있습니다. 로드된 이미지의 본래 치수를 화면에서 차지하는 공간과 비교해 보십시오. 삼백 픽셀 타일을 채우려고 이천 픽셀 너비로 도착하는 사진은 한 번의 관찰로 문제 전체를 보여 줍니다.

해결은 요청된 크기가 존재하도록 썸네일을 다시 생성하거나, 전달 시점에 올바른 크기를 제공해 그 질문이 아예 생기지 않게 하는 것입니다.

지연 로딩, 그리고 어긋나는 지점

WordPress는 기본적으로 이미지를 지연 로딩합니다. 긴 그리드의 대부분이 화면 아래에 있으므로, 이는 거의 어떤 페이지 유형보다 카탈로그 페이지에 도움이 됩니다.

다만 두 가지 실수가 그 이점을 없앱니다.

첫 줄을 지연 로딩하기. 도착 시 보이는 이미지는 즉시 로드해야 합니다. 그중 가장 큰 것을 지연시키면 브라우저가 늦게 발견하고, 그것이 대개 Largest Contentful Paint 요소이므로 측정값이 직접 나빠집니다. 대부분의 테마가 모든 상품 타일에 지연 로딩을 일괄 적용하며 여기서 실수합니다.

네이티브 구현과 싸우는 지연 로딩 플러그인. 브라우저의 방식 위에 자체 지연 로딩을 얹는 플러그인을 돌리면 이미지가 아예 로드되지 않거나, 두 번 로드되거나, 깜빡입니다. 성능 플러그인을 설치했다면 브라우저가 이미 하는 일을 중복하고 있지 않은지 확인하십시오.

전달, 즉 확장되는 부분

썸네일 재생성은 오늘의 카탈로그를 고칩니다. 다음 달은 고치지 못합니다. 새 공급업체가 다른 화면비의 사진을 보내거나, 테마를 바꿔 필요한 크기가 다시 달라질 때는 소용없습니다.

전달 시점에 이미지를 변환하면 이 쳇바퀴를 피합니다. 원본은 업로드된 그대로 남고, 전달되는 크기는 몇 달 전에 생성된 것이 아니라 URL이 정합니다. 그리드를 바꾸면 매개변수를 바꿉니다. 재생성 실행도 없고, 빠진 크기가 원본 전체로 되돌아갈 위험도 없습니다.

이는 카탈로그에 특히 잘 맞습니다. 같은 상품 사진이 보통 세 가지 크기로 나타나기 때문입니다. 그리드 타일, 상품 페이지 이미지, 그리고 확대 또는 라이트박스 보기입니다. 이미지 단위 과금 모델이라면 상품마다 세 건의 청구입니다. Cloudflare 모델이라면 상품 수와 무관하게 세 개의 개별 변형이며, 같은 달 안의 반복 요청은 비용이 들지 않습니다.

Cloudflare Image Transformations와 WordPress 이미지 플러그인 비교에서 과금 모델의 차이와 어떤 형태의 라이브러리에 무엇이 맞는지를 다룹니다.

무엇을 바꿀지, 순서대로

이 항목들을 순서대로 진행하십시오. 각각 따로 측정할 수 있고, 순서를 어기면 무엇이 도움이 됐는지 알기 어려워집니다.

먼저 크기 불일치가 있는지부터 확인하십시오. 있다면 그것이 해결될 때까지 다른 것은 의미가 없습니다. 그리드 이미지의 전송 크기를 그것이 차지하는 공간과 비교하십시오.

그다음 페이지가 요청하는 이미지 수를 줄이십시오. 테마가 오버 이미지를 미리 불러오고 그 효과 없이도 괜찮다면 끄십시오. 페이지당 스물네 개가 누구에게 도움이 되는지, 아니면 열여섯 개로 더 빨리 로드되는 편이 더 잘 팔리는지 생각해 보십시오.

그다음 지연 로딩 경계를 고쳐 첫 번째 보이는 줄은 즉시 로드하고 그 아래는 그러지 않게 하십시오.

그다음 전달을 손보아 전달되는 크기가 표시 크기와 일치하고 카탈로그가 바뀌어도 계속 맞게 하십시오.

캐시가 의미 있게 도움이 되는 것은 이 모든 것 이후입니다. 느린 페이지를 캐시하면 빨라지는 것이 아니라 한결같이 느려질 뿐인데도, 설치가 가장 쉬워 사람들이 가장 먼저 손대는 단계입니다.

이미지를 넘어선 더 넓은 그림은 WooCommerce 성능 에서 데이터베이스 쿼리, 플러그인 오버헤드, 캐시되지 않은 조각 등 상점을 느리게 만드는 다른 요인을 다룹니다.

제대로 측정하기

상점 운영자는 대개 상점이 느리게 느껴진다는 것은 알지만, 열 가지가 넘는 가능한 원인 중 무엇이 문제인지는 모릅니다. 추측은 비쌉니다. 뻔한 해결책은 이미 시도해 본 것들이기 때문입니다.

Mecanik은 홈페이지를 측정하고 끝내는 대신 카탈로그 페이지를 콕 집어 측정하는 WordPress 성능 점검 을 수행하고, 해결책이 설정 범위를 넘어설 때는 WordPress 개발 작업으로 구현까지 맡습니다. 방문자를 잃고 있는 쪽이 카테고리 페이지라면 측정은 거기서 시작해야 합니다.

관련 게시물: WooCommerce가 느린 진짜 이유와 해결 순서 , 트래픽을 잃지 않는 웹사이트 마이그레이션 , Image Transformations와 WordPress 이미지 플러그인 , 이커머스 웹사이트 개발: Shopify vs 커스텀 개발 ., 이커머스 GEO: AI 답변에 실리는 상품 데이터

자주 묻는 질문

WooCommerce 카테고리 페이지가 상품 페이지보다 느린 이유는 무엇인가요? 상품 페이지는 대표 이미지 한 장을 불러옵니다. 카테고리 페이지는 상품마다 한 장을 불러오고 오버 이미지로 흔히 두 배가 되므로, 스물네 개 상품이면 마흔여덟 건의 요청이 될 수 있습니다. 상품 페이지에서는 무해한 같은 처리 방식이 그리드에서는 나쁘게 쌓입니다.

WooCommerce가 잘못된 이미지 크기를 전달하는지 어떻게 아나요? 카테고리 페이지와 브라우저 네트워크 패널을 열고 그리드 이미지의 전송 크기를 원본 업로드와 비교하십시오. 일부가 아니라 비슷하다면 테마가 WordPress가 생성한 적 없는 크기를 요청하고 있고 원본 전체가 브라우저에서 축소되는 것입니다.

썸네일을 다시 생성해야 하나요, 전달 시점에 변환해야 하나요? 재생성은 현재 카탈로그를 고치지만 크기나 테마가 바뀔 때마다 반복해야 합니다. 전달 시점 변환은 URL에서 크기를 정하므로 테마 변경과 새 업로드 이후에도 재생성 없이 계속 맞습니다.

지연 로딩은 WooCommerce 카탈로그 페이지에 도움이 되나요, 해가 되나요? 도움이 됩니다. 긴 그리드의 대부분이 화면 아래에 있기 때문입니다. 다만 첫 번째 보이는 줄은 즉시 로드해야 합니다. 보이는 가장 큰 이미지를 지연시키면 Largest Contentful Paint 측정이 직접 늦어지며, 이는 흔한 테마 기본값입니다.

성능 면에서 페이지당 상품 수는 얼마가 좋은가요? 이미지가 적을수록 페이지는 빨라지지만, 페이지 넘김이 늘면 둘러보는 클릭도 늘어납니다. 열여섯에서 스물넷이 일반적입니다. 숫자 자체보다 각 이미지가 올바른 크기인지가 훨씬 중요하며, 알맞은 크기의 스물넷이 과도한 크기의 열둘을 이깁니다.