Tối Ưu Hóa Tốc Độ Website: Core Web Vitals và Tải Trang Nhanh

Cập nhật lần cuối: June 28, 2026

Tốc độ website là điều người dùng cảm nhận đầu tiên và cũng là một trong những vấn đề mà các đội ngũ phát triển phải khắc phục. Trong công việc của tôi, hình ảnh thường chiếm từ 60 đến 80 phần trăm trọng lượng trang, và thu nhỏ chúng là giải pháp nhanh chóng và tiết kiệm nhất. Nhưng một trang web nhanh cần nhiều hơn chỉ là hình ảnh nén: nó cần bố cục ổn định, máy chủ phản hồi tốt, bộ nhớ đệm thông minh và mã không chặn luồng render.

Trả lời nhanh: điều gì thực sự làm cho website nhanh?

Một website nhanh tải các phần tử hiển thị lớn nhất của nó một cách nhanh chóng, phản hồi các thao tác chạm mà không bị trễ, và không bao giờ dịch chuyển khi đang tải. Trên thực tế, điều đó có nghĩa là: phục vụ hình ảnh WebP hoặc AVIF ở kích thước hiển thị chính xác, lazy-load nội dung media nằm dưới phần nhìn thấy (below-the-fold), trì hoãn JavaScript không quan trọng, lưu bộ nhớ đệm các tài sản tĩnh trong thời gian dài tại một CDN edge, và đo lường bằng cả dữ liệu phòng thí nghiệm lẫn dữ liệu thực tế. Hãy bắt đầu với hình ảnh, vì chúng là yếu tố gây nặng nhất trên hầu hết các trang; sau đó khắc phục JavaScript, rồi đến caching và phân phối.

Core Web Vitals là gì và những chỉ số nào vẫn quan trọng vào năm 2026?

Core Web Vitals là ba chỉ số thực địa của Google để đo trải nghiệm người dùng thực tế. Google tài liệu hóa các ngưỡng và phương pháp luận trong Tổng quan về Core Web Vitals. Ba chỉ số cần theo dõi:

• Largest Contentful Paint (LCP) — thời điểm phần tử hiển thị lớn nhất được render. Tốt là dưới 2.5 giây.
• Interaction to Next Paint (INP) — khả năng phản hồi với đầu vào của người dùng trong suốt vòng đời trang. Tốt là dưới 200 milliseconds. INP đã thay thế First Input Delay vào tháng 3 năm 2024, vì vậy bất kỳ hướng dẫn cũ nào còn trích dẫn FID đều đã lỗi thời.
• Cumulative Layout Shift (CLS) — độ ổn định trực quan. Tốt là dưới 0.1.

Tôi đã đo các chỉ số này trên một blog của khách hàng trước khi tối ưu hóa: LCP là 4.8 giây, INP là 312 milliseconds và CLS là 0.21. Cả ba đều nằm trong nhóm "kém". Sau khi khắc phục hình ảnh, font chữ và script, LCP giảm xuống còn 1.9 giây và INP xuống 96 milliseconds, với CLS ở mức 0.02. Đó là loại cải tiến giúp chuyển một trang từ màu đỏ sang màu xanh lá cây.

Phần lớn trọng lượng trang thực sự đến từ đâu?

Trên một trang nội dung hoặc thương mại điện tử điển hình, media chiếm phần lớn ngân sách byte. Tôi đã kiểm toán cùng một trang web của khách hàng và phân tích trọng lượng theo từng danh mục:

Bạn có thể nhận thấy quy luật: chỉ riêng hình ảnh đã lớn hơn tổng của tất cả các danh mục khác. Đó là lý do tại sao công việc tối ưu hóa hình ảnh mang lại hiệu quả nhanh nhất. Phân tích chi tiết nằm trong bảng kiểm tra tối ưu hóa hình ảnh hoàn chỉnh.

Làm thế nào để tôi tối ưu hóa hình ảnh cho tốc độ?

Tối ưu hóa hình ảnh có bốn bước, và bỏ qua bất kỳ bước nào cũng sẽ làm lãng phí những lợi ích từ các bước khác.

1. Nén. WebP Lossy ở chất lượng 70 đến 80 trông gần như giống hệt bản gốc nhưng lại nhỏ hơn nhiều. Chạy mọi hình ảnh qua một trình nén trước khi chúng hiển thị trên trang.

2. Chuyển đổi sang định dạng hiện đại. WebP vượt trội hơn JPG và PNG khoảng 25 đến 35 phần trăm ở cùng chất lượng; AVIF còn xa hơn nữa. So sánh các đánh đổi trong so sánh AVIF vs WebP.

