Trang sản phẩm WooCommerce thường tải ở mức chấp nhận được. Trang cửa hàng, danh sách danh mục và kết quả tìm kiếm thì thường không, và chủ cửa hàng hay ngạc nhiên vì từng sản phẩm riêng lẻ có vẻ ổn. Khác biệt nằm ở phép nhân. Trang sản phẩm hiển thị một ảnh chính. Trang danh mục hiển thị hai mươi bốn sản phẩm sẽ hiển thị ít nhất hai mươi bốn ảnh, và thường gấp đôi khi tính cả hiệu ứng di chuột và ảnh xem trước của thư viện.

Phép nhân đó là lý do trang danh mục thường là thứ chậm nhất trong một cửa hàng, và cũng là lý do đây là những trang quan trọng nhất về mặt thương mại. Chúng đứng giữa một khách vừa tới và một khách tìm được thứ để mua.

Khuôn mẫu đằng sau phần lớn danh mục chậm: giao diện yêu cầu một kích thước ảnh thu nhỏ mà WordPress chưa bao giờ tạo ra, nên trình duyệt tải bản gốc đầy đủ rồi thu nhỏ ngay trong trang. Hai mươi bốn sản phẩm, mỗi sản phẩm gửi một bức ảnh hai megabyte để hiển thị ở ba trăm pixel, cho ra trang danh mục nặng năm mươi megabyte, chấm điểm kém bất kể bạn thêm bao nhiêu bộ nhớ đệm.

Vì sao trang danh mục hành xử khác

Ba thứ cộng hưởng trên trang danh sách mà trang sản phẩm không có.

Số lượng. Mỗi sản phẩm trong lưới đóng góp ít nhất một yêu cầu ảnh. Thiết lập mặc định của WooCommerce thường hiển thị mười sáu hoặc hai mươi bốn sản phẩm mỗi trang, và cửa hàng lớn hơn còn tăng con số đó để giảm phân trang.

Ảnh di chuột và ảnh thư viện. Nhiều giao diện tải trước một ảnh thứ hai cho mỗi sản phẩm phục vụ hiệu ứng đổi ảnh khi di chuột. Việc này âm thầm nhân đôi số ảnh trên trang, và vì ảnh thứ hai không bao giờ hiển thị cho tới khi có tương tác, nó chẳng đóng góp gì cho lần hiển thị đầu mà vẫn tốn đúng ngần ấy băng thông.

Bố cục không ổn định. Những lưới không dành sẵn chỗ cho ảnh sẽ xê dịch khi từng ảnh tới. Trên trang sản phẩm, một lần dịch chuyển còn chịu được. Trên lưới hai mươi bốn ô, chuyển động tích lũy chính là thứ tạo ra điểm Cumulative Layout Shift tệ, và cảm giác là trang cứ nhảy trong lúc bạn cố bấm.

Hệ quả là trang danh mục trượt Core Web Vitals vì những lý do trang sản phẩm không có, và tối ưu mẫu trang sản phẩm chẳng giúp gì cho chúng.

Sự lệch kích thước gây ra phần lớn vấn đề

WordPress tạo một bộ kích thước ảnh khi tải lên. WooCommerce đăng ký thêm bộ của nó. Rồi giao diện đăng ký thêm nữa. Thứ trình duyệt thực sự nhận phụ thuộc vào việc mẫu trang yêu cầu kích thước nào trong số đó, và kích thước ấy có tồn tại hay không.

Kiểu hỏng này rất im lặng. Nếu giao diện yêu cầu một kích thước được đăng ký sau khi bạn đã tải sản phẩm lên, WordPress chưa từng tạo nó, nên nó rơi về bản gốc đầy đủ. Trang vẫn trông đúng, vì trình duyệt thu nhỏ ảnh cho vừa. Chỉ là nó đang chuyển vài megabyte để hiển thị một ảnh thu nhỏ.

