Preload và prefetch khác nhau thế nào (cùng preconnect, dns-prefetch)

Bốn cái tên nghe na ná nhau nhưng làm bốn việc rất khác: preload, prefetch, preconnect và dns-prefetch. Dùng đúng thì một tài nguyên tới hạn xuất hiện sớm hơn vài trăm mili-giây, kéo theo điểm Core Web Vitals đẹp lên. Dùng sai thì trình duyệt tải nhầm thứ, giành băng thông với cái thực sự quan trọng, và trang còn chậm hơn lúc chưa tối ưu.

Bài này tách rõ vai từng loại, chỉ ra khi nào dùng, kèm ví dụ <link rel> thật và những cái bẫy hay gặp nhất.

Hai nhóm: tải tài nguyên và mở kết nối

Để khỏi rối, hãy chia bốn hint thành hai nhóm theo việc chúng làm:

• Nhóm tải tài nguyên (lấy hẳn file về): preload cho trang hiện tại, prefetch cho trang kế tiếp.
• Nhóm mở kết nối (chỉ dọn đường, chưa tải gì): preconnect mở trọn kết nối, dns-prefetch chỉ tra DNS.

preconnect và dns-prefetch — dọn đường tới domain ngoài

Mỗi domain bên thứ ba (Google Fonts, một CDN ảnh, trình phân tích…) bắt trình duyệt làm ba bước trước khi tải được byte đầu tiên: tra DNS, bắt tay TCP, rồi bắt tay TLS nếu là HTTPS. preconnect làm trước cả ba để khi cần tải thật thì kết nối đã sẵn sàng.

<link rel="preconnect" href="https://cdn.example.com" crossorigin>
<link rel="dns-prefetch" href="https://cdn.example.com">

Theo web.dev, preconnect chỉ nên dành cho vài kết nối tới hạn nhất — mỗi kết nối mở ra đều tốn tài nguyên, mở bừa hàng loạt domain còn phản tác dụng. Những domain còn lại thì dùng dns-prefetch cho nhẹ. Đặt cả hai dòng cạnh nhau như trên là cách an toàn: trình duyệt nào không hiểu preconnect vẫn hưởng được phần tra DNS.

Một mẹo từ chính việc Web22 vận hành web22.dev: nếu bạn tự host Google Font về cùng domain, bạn xoá luôn được nhu cầu preconnect tới fonts.gstatic.com — không còn kết nối ngoài nào để dọn đường nữa. Đó thường là cách gọn hơn cả việc thêm hint.

preload — kéo tài nguyên tới hạn lên sớm

preload bảo trình duyệt tải ngay một tài nguyên mà bình thường nó phát hiện muộn — vì tài nguyên đó nằm trong CSS, trong JS, hay là ảnh nền không lộ ra cho bộ phân tích HTML thấy sớm. Ứng viên đáng preload nhất là font hiển thị chữ đầu trang và ảnh LCP (Largest Contentful Paint — phần tử lớn nhất hiện ra).

<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/hero.avif" as="image" fetchpriority="high">

Ba thuộc tính dưới đây không phải tuỳ chọn — thiếu là sinh lỗi:

• as: thiếu thuộc tính này, trình duyệt không biết loại tài nguyên và sẽ tải file hai lần.
• crossorigin cho font: font là tài nguyên CORS, thiếu crossorigin (hoặc thừa khi không cần) cũng làm tải hai lần. Đây là lỗi font phổ biến nhất.
• fetchpriority="high" cho ảnh: ảnh mặc định ưu tiên thấp, và bản thân preload không nâng ưu tiên. Không gắn cờ này thì ảnh tuy được phát hiện sớm vẫn xếp hàng sau CSS và JS.

Với ảnh đổi theo khổ màn hình, đừng preload bằng href trơn. Dùng imagesrcset để trình duyệt chọn đúng kích thước, khớp với cách khai báo srcset cho ảnh responsive:

<link rel="preload" as="image"
  imagesrcset="/hero-480.avif 480w, /hero-1200.avif 1200w"
  imagesizes="100vw" fetchpriority="high">

Bẫy lớn nhất: preload sai làm trang chậm hơn

preload đẩy một tài nguyên lên đầu hàng đợi. Nếu thứ bạn đẩy lên không phải thứ tới hạn, nó sẽ chen ngang đúng cái đang quyết định tốc độ hiển thị. Những lỗi hay gặp:

1. Preload nhiều thứ một lúc. Nếu cái gì cũng “ưu tiên cao” thì chẳng còn gì ưu tiên — trình duyệt chỉ nâng được một tài nguyên so với các tài nguyên khác. Giữ fetchpriority="high" cho 1–2 tài nguyên mỗi trang thôi.
2. Preload ảnh rồi lại đặt loading="lazy" cho chính ảnh đó — hai lệnh đá nhau. Phần tử LCP không bao giờ được lazy-load.
3. Preload tài nguyên trang không thực sự cần (một font weight không dùng, một ảnh nằm dưới màn hình đầu). Băng thông bị hút đi khỏi nội dung tới hạn.

Phép thử đơn giản: chỉ preload những gì ảnh hưởng trực tiếp tới điểm LCP của màn hình đầu. Đo lại bằng PageSpeed Insights hoặc Lighthouse sau mỗi lần thêm hint — nếu LCP không nhúc nhích hoặc tệ đi, gỡ hint đó ra.

prefetch — chuẩn bị cho trang kế tiếp

Khác hẳn ba hint trên (đều phục vụ trang hiện tại), prefetch tải trước tài nguyên cho lần điều hướng sau, ở mức ưu tiên thấp để không tranh với trang đang xem.

<link rel="prefetch" href="/san-pham/chi-tiet.html" as="document">

Chỉ dùng khi bạn khá chắc người dùng sẽ đi tiếp — ví dụ bước kế trong luồng thanh toán, hay trang chi tiết từ trang danh sách. Đoán mò sẽ tải về thứ chẳng ai mở, tốn dữ liệu của khách (nhất là 4G). web.dev khuyên tôn trọng tín hiệu Save-Data: người dùng bật tiết kiệm dữ liệu thì đừng prefetch.

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

preload và prefetch khác nhau ở đâu?

preload tải tài nguyên tới hạn cho trang đang xem ở ưu tiên cao. prefetch tải trước cho trang kế tiếp ở ưu tiên thấp. Một cái phục vụ ngay, một cái dự phòng cho sau.

preconnect khác dns-prefetch chỗ nào?

dns-prefetch chỉ tra DNS. preconnect làm trọn cả DNS, TCP và TLS nên dọn đường sâu hơn nhưng tốn tài nguyên hơn, vì vậy chỉ dành cho vài domain quan trọng nhất.

Có cần gắn nhiều preload để web nhanh không?

Không. Gắn nhiều preload thường phản tác dụng vì chúng giành băng thông lẫn nhau. Chỉ preload font màn hình đầu và ảnh LCP, rồi đo lại để kiểm chứng.

Cần rà toàn bộ resource hint và thứ tự tải tài nguyên cho website của bạn, dịch vụ tối ưu tốc độ website của Web22 có thể giúp soi và sửa từ gốc.