Sửa Core Web Vitals thực chiến: 15 kỹ thuật sửa LCP, INP, CLS (2026)
Biết ngưỡng Core Web Vitals là một chuyện, sửa cho website đạt ngưỡng lại là chuyện khác. Bài này là phần thực chiến: 15 kỹ thuật cụ thể để kéo ba chỉ số LCP, INP, CLS về nhóm đạt chuẩn, chia đều mỗi chỉ số 5 kỹ thuật. Mỗi kỹ thuật nêu rõ sửa cái gì và vì sao có tác dụng, để bạn áp thẳng vào website của mình theo thứ tự ưu tiên. Nếu bạn chưa nắm ngưỡng đạt chuẩn tháng 3/2026 và nguyên nhân gốc của từng chỉ số, hãy đọc bài nền Core Web Vitals tháng 3/2026 trước, rồi quay lại đây để sửa.
Sửa Core Web Vitals bắt đầu từ đâu?
Trả lời ngắn: Bắt đầu bằng việc đo để biết chỉ số nào đang không đạt, rồi sửa nhóm kém trước. Đừng tối ưu cả ba chỉ số cùng lúc, và đừng đuổi theo điểm số hoàn hảo vì lợi ích giảm dần rất nhanh khi đã vào nhóm đạt chuẩn. Chạy PageSpeed Insights ở chế độ di động cho vài trang quan trọng nhất, ghi lại ba chỉ số, rồi áp đúng nhóm kỹ thuật cho chỉ số đang kém.
Mỗi chỉ số đo một khía cạnh khác nhau nên cần cách sửa khác nhau. LCP đo tốc độ hiển thị phần tử lớn nhất, thường là ảnh đầu trang. INP đo độ trễ phản hồi khi người dùng tương tác. CLS đo mức xáo trộn bố cục. Một website có thể đạt hai chỉ số mà hỏng chỉ số thứ ba, nên sửa theo nguyên nhân gốc, không sửa theo cảm tính. 15 kỹ thuật dưới đây xếp theo ba nhóm đó.
5 kỹ thuật sửa LCP (thời gian hiển thị nội dung lớn nhất)
LCP kém gần như luôn bắt nguồn từ ba nhóm: ảnh đầu trang nặng, tài nguyên tải trễ, và mã lệnh chặn hiển thị. Năm kỹ thuật sau xử lý cả ba, xếp theo mức tác động từ cao xuống thấp. Tham khảo thêm hướng dẫn tối ưu LCP của web.dev.
Kỹ thuật 1 — Nén ảnh đầu trang và cho tải ngay với ưu tiên cao
Ảnh đầu trang nặng là nguyên nhân số một khiến LCP vượt mốc mục tiêu 2,0 giây — mốc HAYWEB siết chặt hơn ngưỡng đạt chuẩn 2,5 giây mà Google công bố. Chuyển ảnh sang WebP ở mức chất lượng 85, đặt loading="eager" và fetchpriority="high" để trình duyệt ưu tiên tải nó trước mọi thứ khác. Đây là kỹ thuật cho hiệu quả cao nhất trên mỗi giờ công. Cách nén và chọn ảnh đầu trang chi tiết nằm ở bài tối ưu hình ảnh cho SEO.
Kỹ thuật 2 — Tải trước ảnh LCP và phông chữ quan trọng
Trình duyệt chỉ phát hiện ảnh đầu trang sau khi phân tích xong phần đầu trang, nên đôi khi tải nó muộn. Thêm gợi ý <link rel="preload"> trong <head> cho ảnh LCP và cho phông chữ quan trọng, để trình duyệt bắt đầu tải chúng ngay từ đầu. Riêng phông chữ, tự lưu trữ trên tên miền của mình thay vì gọi qua tên miền khác cũng cắt được một vòng kết nối mạng.
Kỹ thuật 3 — Nội tuyến CSS quan trọng và hoãn phần CSS còn lại
CSS là tài nguyên chặn hiển thị: trình duyệt không vẽ gì cho tới khi tải xong CSS. Đưa phần CSS cần cho khung nhìn đầu tiên vào nội tuyến ngay trong trang, rồi tải phần CSS còn lại sau, giúp phần đầu trang hiển thị sớm hơn. Với website nhỏ, gộp và rút gọn CSS đã đủ cải thiện rõ; website lớn thì tách riêng phần CSS quan trọng.
Kỹ thuật 4 — Giảm thời gian phản hồi đầu tiên của máy chủ
Thời gian phản hồi đầu tiên của máy chủ (TTFB) trên 1,0 giây làm mọi thứ phía sau chậm theo. Bật bộ đệm ở biên qua CDN, đặt máy chủ hoặc điểm biên gần người dùng — với lưu lượng Việt là Singapore hoặc TP.HCM — và tối ưu khởi động nguội cho hàm chạy không máy chủ riêng. Cải thiện ở phía máy chủ không cần nâng phần cứng, chỉ cần cấu hình đúng.
Kỹ thuật 5 — Bỏ mã lệnh chặn hiển thị trong phần đầu trang
Mỗi thẻ <script> đồng bộ trong <head> chặn trình duyệt vẽ trang cho tới khi tải và chạy xong. Thêm defer hoặc async cho mọi mã lệnh không cấp thiết cho lần hiển thị đầu, hoặc chuyển chúng xuống cuối <body>. Chỉ giữ lại trong phần đầu trang những gì thật sự phải chạy trước khi vẽ.
5 kỹ thuật sửa INP (độ trễ phản hồi khi tương tác)
INP kém gần như luôn là câu chuyện của JavaScript chặn luồng chính. Một tác vụ dài chặn luồng chính khiến trình duyệt không kịp phản hồi khi người dùng chạm hay gõ. Năm kỹ thuật sau giảm gánh nặng luồng chính, tham khảo hướng dẫn tối ưu INP của web.dev.
Kỹ thuật 6 — Chia nhỏ tác vụ dài và nhường luồng chính
Bất kỳ tác vụ JavaScript nào chạy quá 50 mili-giây đều là tác vụ dài, chặn luồng chính và đẩy INP lên, theo hướng dẫn xử lý tác vụ dài của web.dev. Chia một tác vụ nặng thành nhiều mảnh nhỏ, và chủ động nhường luồng chính giữa các mảnh để trình duyệt kịp xử lý tương tác của người dùng. Cách này giữ giao diện luôn phản hồi ngay cả khi có việc nặng chạy nền.
Kỹ thuật 7 — Giảm và tải trễ mã lệnh bên thứ ba
Khung chat, công cụ phân tích, công cụ bản đồ nhiệt và mã quảng cáo thường chiếm phần lớn tác vụ dài trên website dùng nhiều công cụ — đây là nguồn ẩn bị bỏ qua nhiều nhất. Bỏ những công cụ không dùng, tải trễ phần còn lại bằng defer, và cân nhắc đẩy chúng sang luồng nền để không chặn luồng chính. Không rà mã bên thứ ba thì không bao giờ đạt INP tốt, dù mã tự viết đã tối ưu.
Kỹ thuật 8 — Tiết chế sự kiện gõ phím và cuộn
Bộ xử lý chạy trên mỗi lần gõ phím hoặc mỗi khung cuộn có thể dội hàng trăm lần một giây, làm nghẽn luồng chính. Làm trễ sự kiện gõ để phần kiểm tra hay gợi ý chỉ chạy sau khi người dùng ngừng gõ, và tiết chế bộ xử lý cuộn về mức 60 khung hình mỗi giây. Với hiệu ứng theo cuộn, dùng IntersectionObserver thay vì gắn thẳng vào sự kiện cuộn.
Kỹ thuật 9 — Đẩy tính toán nặng sang luồng nền
Sắp xếp hay lọc một danh sách dài, xử lý dữ liệu lớn, kiểm tra biểu mẫu phức tạp — những việc này nếu chạy trên luồng chính sẽ chặn giao diện. Đẩy chúng sang luồng nền qua Web Worker để luồng chính rảnh tay lo việc phản hồi tương tác. Người dùng vẫn cuộn và bấm mượt trong khi tính toán chạy ngầm.
Kỹ thuật 10 — Giảm cây DOM quá lớn và hoãn phần ngoài màn hình
Trang có cây DOM quá lớn khiến mỗi lần trình duyệt tính lại bố cục đều tốn kém, đội INP. Gom bớt phần tử thừa, và dùng thuộc tính content-visibility: auto để trình duyệt bỏ qua việc dựng phần nằm ngoài màn hình cho tới khi người dùng cuộn tới. Với danh sách rất dài, chỉ dựng phần đang hiện thay vì dựng toàn bộ một lúc.
5 kỹ thuật sửa CLS (mức xáo trộn bố cục)
CLS kém là do các phần tử nhảy khi trang đang tải hoặc người dùng đang đọc. Gốc rễ gần như luôn là không chừa chỗ trước cho nội dung sẽ xuất hiện. Năm kỹ thuật sau chừa chỗ đúng cách, tham khảo hướng dẫn tối ưu CLS của web.dev.
Kỹ thuật 11 — Khai báo kích thước cho mọi ảnh, video và khung nhúng
Ảnh không khai báo chiều rộng và chiều cao làm trình duyệt không biết chừa bao nhiêu chỗ, nên khi ảnh tải xong, mọi thứ bên dưới bị đẩy nhảy. Khai báo thuộc tính width và height cho mọi thẻ <img>, <video> và <iframe>, hoặc dùng thuộc tính CSS aspect-ratio. Đây là kỹ thuật sửa CLS cho hiệu quả cao nhất và dễ làm nhất, gắn với cách xử lý ảnh ở bài tối ưu hình ảnh cho SEO.
Kỹ thuật 12 — Chừa chỗ tối thiểu cho quảng cáo và nội dung chèn động
Quảng cáo, khung nhúng, hay nội dung tải sau khi trang đã hiện đều đẩy bố cục nếu không có chỗ chờ sẵn. Đặt min-height cố định cho khung chứa khớp với kích thước nội dung sẽ chèn vào, để khi nội dung xuất hiện nó lấp đúng chỗ đã chừa thay vì chen ngang. Nguyên tắc: mọi thứ tải sau đều phải có chỗ đặt trước.
Kỹ thuật 13 — Tải trước phông chữ và giảm nhảy chữ khi hoán đổi
Phông chữ web tải muộn làm chữ vẽ lại khi phông chính về, gây xáo trộn. Tải trước phông chữ quan trọng, đặt font-display: swap để chữ hiện ngay bằng phông dự phòng, và dùng bộ mô tả size-adjust để phông dự phòng có kích thước gần với phông chính, giảm mức nhảy khi hoán đổi. Kỹ thuật này sửa được cả CLS lẫn một phần LCP.
Kỹ thuật 14 — Không chèn nội dung phía trên phần đang xem
Chèn một thanh thông báo, biểu ngữ, hay khối nội dung vào phía trên phần người dùng đang đọc sẽ đẩy toàn bộ trang xuống — một trong những nguồn CLS khó chịu nhất. Nếu cần hiện thanh thông báo, chừa sẵn chỗ cho nó từ đầu, hoặc cho nó nổi đè lên thay vì chen vào dòng chảy bố cục. Không bao giờ chèn nội dung mới đẩy phần người dùng đang đọc.
Kỹ thuật 15 — Dùng transform cho hiệu ứng thay vì đổi thuộc tính bố cục
Hiệu ứng chuyển động đổi các thuộc tính bố cục như chiều cao, lề, vị trí khiến trình duyệt tính lại bố cục và có thể đội CLS. Dùng thuộc tính CSS transform cho chuyển động thay vì đổi thuộc tính bố cục, vì transform chạy ở tầng hợp thành, không kích hoạt tính lại bố cục. Đây cũng là cách giữ hiệu ứng mượt 60 khung hình mỗi giây.
Đo lại sau khi sửa: dữ liệu thực tế và dữ liệu phòng thí nghiệm
Trả lời ngắn: Sửa xong đừng vội kết luận. Dùng dữ liệu phòng thí nghiệm của Lighthouse để kiểm ngay xem lỗi đã hết chưa, rồi chờ 28 ngày để dữ liệu thực tế trong Chrome UX Report cập nhật — vì đó mới là số Google dùng để xếp hạng.
Chrome UX Report cập nhật theo cửa sổ 28 ngày gần nhất, theo tài liệu Chrome UX Report. Nghĩa là sửa hôm nay thì cần ít nhất 28 ngày mới thấy ngưỡng đổi trong dữ liệu thực tế, và báo cáo Core Web Vitals trong Google Search Console còn chậm hơn vài ngày nữa. Quy trình đúng: sửa, đo ngay bằng dữ liệu phòng thí nghiệm để xác nhận đã sửa đúng, chờ 28 ngày, rồi kiểm báo cáo Search Console sau khoảng 35 ngày.
Sau khi đạt ngưỡng, đừng dừng ở một lần sửa. Triển khai tính năng mới hay thêm mã mới là LCP hoặc INP có thể tụt ngay. Cài giám sát liên tục bằng thư viện Web Vitals để thu ba chỉ số từ người dùng thật mỗi lượt tải trang, và đặt cảnh báo khi chỉ số tụt quá 10% so với mốc nền. Cùng nguyên tắc đo trước, sửa, xác minh này áp cho cả bảng kiểm SEO kỹ thuật 30 điểm 2026.
Cách HAYWEB tiếp cận
HAYWEB không chỉ áp dụng chạy PageSpeed Insights ở chế độ di động cho trang chủ và 3 trang đích chính, ghi lại ba chỉ số LCP, INP, CLS, rồi sửa nhóm kém trước bằng đúng nhóm kỹ thuật tương ứng — ảnh đầu trang cho LCP, mã bên thứ ba cho INP, khai báo kích thước cho CLS, mà còn kết hợp toàn diện với:
- Kết cấu bài viết theo chuẩn 2026 — chi tiết chia sẻ qua tư vấn trực tiếp.
- Cách trình bày thông tin để công cụ tìm kiếm AI (ChatGPT, Gemini, Perplexity, AI Hay) trích dẫn chính xác.
- Đo lường bằng Google Search Console thật — theo dõi thứ hạng, lượt hiển thị và nhấp chuột từng bài để tối ưu theo dữ liệu.
- Điểm bảo mật Mozilla Observatory 100 trên 100 và tốc độ Lighthouse trên 90 giữ nguyên qua mọi lần cập nhật, kiểm tra hàng ngày.
- Cách phối bộ đệm CDN ở biên với hạ tầng triển khai để giữ LCP dưới 2,0 giây, và đoạn mã tự đo Core Web Vitals trên di động của người dùng thật — chia sẻ qua tư vấn 1-1 (HAYWEB áp dụng khi tối ưu website cho dự án khách, gồm bảng kiểm rà soát mã lệnh bên thứ ba theo thứ tự tác động).
Trải nghiệm khách hàng như ví dụ thực tế trên — và còn hơn, vì HAYWEB sở hữu thêm các chỉ tiêu nâng cao chuẩn 2026 chỉ chia sẻ qua tư vấn trực tiếp.
Ba lỗi khi sửa Core Web Vitals
Lỗi 1 — Chỉ đo máy tính bàn, bỏ qua di động
Google lập chỉ mục ưu tiên di động, và ngưỡng trên di động khắt khe hơn vì vi xử lý điện thoại yếu hơn. Website đạt điểm cao trên máy bàn nhưng kém trên di động vẫn bị đánh giá theo phía di động. Với lưu lượng Việt đa số là di động, sai lầm này đặc biệt tốn kém — bàn kỹ hơn ở bài thiết kế ưu tiên di động cho 70% lưu lượng Việt. Luôn đo và sửa trên di động trước.
Lỗi 2 — Sửa theo triệu chứng thay vì nguyên nhân gốc
Thấy điểm thấp là vội áp mọi mẹo cùng lúc, không xác định chỉ số nào kém và vì sao. Kết quả là tốn công mà không trúng. Cách đúng: đo để biết chỉ số nào không đạt, tìm nguyên nhân gốc của đúng chỉ số đó, rồi áp nhóm kỹ thuật tương ứng. Ảnh nặng thì sửa ảnh, JavaScript nặng thì sửa mã, bố cục nhảy thì chừa chỗ.
Lỗi 3 — Sửa một lần rồi quên
Core Web Vitals đo trải nghiệm thật, thay đổi theo mỗi lần bạn thêm tính năng hay mã mới. Sửa xong một lần rồi không theo dõi thì vài tháng sau chỉ số có thể tụt lại mà không ai hay. Cách đúng: cài giám sát liên tục và đặt cảnh báo, coi Core Web Vitals là vòng lặp chứ không phải việc làm một lần.
Câu hỏi thường gặp về sửa Core Web Vitals
Nên sửa chỉ số nào trước: LCP, INP hay CLS?
Sửa chỉ số đang ở nhóm kém trước, đó là ưu tiên số một. Nếu cả ba đều kém, thứ tự thực dụng thường là LCP trước vì ảnh đầu trang cho cải thiện nhanh và rõ, rồi tới INP vì liên quan JavaScript, cuối cùng CLS vì thường sửa nhanh khi đã khai báo kích thước ảnh. Nhưng nguyên tắc gốc vẫn là: chỉ số nào kém nhất, ảnh hưởng trang quan trọng nhất, thì sửa trước.
Sửa xong bao lâu thì thấy thay đổi trên Google?
Dữ liệu phòng thí nghiệm của Lighthouse phản hồi ngay sau khi sửa, nhưng đó không phải số Google dùng để xếp hạng. Dữ liệu thực tế trong Chrome UX Report cập nhật theo cửa sổ 28 ngày, nên cần ít nhất 28 ngày mới thấy ngưỡng đổi, và báo cáo trong Google Search Console chậm hơn vài ngày nữa. Hãy sửa, xác nhận bằng dữ liệu phòng thí nghiệm, rồi kiên nhẫn chờ dữ liệu thực tế.
Tối ưu Core Web Vitals có làm giảm bảo mật không?
Không. Hiệu năng và bảo mật không đánh đổi nhau: bật tiêu đề bảo mật chặt và mã hóa không làm tăng thời gian tải. HAYWEB giữ hạng bảo mật A+ trên Mozilla Observatory song song với LCP thấp. Cách triển khai cả hai cùng lúc nằm ở bài bảo mật website và Mozilla Observatory.
Website mới chưa có dữ liệu thực tế thì đo bằng gì?
Website mới hoặc ít lưu lượng thường chưa có dữ liệu thực tế trong Chrome UX Report, nhất là với INP. Trường hợp này dùng số giả lập từ Lighthouse để dò lỗi và sửa, đồng thời cài thư viện Web Vitals để bắt đầu thu dữ liệu thật ngay khi có người dùng. Khi lưu lượng đủ, dữ liệu thực tế sẽ xuất hiện và bạn có căn cứ chính xác hơn.
Bắt đầu sửa Core Web Vitals thế nào?
Ba việc làm được ngay hôm nay. Bước 1 — chạy PageSpeed Insights ở chế độ di động cho trang chủ và 3 trang đích chính, ghi lại ba chỉ số để biết chỉ số nào đang kém. Bước 2 — áp đúng nhóm kỹ thuật cho chỉ số kém: 5 kỹ thuật LCP nếu tải chậm, 5 kỹ thuật INP nếu phản hồi trễ, 5 kỹ thuật CLS nếu bố cục nhảy; nếu cần nền tảng, đọc lại bài Core Web Vitals tháng 3/2026. Bước 3 — chạy lại công cụ rà soát miễn phí đã nhắc ở phần trên để xem ba chỉ số trên di động và máy tính bàn, hoặc liên hệ HAYWEB tư vấn trực tiếp — nhà sáng lập Nguyễn Thế Quyền trả lời, không qua trung gian bán hàng, bàn cụ thể lộ trình sửa dựa trên dữ liệu thật chứ không phải ước lượng chung.
Kiến thức liên quan
Nền tảng — nên đọc trước
- Core Web Vitals tháng 3/2026: ngưỡng LCP 2 giây, INP 200ms — website Việt ưu tiên điện thoại di độngcore web vitals 2026 · 12 phút đọc
Cùng chủ đề
- SEO kỹ thuật 2026: bảng kiểm 30 điểm cho website doanh nghiệp Việttechnical SEO checklist · 15 phút đọc
- Sitemap.xml và robots.txt: 2 tệp kỹ thuật bắt buộc cho website 2026sitemap và robots.txt · 12 phút đọc
- Thẻ canonical và trùng lặp nội dung: cách xử lý cho website 2026thẻ canonical · 12 phút đọc
- Thẻ tiêu đề và thẻ mô tả: cách viết chuẩn SEO cho website 2026thẻ tiêu đề và thẻ mô tả · 11 phút đọc
Cần làm website chuyên nghiệp? Gọi trực tiếp HAYWEB.
Nhà sáng lập Nguyễn Thế Quyền trả lời trực tiếp, không qua trung gian bán hàng. Hoặc so sánh website của bạn với chuẩn HAYWEB trên 7 chỉ tiêu kỹ thuật — chỉ cần URL, không cần đăng ký.
Tài liệu tham khảo
- web.dev — Optimize Largest Contentful Paint (các kỹ thuật sửa LCP) — retrieved 2026-07.
- web.dev — Optimize Interaction to Next Paint (các kỹ thuật sửa INP) — retrieved 2026-07.
- web.dev — Optimize Cumulative Layout Shift (các kỹ thuật sửa CLS) — retrieved 2026-07.
- web.dev — Optimize long tasks (chia nhỏ tác vụ dài, ngưỡng 50 mili-giây) — retrieved 2026-07.
- Chrome for Developers — Chrome UX Report API (nêu rõ dữ liệu thực tế là trung bình trượt cửa sổ 28 ngày) — retrieved 2026-07.
- GitHub — thư viện web-vitals của Google Chrome (giám sát người dùng thật) — retrieved 2026-07.
- Google Search Central — Core Web Vitals và tìm kiếm Google — retrieved 2026-07.