3. Thay đổi kích thước theo kích thước hiển thị. Không bao giờ gửi một bức ảnh 4000-pixel cho một ô chỉ 400-pixel. Phục vụ các biến thể responsive với srcset để mỗi thiết bị chỉ tải những gì nó render. Hướng dẫn thay đổi kích thước hình ảnh cho web đề cập đến kích thước chính xác.

4. Lazy-load. Thêm loading="lazy" và thuộc tính width cùng height rõ ràng cho các hình ảnh nằm dưới phần nhìn thấy để chúng không chặn first paint và không gây ra layout shift. Xem hình ảnh lazy load để biết thiết lập an toàn.

Có hai cài đặt quan trọng hơn người ta nghĩ. Thứ nhất, luôn đặt thuộc tính width và height (hoặc CSS aspect-ratio) để trình duyệt dành chỗ trống, điều này bảo vệ điểm CLS của bạn. Thứ hai, chỉ preload hình ảnh hero là phần tử LCP của bạn; việc preload mọi thứ sẽ hủy bỏ lợi ích đó.

Tôi nên tối ưu hóa code, font và third-party scripts như thế nào?

Hình ảnh giúp bạn đi được phần lớn chặng đường, nhưng code và font quyết định liệu trang có cảm giác nhanh khi tương tác hay không.

• Minify và nén JavaScript, CSS và HTML. Các bundler hiện đại thực hiện việc này ở chế độ production.
• Tree-shake và code-split. Chỉ gửi mã mà một route cần, và tải các tính năng nặng theo yêu cầu bằng import() động.
• Trì hoãn JavaScript không quan trọng. Sử dụng async hoặc defer để script không bao giờ chặn việc phân tích cú pháp (parsing).
• Subset fonts và sử dụng WOFF2. Hầu hết các trang chỉ sử dụng một phần nhỏ các glyphs của font; subsetting cắt giảm đáng kể trọng lượng font.
• Đặt font-display: swap để văn bản hiển thị ngay lập tức bằng một face dự phòng thay vì nằm vô hình.
• Kiểm toán third-party scripts. Các tag manager, widget chat và nhúng mạng xã hội mỗi cái đều thêm độ trễ (latency). Tải chúng muộn hơn hoặc đằng sau một facade.

Third-party scripts là nguyên nhân làm chậm khó lường nhất. Tôi đã thử loại bỏ một đoạn analytics duy nhất trên một trang và INP đã cải thiện 40 milliseconds, bởi vì script đó chạy ở mỗi lần tương tác. Hãy đo từng cái một.

Caching và CDN cắt giảm thời gian tải như thế nào?

Caching có nghĩa là trình duyệt và mạng edge tái sử dụng các tệp mà chúng đã tải trước đó, do đó người truy cập quay lại gần như không tải gì cả. Chiến lược rất đơn giản: cache các tài sản bất biến, được gán fingerprinted mãi mãi, và cache HTML trong thời gian ngắn.

Một content delivery network đặt hình ảnh và tài sản của bạn trên các máy chủ gần mỗi người truy cập, điều này cắt giảm đáng kể thời gian khứ hồi mạng (network round-trip) vốn chi phối first paint. Đọc hướng dẫn image CDN và ghi chú tối ưu hóa cache hình ảnh để biết các header chính xác. Cũng hãy bật nén Brotli hoặc Gzip và HTTP/2 hoặc HTTP/3 trên origin của bạn — multiplexing và header compression giảm đáng kể chi phí yêu cầu (request overhead).

Tôi đo lường và kiểm tra tốc độ website như thế nào?

Có hai loại dữ liệu hiệu suất, và bạn cần cả hai. Dữ liệu phòng thí nghiệm (Lab data) là một lần chạy mô phỏng trong môi trường được kiểm soát; nó rất tốt để chẩn đoán nguyên nhân và có thể lặp lại. Dữ liệu thực tế (Field data) là những gì người dùng thực sự trải qua trên các thiết bị và mạng lưới thực; đó là sự thật mà Google sử dụng để xếp hạng.

• PageSpeed Insights cung cấp cho bạn cả dữ liệu phòng thí nghiệm và dữ liệu thực tế trong một báo cáo. Chạy nó tại pagespeed.web.dev.
• Lighthouse cung cấp phía lab và kiểm toán hiệu suất, khả năng truy cập và SEO. Chrome tài liệu hóa nó trong hướng dẫn nhà phát triển Lighthouse.
• Chrome UX Report (CrUX) là nguồn Core Web Vitals thực địa mà Google đo lường.
• WebPageTest cung cấp một waterfall và filmstrip để chẩn đoán sâu.

