Tối ưu Core Web Vitals cho website thương mại điện tử

Có một cách gần như chắc chắn để tối ưu Core Web Vitals sai hướng: mở PageSpeed Insights, nhìn vào danh sách gợi ý rồi sửa dần từ trên xuống dưới. Nhiều website bán hàng đã đi con đường đó, mất vài tuần và nhận lại một điểm số đẹp hơn, trong khi khách thật vẫn thấy trang ì ạch như cũ. Bài này đi theo hướng ngược lại: bắt đầu từ dữ liệu người dùng thật, xác định đúng chỗ nghẽn, rồi mới chạm vào mã nguồn. Nội dung viết cho founder và tech lead đang vận hành website thương mại điện tử, không phải cam kết điểm số hay báo cáo của một dự án cụ thể.

Core Web Vitals đo ba khoảnh khắc trong trải nghiệm của khách

Theo tài liệu Web Vitals của Google, ngưỡng đạt là LCP không quá 2,5 giây, INP không quá 200 mili giây và CLS không quá 0,1. Các con số được đánh giá ở phân vị 75, tức ba phần tư lượt truy cập, và tách riêng thiết bị di động với máy tính. Nói theo cách đời thường, LCP hỏi nội dung chính hiện ra có nhanh không, INP hỏi trang có phản hồi khi khách chạm vào không, và CLS hỏi bố cục có nhảy lung tung trong lúc dùng không. Ba câu hỏi độc lập với nhau, đạt một chỉ số không bù được chỉ số khác.

Một điểm rất hay bị hiểu nhầm là điểm Performance trong PageSpeed Insights. Đó là kết quả kiểm thử trong phòng lab, không đồng nghĩa với việc khách thật đều có trải nghiệm tốt. Lighthouse chạy một lần tải trang thông thường nên không đo được INP vì thiếu chuỗi tương tác; TBT chỉ là tín hiệu chẩn đoán, không phải chỉ số thay thế tương đương. Với shop phục vụ khách Việt Nam, phần lớn truy cập đến từ điện thoại tầm trung trên mạng di động, nên con số đo từ một chiếc máy tính cấu hình cao trong văn phòng nói rất ít về trải nghiệm thật.

Đo đúng trước khi sửa bất cứ thứ gì

Nguồn đáng tin nhất là dữ liệu field, tức số đo từ người dùng thật mà Google thu thập qua Chrome UX Report, xem được trong PageSpeed Insights và Search Console. Nếu website chưa có đủ dữ liệu người dùng thật, hãy ghi nhận là thiếu dữ liệu và dùng kết quả lab như phương án tạm, đừng chuyển kết quả lab thành kết luận về người dùng thật.

Tiếp theo, lập bản đồ các nhóm trang đại diện: trang chủ, trang danh mục, trang chi tiết sản phẩm, giỏ hàng và thanh toán. Với mỗi nhóm, chọn URL có lưu lượng hoặc giá trị kinh doanh đáng theo dõi, và kiểm tra thêm những trường hợp nặng như sản phẩm nhiều biến thể hay danh mục rất dài. Khi đo, ghi lại URL, phiên bản triển khai, thiết bị, điều kiện mạng và trạng thái cache, rồi chạy nhiều lần trong cùng điều kiện thay vì lấy kết quả đẹp nhất. Nếu triển khai đo hiệu năng thật bằng thư viện web-vitals, chỉ thu thập thông tin cần cho chẩn đoán; không gửi nội dung form, số điện thoại hay dữ liệu thanh toán vào hệ thống đo.

LCP: tìm đúng chặng đang mất thời gian

Bước đầu là xác định phần tử LCP của từng mẫu trang. Ở trang sản phẩm đó thường là ảnh chính, ở trang khác có thể là một khối chữ lớn. Đừng kết luận banner là thủ phạm trước khi xem trace. Google chia thời gian LCP thành bốn chặng: thời gian máy chủ trả lời, thời gian chờ bắt đầu tải tài nguyên, thời gian tải tài nguyên và thời gian chờ hiển thị phần tử. Mỗi chặng có cách sửa riêng, nên nén ảnh một cách tràn lan hiếm khi là câu trả lời đúng.

Nếu máy chủ trả lời chậm, hãy kiểm tra chuỗi redirect, các truy vấn dữ liệu nặng và khả năng phục vụ qua cache. Lưu ý ranh giới của cache: không được dùng chung dữ liệu riêng của giỏ hàng hay tài khoản giữa các khách, và giá hay tồn kho phải có cơ chế cập nhật đúng. Một trang tải nhanh nhưng báo sai giá không phải là tối ưu thành công.

Nếu ảnh LCP bị phát hiện muộn, hãy đưa đường dẫn ảnh vào HTML ban đầu thay vì chờ JavaScript gọi dữ liệu rồi mới tạo ảnh, và không dùng lazy loading cho chính ảnh đó. Có thể ưu tiên ảnh quan trọng bằng thuộc tính fetchpriority, nhưng chỉ cho một ảnh chứ không gắn cho cả bộ sưu tập. Về dung lượng, hãy phục vụ ảnh theo kích thước hiển thị thật qua srcset và sizes, và thử so sánh WebP hay AVIF với định dạng hiện tại thay vì mặc định định dạng mới luôn nhẹ hơn. Còn nếu ảnh đã tải xong mà vẫn chưa hiện, vấn đề nằm ở CSS chặn render hoặc tác vụ JavaScript dài, và nén ảnh thêm cũng không giải quyết được. Khi làm việc với đội kỹ thuật, founder nên yêu cầu họ chỉ rõ con số giảm ở chặng nào sau thay đổi, thay vì nghe một câu chung chung như đã bật CDN.