Bạn có thể phát hiện điều này mà không cần công cụ nào. Mở một trang danh mục, mở bảng network, và sắp xếp các yêu cầu ảnh theo dung lượng. Nếu dung lượng truyền gần bằng dung lượng file gốc thay vì chỉ là một phần nhỏ, kích thước sai đang được phục vụ. So sánh kích thước thực của một ảnh đã tải với khoảng không nó chiếm trên màn hình. Một bức ảnh tới với chiều rộng hai nghìn pixel để lấp một ô ba trăm pixel chính là toàn bộ vấn đề gói trong một quan sát.

Cách sửa là hoặc tạo lại ảnh thu nhỏ để các kích thước được yêu cầu tồn tại, hoặc phục vụ đúng kích thước ngay lúc phân phối để câu hỏi đó không bao giờ đặt ra.

Tải trễ, và chỗ nó đi chệch

WordPress mặc định tải ảnh theo kiểu trễ, điều này giúp trang danh mục nhiều hơn hầu hết mọi loại trang khác, vì phần lớn một lưới dài nằm dưới màn hình đầu.

Hai sai lầm làm hỏng lợi ích đó.

Tải trễ hàng đầu tiên. Những ảnh nhìn thấy ngay khi vào trang nên được tải luôn. Nếu ảnh lớn nhất bị tải trễ, trình duyệt phát hiện nó muộn, và vì nó thường là phần tử Largest Contentful Paint, phép đo bị ảnh hưởng trực tiếp. Phần lớn giao diện sai ở đây vì áp dụng tải trễ đồng loạt cho mọi ô sản phẩm.

Plugin tải trễ đánh nhau với cơ chế gốc. Chạy một plugin tự thêm cơ chế tải trễ chồng lên cơ chế của trình duyệt sẽ tạo ra những ảnh không bao giờ tải, tải hai lần, hoặc nhấp nháy. Nếu bạn đã cài plugin hiệu năng, hãy kiểm tra xem nó có đang lặp lại việc trình duyệt vốn đã làm hay không.

Phân phối: phần có khả năng mở rộng

Tạo lại ảnh thu nhỏ sửa được danh mục hôm nay. Nó không sửa được danh mục tháng sau, khi một nhà cung cấp mới gửi ảnh với tỉ lệ khác, hoặc khi bạn đổi giao diện và các kích thước cần thiết lại thay đổi.

Biến đổi ảnh lúc phân phối tránh được vòng luẩn quẩn đó. Bản gốc giữ nguyên như lúc tải lên, và kích thước phục vụ do URL quyết định chứ không phải do những gì đã tạo ra từ nhiều tháng trước. Đổi lưới thì đổi tham số. Không có lượt tạo lại nào, và không có rủi ro một kích thước thiếu rơi về bản gốc đầy đủ.

Điều này hợp với danh mục đặc biệt tốt, vì cùng một bức ảnh sản phẩm thường xuất hiện ở ba kích thước: ô lưới, ảnh trang sản phẩm, và khung phóng to hoặc lightbox. Theo mô hình tính tiền trên mỗi ảnh, đó là ba khoản cho mỗi sản phẩm. Theo mô hình của Cloudflare, đó là ba biến thể riêng biệt bất kể bạn có bao nhiêu sản phẩm, và các yêu cầu lặp lại trong tháng không tốn gì.

Bài so sánh của chúng tôi giữa Cloudflare Image Transformations và các plugin ảnh WordPress bàn về khác biệt giữa các mô hình tính phí và cái nào hợp với hình dạng thư viện nào.

Nên đổi gì, theo thứ tự

Hãy làm theo trình tự. Mỗi bước đều đo được riêng, và làm lộn xộn thì khó biết cái gì đã giúp.

Bắt đầu bằng việc xác định bạn có bị lệch kích thước hay không, vì nếu có thì mọi thứ khác chẳng nghĩa lý gì cho tới khi sửa xong. Kiểm tra dung lượng truyền của ảnh trong lưới so với khoảng không chúng chiếm.

Sau đó giảm số ảnh trang yêu cầu. Tắt ảnh di chuột nếu giao diện tải trước chúng và bạn sống được không cần hiệu ứng đó. Cân nhắc xem hai mươi bốn sản phẩm mỗi trang có phục vụ ai không, hay mười sáu với tốc độ tải nhanh hơn lại chuyển đổi tốt hơn.

