Mục lục · 7 phần
Trả lời nhanh
Cách tối ưu Core Web Vitals là tìm nguyên nhân khiến nội dung xuất hiện chậm, thao tác bị khựng hoặc bố cục nhảy rồi sửa. Anh/chị cần tìm nội dung chính xuất hiện muộn khi LCP chậm, lần theo lượt bấm bị khựng khi INP chậm. Với CLS, hãy chừa sẵn chỗ cho nội dung trước khi nó xuất hiện trên trang.
Core Web Vitals là ba chỉ số cho biết người truy cập có thấy nội dung chính kịp thời, bấm có được phản hồi và đọc có bị nhảy bố cục hay không. Cách tối ưu Core Web Vitals là tìm đúng khoảnh khắc đang làm họ khó chịu rồi sửa nguyên nhân của khoảnh khắc đó.
Ba khoảnh khắc người đọc đang chờ trên trang
Core Web Vitals không phải một điểm tổng để xếp website tốt hay xấu. Nó nhìn vào ba việc rất cụ thể xảy ra trên màn hình của người dùng.
LCP là thời điểm phần nội dung lớn nhất ở màn hình đầu tiên xuất hiện. Phần đó có thể là ảnh sản phẩm chính, banner, hoặc một khối chữ lớn. Người đọc vào trang và chưa thấy thứ họ cần xem thì LCP đang cho biết họ phải chờ bao lâu.
INP là độ trễ từ lúc người dùng bấm, chạm hoặc gõ đến lúc giao diện phản hồi nhìn thấy được. Ví dụ, anh/chị bấm bộ lọc sản phẩm nhưng nút chưa đổi trạng thái, danh sách chưa thay hoặc màn hình khựng lại. Khoảng chờ đó liên quan đến INP. INP không chỉ nói về tốc độ mở trang; nó nói về cảm giác trang có nghe lệnh của người dùng hay không.
CLS là việc bố cục tự dịch chuyển bất ngờ trong lúc người dùng đang đọc. Một ảnh chưa có chỗ cố định có thể tải xong rồi đẩy tiêu đề, giá và nút mua xuống dưới. Một thanh thông báo chèn lên đầu trang cũng có thể làm người dùng bấm lệch vị trí. Nếu người dùng chủ động bấm để mở một phần nội dung thì phần đó thay đổi là bình thường. Vấn đề là những chuyển động xảy ra khi họ không hề yêu cầu.
Ba chỉ số này có thể xấu ở ba chỗ khác nhau. Một trang có ảnh đầu trang xuất hiện nhanh vẫn có thể bị khựng khi lọc sản phẩm. Một trang bấm nhanh vẫn có thể làm nút mua nhảy xuống ngay trước khi người dùng chạm vào. Theo chuẩn của Google, trải nghiệm tốt cần đạt LCP dưới 2,5 giây, INP dưới 200 mili-giây và CLS dưới 0,1. Vượt các ngưỡng này là lúc anh/chị cần bắt tay tối ưu.
LCP chậm: tìm thứ quan trọng nhất xuất hiện muộn
Khi xử lý LCP, câu hỏi đầu tiên không phải là “website nặng bao nhiêu”. Câu hỏi là: người đọc đang chờ phần tử nào ở màn hình đầu tiên?
Hãy mở đúng URL trên điện thoại, nhìn màn hình vừa tải và chỉ ra phần lớn nhất có ích cho người đọc. Với trang sản phẩm, đó thường là ảnh sản phẩm. Với trang dịch vụ, đó có thể là tiêu đề và phần giới thiệu. Với trang bài viết, đó có thể là ảnh đại diện hoặc phần mở bài. Nếu phần tử lớn nhất chỉ là một ảnh trang trí, hãy cân nhắc lại cách bố trí trước khi tối ưu kỹ thuật cho nó.
Ảnh đầu trang thường chậm vì được yêu cầu quá muộn. Có trường hợp HTML đã tải nhưng ảnh phải đợi một tệp CSS, một đoạn JavaScript hoặc một thành phần bên thứ ba xong trước. Có trường hợp ảnh được nhét trong một slider nên trình duyệt không nhận ra sớm ảnh nào là ảnh cần hiển thị đầu tiên. Có trường hợp ảnh đã nhẹ nhưng máy chủ trả trang ban đầu chậm, nên ảnh nhẹ cũng không thể xuất hiện sớm.
Nếu ảnh là LCP, anh/chị nên làm rõ kích thước hiển thị ngay trong mã để trình duyệt dành đúng chỗ và chọn tệp ảnh phù hợp với khung đó. Đừng đưa một ảnh lớn cho vùng hiển thị nhỏ rồi chỉ mong trình duyệt tự xử lý. Cũng đừng trì hoãn tải ảnh chính chỉ vì đang dùng quy tắc trì hoãn tải cho ảnh cuối trang. Ảnh đầu trang và ảnh người đọc chưa cuộn tới là hai trường hợp khác nhau.
Nếu khối chữ là LCP, đừng vội thay ảnh. Kiểm tra font chữ, CSS và mã dựng giao diện có đang khiến chữ phải chờ hay không. Một trang có thể tải HTML sớm nhưng vẫn để phần chữ đầu tiên trống vì stylesheet chưa sẵn sàng. Sửa đúng chỗ này hữu ích hơn việc tối ưu những ảnh ở cuối bài.
INP chậm: lần theo đúng lần bấm bị khựng
INP chỉ có ý nghĩa khi anh/chị kiểm tra thao tác thật. Đừng chỉ mở menu rồi kết luận toàn bộ trang phản hồi tốt nếu khách thường tìm kiếm, chọn biến thể, thêm vào giỏ hoặc lọc danh mục.
Một lần bấm bị trễ thường có ba đoạn. Đầu tiên, trình duyệt phải chờ công việc đang chạy xong mới nhận lần bấm. Sau đó, mã của website xử lý yêu cầu. Cuối cùng, trình duyệt vẽ lại giao diện để người dùng thấy kết quả. JavaScript chạy quá lâu thường làm đoạn chờ đầu tiên kéo dài. Logic lọc, kiểm tra dữ liệu hoặc dựng lại quá nhiều thành phần có thể làm đoạn xử lý dài. Giao diện thay đổi quá nhiều cùng lúc có thể làm đoạn vẽ lại nặng hơn.
Hãy ghi một hành trình ngắn cho từng loại trang. Chẳng hạn, với trang danh mục: mở trang, chọn một bộ lọc, đổi thứ tự, rồi mở một sản phẩm. Với trang sản phẩm: chọn biến thể, thêm vào giỏ, rồi mở giỏ. Anh/chị sẽ biết thao tác nào cần soi thay vì đoán từ danh sách tệp mã.
Khi đã thấy điểm khựng, tách công việc theo việc nào phải hoàn thành ngay và việc nào có thể làm sau. Sau lần bấm bộ lọc, người dùng cần thấy bộ lọc đã được nhận và danh sách đang cập nhật. Họ không nhất thiết cần mọi đoạn theo dõi, gợi ý hoặc nội dung nằm ngoài màn hình chạy cùng đúng khoảnh khắc đó. Chỉ tải chức năng khi người dùng cần nó, giảm số thành phần phải vẽ lại và tránh các tác vụ dài chặn lần bấm tiếp theo.
Đừng đổi mã chỉ vì một công cụ chấm điểm cảnh báo. Hãy bấm lại đúng thao tác đã chậm sau mỗi lần sửa. Nếu danh sách vẫn không phản hồi khi người dùng cần, thay đổi đó chưa giải quyết được trải nghiệm thực tế.
CLS: chừa chỗ trước khi nội dung đến
CLS thường xuất hiện vì website chưa nói trước cho trình duyệt biết một phần nội dung sẽ chiếm bao nhiêu chỗ. Khi ảnh, video nhúng, khung quảng cáo, font hoặc mô-đun gợi ý đến muộn, nội dung đang hiện phải dạt sang vị trí khác để nhường chỗ.
Việc đầu tiên là tìm phần tử nào đã đẩy phần tử khác đi. Anh/chị có thể bắt đầu ở ảnh sản phẩm, video, biểu mẫu nhúng, thanh thông báo, banner và khối gợi ý bài viết. Với ảnh và khung nhúng, cần xác định kích thước hoặc tỷ lệ khung từ đầu. Với nội dung tải sau, hãy dành một vùng chứa ổn định thay vì để nó xuất hiện rồi chen vào giữa đoạn người đọc đang xem.
Font cũng có thể làm chữ nhảy dòng. Một tiêu đề vừa đủ một dòng khi font tạm thời được dùng, nhưng thành hai dòng khi font chính tải xong, sẽ đẩy toàn bộ phần dưới xuống. Điều này đặc biệt dễ thấy trên màn hình hẹp. Vì vậy, sau khi sửa, hãy kiểm tra điện thoại thật hoặc kích thước hẹp, không chỉ xem màn hình máy tính rộng.
Không phải mọi chuyển động đều cần loại bỏ. Khi anh/chị bấm “xem thêm” và nội dung mở ra, đó là phản hồi theo ý người dùng. Nhưng khi đang đọc mô tả sản phẩm mà nút mua hoặc giá tự trôi đi vì một khối khác vừa tải xong, đó là chuyển động cần xử lý.
Nên sửa chỉ số nào trước để không tốn công sai chỗ?
Ưu tiên theo hành trình đang tạo ra giá trị cho website, không ưu tiên theo tên chỉ số nghe quen hơn. Nếu khách mới vào đã phải chờ ảnh sản phẩm hoặc lời hứa chính của trang, xử lý LCP trước. Nếu họ vào được nhưng không lọc, tìm kiếm hoặc thêm vào giỏ được mượt, xử lý INP trước. Nếu họ có nguy cơ bấm nhầm vì bố cục đổi vị trí, xử lý CLS trước.
Mỗi lần chỉ nên nhắm một nguyên nhân có thể kiểm tra. Ví dụ, nếu ảnh chính tải muộn vì nằm trong slider, việc cần làm là để ảnh đầu tiên được phát hiện sớm hơn; không phải giảm ngẫu nhiên mọi ảnh trên website. Nếu một bộ lọc khựng do dựng lại cả danh sách, việc cần làm là giảm phần phải cập nhật sau lần bấm; không phải chỉ đổi màu nút lọc.
Đừng lấy doanh số để suy ra Core Web Vitals. Đây là hai loại số khác nhau. Một shop có doanh số trên 100 triệu mỗi ngày ghi nhận ROAS 8,54 từ CPAS Facebook về Shopee trong giai đoạn 16–20/8/2026, với chi phí 5.903đ cho mỗi lượt mua ở Campaign A trong cùng giai đoạn. ROAS 8,54 chỉ cho biết doanh thu được quy cho quảng cáo cao gấp 8,54 lần chi phí quảng cáo; nó không cho biết riêng trang web nào đang có LCP, INP hay CLS tốt. Muốn cải thiện web, anh/chị vẫn phải quan sát trực tiếp URL và thao tác của người dùng.
Số liệu thực tế từ tài khoản đang vận hành, ghi nhận tại thời điểm nêu trên. Kết quả từng shop khác nhau tuỳ ngành hàng, giá bán và ngân sách.
Sự phân biệt này giúp tránh một lỗi hay gặp: thấy một chỉ số kinh doanh tốt rồi bỏ qua trải nghiệm trang, hoặc thấy một bài kiểm thử web chưa đẹp rồi kết luận quảng cáo không hiệu quả. Mỗi báo cáo trả lời một câu hỏi khác nhau. Core Web Vitals trả lời câu hỏi về khoảnh khắc người dùng nhìn, bấm và đọc trên trang.
Xem cách kết nối hiệu suất trang với cấu trúc nội dung để hệ thống tìm kiếm và trợ lý AI hiểu đúng giá trị của website. Bên cạnh đó, Core Web Vitals cũng không phải là Domain Authority (DA/DR), vì DA hoặc DR chỉ là cách một số công cụ đánh giá sức mạnh tên miền. Nó cũng không phải Featured Snippets, tức cách một câu trả lời có thể được trình bày trên kết quả tìm kiếm. Một trang có thể cần cải thiện cả ba mảng, nhưng mỗi mảng phải được kiểm tra bằng cách riêng.
Xem số ở đâu và kiểm tra lại thế nào?
Để xem số liệu trải nghiệm thực tế từ người dùng, anh/chị nên mở báo cáo Core Web Vitals (nằm trong mục Trải nghiệm trang) trên Google Search Console. Báo cáo này gom các trang theo nhóm URL có cùng mục đích như trang sản phẩm, danh mục, bài viết hay thanh toán, giúp nhận ra lỗi thuộc về mẫu giao diện chung hay chỉ một trang cá biệt. Khi cần kiểm tra nhanh từng đường link sau khi sửa mã, anh/chị có thể dán link vào PageSpeed Insights để xem phân tích chi tiết tại chỗ.
Sau khi có một nghi ngờ, mở đúng URL và làm lại hành trình người dùng. Nếu báo cáo gợi ý LCP, nhìn phần nội dung lớn đầu tiên. Nếu báo cáo gợi ý INP, bấm thao tác thường dùng. Nếu báo cáo gợi ý CLS, cuộn và quan sát xem phần nào chen vào làm chữ hoặc nút dời chỗ. Báo cáo cho anh/chị nơi cần điều tra; nó không tự chỉ ra nguyên nhân trong mã.
Một lần kiểm thử tại chỗ là ảnh chụp của lần kiểm tra đó. Người dùng thật có thể dùng mạng, thiết bị và thời điểm khác. Vì vậy, sau mỗi bản sửa, hãy vừa kiểm tra lại hành trình trên trang vừa theo dõi dữ liệu trải nghiệm khi dữ liệu mới được ghi nhận. Không nên tuyên bố đã cải thiện chỉ vì một lần chạy công cụ đẹp hơn.
Tài liệu hướng dẫn của Google về Search và trải nghiệm trang có thể xem tại Google Search Central Help. Khi dùng một công cụ cụ thể, anh/chị nên đối chiếu định nghĩa và cách hiển thị của chính công cụ đó trước khi đổi mã.
Câu hỏi thường gặp
Tối ưu Core Web Vitals có phải chỉ cần nén ảnh không?
Không. Nén ảnh có thể giúp LCP nếu ảnh đầu trang là phần nội dung lớn nhất và đang quá nặng hoặc được tải không hợp lý. Nó không tự sửa thao tác bị JavaScript chặn, cũng không chừa chỗ cho khung nội dung tải muộn gây CLS.
LCP cao thì tôi nên kiểm tra ảnh nào trước?
Kiểm tra phần tử lớn nhất mà người dùng nhìn thấy ngay khi mở đúng URL, thường là ảnh sản phẩm, banner hoặc khối chữ đầu trang. Sau đó xem nó có được yêu cầu sớm hay phải chờ CSS, JavaScript hoặc slider. Đừng bắt đầu từ ảnh cuối trang nếu người dùng chưa cuộn tới đó.
Bấm bộ lọc sản phẩm bị khựng thì có phải lỗi INP không?
Có thể, vì INP đo thời gian từ thao tác đến lúc giao diện phản hồi nhìn thấy được. Anh/chị hãy bấm lại bộ lọc trên trang đang có người dùng, rồi kiểm tra xem mã có đang chạy công việc dài hoặc dựng lại quá nhiều danh sách hay không. Chỉ số là dấu hiệu để tìm chỗ khựng, không phải tên của nguyên nhân.
Vì sao nút mua tự nhảy xuống khi tôi chưa bấm gì?
Đó thường là dạng CLS do ảnh, font, banner hoặc khung nhúng đến sau mà chưa được dành chỗ. Hãy tìm phần tử xuất hiện ngay trước khi nút đổi vị trí và đặt một vùng hiển thị ổn định cho nó. Kiểm tra cả màn hình điện thoại vì chữ xuống dòng có thể làm lỗi rõ hơn.
Tôi sửa xong rồi, vì sao báo cáo Core Web Vitals chưa đổi ngay?
Vì báo cáo trải nghiệm phản ánh cách người dùng đã dùng trang trong một khoảng thời gian, còn bài kiểm thử tại chỗ chỉ là một lần kiểm tra. Trước hết, xác nhận đúng phần tử hoặc thao tác đã được cải thiện trên URL thật. Sau đó theo dõi khi dữ liệu mới được ghi nhận, thay vì chỉ dựa vào một lần chạy.
Điểm audit cao có nghĩa website chắc chắn dễ dùng không?
Không. Điểm audit giúp phát hiện hướng kiểm tra, nhưng người dùng có thể gặp lỗi ở một lần bấm hoặc một khung màn hình mà bài kiểm thử chưa đại diện. Anh/chị vẫn cần tự đi qua hành trình quan trọng như tìm kiếm, lọc, chọn sản phẩm và gửi biểu mẫu.