INP: đừng để JavaScript chiếm mất nút bấm của khách

INP chỉ lộ ra ở thao tác thật, nên hãy ghi trace trong lúc mở menu trên điện thoại, đổi bộ lọc, chọn màu hay kích thước, tăng số lượng và thêm vào giỏ. Kiểm tra cả giai đoạn trang đang tải, vì một trang nhìn có vẻ nhanh vẫn có thể phản hồi chậm khi JavaScript đang chiếm luồng chính của trình duyệt.

Với mỗi tương tác chậm, hãy tách ba phần: thời gian chờ trước khi mã xử lý chạy, thời gian chạy mã xử lý, và thời gian chờ trình duyệt vẽ khung hình tiếp theo. Các cách sửa quen thuộc là bỏ công việc không cần thiết trong mã xử lý, chia tác vụ dài thành nhiều tác vụ nhỏ để trình duyệt kịp phản hồi, và ưu tiên cập nhật phần giao diện cần thiết trước khi làm các việc khác. Một lỗi phổ biến trên trang danh mục là dựng lại toàn bộ danh sách khi khách chỉ đổi một bộ lọc; phân trang hoặc giới hạn số phần tử hiển thị thường hiệu quả hơn là thêm thư viện.

Cũng nên rà soát các script bên thứ ba như chat, đánh giá, quảng cáo và analytics. Chỉ giữ những script có mục đích rõ ràng, cân nhắc tải chúng sau nội dung quan trọng và kiểm tra yêu cầu về consent. Tuyệt đối không tắt đo lường để có điểm đẹp rồi tuyên bố hiệu năng đã tăng. Với thao tác cần chờ máy chủ như thêm giỏ, có thể hiển thị ngay trạng thái đang xử lý, nhưng chỉ xác nhận thành công sau khi máy chủ trả kết quả hợp lệ.

CLS: giữ trang đứng yên từ lúc tải đến lúc thanh toán

Nguyên tắc gốc của CLS là dành sẵn chỗ cho mọi thứ sẽ xuất hiện. Khai báo width và height hoặc dùng aspect-ratio cho ảnh, video và các vùng nội dung chèn muộn. Khung ảnh sản phẩm và các khối skeleton nên có kích thước khớp với nội dung thật, và cần kiểm tra cả trường hợp ảnh lỗi hay tên sản phẩm quá dài chứ không chỉ dữ liệu mẫu vừa đẹp.

Những thứ hay gây xê dịch trên website bán hàng là widget đánh giá, banner ưu đãi và thông báo vận chuyển xuất hiện sau khi khách đã bắt đầu đọc. Hãy dành chỗ cho chúng ngay trong bố cục. Với font chữ, chọn font dự phòng có kích thước gần font chính và kiểm tra khoảnh khắc font chính được thay vào; thuộc tính font-display giúp kiểm soát hành vi hiển thị nhưng không tự bảo đảm CLS bằng không.

Quan trọng hơn, đừng chỉ đo CLS trong vài giây đầu. Hãy cuộn hết một trang danh mục, mở các biến thể và đi qua từng bước thanh toán để tìm xê dịch xảy ra sau tải. Dữ liệu CLS của người dùng thật thường khác kết quả Lighthouse vì phiên sử dụng của họ dài hơn và nhiều trạng thái hơn.

Làm việc với đội kỹ thuật theo hạng mục có bằng chứng

Một dự án tối ưu lành mạnh bắt đầu bằng baseline và điểm nghẽn có bằng chứng, sau đó chọn một thay đổi phạm vi nhỏ như sửa ảnh LCP của mẫu trang sản phẩm, đo lại trong cùng điều kiện rồi mới nhân rộng. Không nên hứa một mốc điểm khi chưa biết nguyên nhân và phạm vi mã nguồn. Mỗi hạng mục nên ghi rõ URL chịu ảnh hưởng, số đo trước và sau, trace minh họa, người phụ trách và cách quay lại phiên bản cũ.

Hai điều cần nhớ khi đọc kết quả. Dữ liệu field được tổng hợp theo cửa sổ hai mươi tám ngày trôi, nên không phản ánh ngay bản phát hành mới, và không được trộn số đo của nhiều phiên bản rồi gán toàn bộ thay đổi cho một lần sửa. Và mỗi lần tối ưu phải đi kèm kiểm thử chức năng: bộ lọc còn đúng không, biến thể cập nhật giá đúng không, giỏ hàng có mất hàng không, thanh toán có tạo đơn trùng không. Tối ưu mà làm hỏng luồng mua thì con số xanh cũng vô nghĩa.

Nếu bạn cần một đội cùng nhìn vào số liệu đo, chọn trang ưu tiên và xác minh từng thay đổi, có thể xem dịch vụ thiết kế và tối ưu website của F2C Labs hoặc gửi mô tả ngắn về website của bạn. Khi làm việc với bất kỳ đơn vị bên ngoài nào, bài checklist thuê ngoài làm website và phần mềm sẽ giúp bạn chuẩn bị yêu cầu và đọc báo giá.