Sau đó sửa ranh giới tải trễ để hàng đầu tiên nhìn thấy được tải ngay còn mọi thứ bên dưới thì không.

Sau đó xử lý phần phân phối, để kích thước phục vụ khớp với kích thước hiển thị và vẫn đúng khi danh mục thay đổi.

Chỉ sau tất cả những việc đó thì bộ nhớ đệm mới giúp đáng kể. Đệm một trang chậm chỉ khiến nó chậm một cách ổn định chứ không nhanh, và đây lại là bước người ta với tới đầu tiên vì dễ cài nhất.

Về bức tranh rộng hơn ngoài ảnh, bài hiệu năng WooCommerce bàn về truy vấn cơ sở dữ liệu, gánh nặng plugin và các mảnh không được đệm cũng làm cửa hàng chậm.

Đo cho đúng

Chủ cửa hàng thường biết cửa hàng có vẻ chậm nhưng không biết nguyên nhân nào trong cả tá khả năng là thủ phạm. Đoán mò thì đắt, vì những cách sửa hiển nhiên chính là những cách đã thử rồi.

Mecanik thực hiện kiểm tra hiệu năng WordPress đo riêng các trang danh mục thay vì kiểm tra trang chủ rồi coi như xong, và đảm nhận việc triển khai qua công việc phát triển WordPress khi cách khắc phục vượt quá phần cấu hình. Nếu chính các trang danh mục đang làm bạn mất khách, đó là nơi phép đo nên bắt đầu.

Bài viết liên quan: WooCommerce chậm: nguyên nhân thật sự và cách sửa , Chuyển đổi website không mất traffic: hướng dẫn 2026 , Cloudflare Image Transformations vs plugin WordPress , Phát triển website thương mại điện tử: Shopify so với giải ., GEO cho thương mại điện tử: dữ liệu sản phẩm trong AI

Câu hỏi thường gặp

Vì sao trang danh mục WooCommerce chậm hơn trang sản phẩm? Trang sản phẩm tải một ảnh chính. Trang danh mục tải một ảnh cho mỗi sản phẩm, thường nhân đôi vì ảnh di chuột, nên hai mươi bốn sản phẩm có thể thành bốn mươi tám yêu cầu ảnh. Cùng cách xử lý ảnh đó vô hại trên trang sản phẩm nhưng cộng dồn rất tệ trên một lưới.

Làm sao biết WooCommerce đang phục vụ sai kích thước ảnh? Mở một trang danh mục và bảng network của trình duyệt, rồi so dung lượng truyền của ảnh trong lưới với file gốc đã tải lên. Nếu chúng xấp xỉ nhau thay vì chỉ bằng một phần nhỏ, giao diện đang yêu cầu kích thước WordPress chưa từng tạo và bản gốc đầy đủ đang bị thu nhỏ trong trình duyệt.

Nên tạo lại ảnh thu nhỏ hay biến đổi ảnh lúc phân phối? Tạo lại sửa được danh mục hiện tại nhưng phải lặp lại mỗi khi đổi kích thước hoặc đổi giao diện. Biến đổi lúc phân phối quyết định kích thước từ URL, nên vẫn đúng khi đổi giao diện và khi có ảnh mới, mà không cần lượt tạo lại nào.

Tải trễ giúp hay hại trang danh mục WooCommerce? Nó giúp, vì phần lớn lưới dài nằm dưới màn hình đầu, nhưng hàng đầu tiên nhìn thấy nên tải ngay. Tải trễ bức ảnh lớn nhất đang hiển thị sẽ trực tiếp làm chậm phép đo Largest Contentful Paint, và đây là mặc định phổ biến của nhiều giao diện.

Bao nhiêu sản phẩm mỗi trang là tốt nhất cho hiệu năng? Ít ảnh hơn thì trang nhanh hơn, nhưng phân trang nhiều hơn thì phải bấm nhiều hơn để duyệt. Mười sáu đến hai mươi bốn là mức thường thấy. Con số đó ít quan trọng hơn nhiều so với việc mỗi ảnh có đúng kích thước hay không, vì một lưới hai mươi bốn ảnh đúng cỡ vẫn thắng một lưới mười hai ảnh quá cỡ.