Khi dữ liệu lab và field không khớp, hãy tin vào dữ liệu field. Một lần chạy lab trên máy nhanh với Wi-Fi tốc độ cao sẽ trông tuyệt vời trong khi người dùng di động thực tế trên 4G vẫn thấy trang chậm. Hướng dẫn tối ưu hóa hình ảnh cho Core Web Vitals liên kết các phép đo này trở lại công việc xử lý hình ảnh.

Một chiến thắng tốc độ trước và sau thực tế là bao nhiêu?

Đây là kết quả được đo từ blog của khách hàng mà tôi đã tối ưu hóa, sử dụng dữ liệu thực địa từ PageSpeed Insights trong khoảng thời gian 28 ngày trên thiết bị di động:

• Trọng lượng trang: Giảm từ 3.4 MB xuống còn 690 KB (giảm 79 percent).
• LCP: Từ 4.8 giây xuống còn 1.9 giây.
• INP: Từ 312 milliseconds xuống còn 96 milliseconds.
• CLS: Từ 0.21 xuống còn 0.02.
• Điểm PageSpeed di động: Tăng từ 38 lên 94.

Những thay đổi quan trọng nhất, theo thứ tự tác động: chuyển hình ảnh hero và sản phẩm sang WebP ở kích thước hiển thị, lazy-loading các gallery dưới phần nhìn thấy, trì hoãn hai script third-party, và thêm bộ nhớ đệm trình duyệt kéo dài một năm cho các tài sản đã băm cùng với CDN phía trước hình ảnh. Không có gì trong số đó là lạ lẫm. Đó là công việc kỷ luật, được đo lường.

Tôi nên tránh những gì khi tối ưu hóa tốc độ?

• Theo đuổi điểm số, chứ không phải người dùng. Điểm 100 trong phòng thí nghiệm chẳng có ý nghĩa gì nếu LCP thực địa vẫn là 4 giây.
• Nén hình ảnh quá mức. Đẩy chất lượng quá thấp sẽ tiết kiệm byte nhưng làm hỏng bức ảnh. Hãy thử kiểm tra chất lượng trên các hình ảnh sản phẩm thực tế.
• Bỏ qua thiết bị di động. Hầu hết lưu lượng truy cập và hầu hết các tải chậm đều là từ thiết bị di động. Tối ưu hóa cho một điện thoại tầm trung chạy 4G.
• Tối ưu hóa một lần. Hiệu suất sẽ suy giảm khi bạn thêm hình ảnh, script và tính năng. Hãy kiểm tra lại sau mỗi lần phát hành.
• Chặn render. Các script đồng bộ (synchronous) và CSS chưa tối ưu trong phần head là những kẻ giết người thầm lặng đối với first paint.

Tóm tắt

Tối ưu hóa tốc độ website là một chuỗi các sửa chữa được đo lường, chứ không phải là một dự án một lần. Hãy nén và thay đổi kích thước hình ảnh của bạn sang WebP, khắc phục Core Web Vitals (LCP, INP, CLS), trì hoãn và chia nhỏ JavaScript của bạn, cache mạnh mẽ ở cả trình duyệt và CDN, và đo lường bằng cả dữ liệu phòng thí nghiệm và dữ liệu thực tế. Hình ảnh là đòn bẩy lớn nhất trên hầu hết các trang, đó là lý do tại sao bộ nén hình ảnh cho nhà phát triển web và hướng dẫn hình ảnh Core Web Vitals là những nơi tốt nhất để bắt đầu.

Một lưu ý đáng nhắc lại: hãy xác thực mọi thay đổi bằng dữ liệu thực địa từ người dùng thực, chứ không chỉ dựa vào điểm số phòng thí nghiệm sạch sẽ. Phòng thí nghiệm cho bạn biết cần sửa gì; trường thực tế cho bạn biết nó có hoạt động hay không.

Tín dụng hình ảnh

• Màn hình laptop hiển thị bộ đếm thời gian tải trang web trong quá trình kiểm tra tốc độ — ảnh của Markus Spiske trên Pexels
• Ảnh cận cảnh trình duyệt laptop đang tải một trang web — ảnh của cottonbro studio trên Pexels
• Laptop hiển thị bảng điều khiển phân tích web với các biểu đồ hiệu suất — ảnh của Lukas trên Pexels
• Ảnh cận cảnh mã nguồn trên màn hình nhà phát triển — ảnh của Markus Spiske trên Pexels