Tại sao hình ảnh làm chậm website của bạn và các giải pháp tăng tốc hiệu quả

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

Trên hầu hết các trang web chậm mà tôi kiểm tra, nguyên nhân đều giống nhau: đó là hình ảnh. Văn bản, phông chữ và JavaScript đều quan trọng, nhưng media (đa phương tiện) là thành phần chiếm trọng lượng chủ đạo trên một trang nội dung hoặc thương mại điện tử điển hình, và đây lại là phần mà các nhóm tối ưu hóa cuối cùng. Bài viết này tập trung hẹp vào cách hình ảnh ảnh hưởng đến tốc độ tải trang, cùng với các giải pháp khắc phục mà tôi đã đo lường trong môi trường sản xuất. Đối với bức tranh tổng thể hơn, hướng dẫn tối ưu hóa tốc độ website cũng bao gồm cả mã code, phông chữ và caching.

Trả lời nhanh: hình ảnh làm chậm trang web như thế nào?

Hình ảnh thường chiếm 60 đến 80 phần trăm tổng trọng lượng trang, và trên các trang nặng về hình ảnh, chúng là đòn bẩy lớn nhất đối với thời gian tải. Bốn giải pháp khắc phục mang lại hiệu quả cao nhất là cung cấp định dạng hiện đại ở kích thước hiển thị chính xác, nén để đạt chất lượng hợp lý, lazy-loading media dưới phần cuộn (below-the-fold), và đặt các tài sản này sau một CDN.

Trên một blog khách hàng tôi đo lường, bốn thay đổi đó đã giảm trọng lượng trang từ 3.4 MB xuống còn 690 KB và Largest Contentful Paint từ 4.8 giây xuống 1.9 giây. Hãy bắt đầu với những hình ảnh lớn nhất và đo trước và sau khi tối ưu hóa.

Tại sao hình ảnh làm chậm trang web của bạn?

Mọi hình ảnh đều là một yêu cầu mạng cộng với các byte mà trình duyệt phải tải xuống, giải mã và hiển thị. Trên một trang điển hình, lượng byte này vượt xa mọi thứ khác. Tôi đã phân tích trọng lượng trên cùng một trang khách hàng, được sắp xếp theo danh mục:

Hình ảnh lớn hơn tất cả các danh mục khác cộng lại, đó là lý do tại sao công việc với hình ảnh mang lại lợi ích nhanh hơn bất kỳ thay đổi nào khác. Cùng một byte cũng tốn thời gian giải mã: một bức ảnh 4 MB sẽ chặn luồng chính (main thread) trong khi trình duyệt đang nén nó, ngay cả sau khi quá trình tải xuống hoàn tất.

Ba cơ chế, theo thứ tự tôi thường gặp nhất, giải thích sự chậm trễ này:

• Excess bytes — gửi một bức ảnh 4000 pixel vào một ô kích thước 400 pixel.
• Wrong format — dùng PNG màu đầy đủ cho ảnh chụp thay vì WebP.
• Unoptimized delivery — không có CDN, không caching, và không biến thể responsive.

Hai điểm đầu tiên liên quan đến những gì bạn gửi đi. Điểm thứ ba liên quan đến cách bạn gửi nó. Mỗi điểm đều có một giải pháp rõ ràng, được đề cập bên dưới.

Trọng lượng trang thực sự tốn bao nhiêu giây?

Trọng lượng trang chuyển thành thời gian thông qua mạng. Một quy tắc ước tính nhưng hữu ích: điện thoại tầm trung trên kết nối 4G tải xuống với tốc độ khoảng 1 đến 1.5 MB mỗi giây trong thế giới thực, chứ không phải tốc độ đỉnh lý thuyết. Vì vậy, một trang 3.4 MB mất khoảng 3 giây chỉ để tải về, trước khi trình duyệt làm bất kỳ công việc nào.

Tôi đã đo điều này trực tiếp trên trang khách hàng, giữ mọi thứ khác không đổi và chỉ thay đổi trọng lượng hình ảnh:

Mỗi megabyte bạn cắt đi tương đương với khoảng một giây tiết kiệm trên kết nối di động điển hình. Đó là lý do tại sao trọng lượng hình ảnh quan trọng hơn bất kỳ tối ưu hóa nhỏ nào trong CSS hoặc JavaScript của bạn. Google tài liệu mối quan hệ giữa trọng lượng trang và hiệu suất tải trong web.dev fast guide, và PageSpeed Insights đánh dấu các hình ảnh quá khổ là một trong những lỗi kiểm tra hàng đầu.

Làm thế nào để cung cấp định dạng và kích thước phù hợp?

Thành tựu lớn nhất là chuyển đổi các bức ảnh từ JPG và PNG sang định dạng hiện đại và thay đổi kích thước chúng theo kích thước hiển thị. WebP nhỏ hơn khoảng 25 đến 35 phần trăm so với JPG ở cùng chất lượng cảm nhận; AVIF còn tốt hơn nữa nhưng có tốc độ mã hóa kém ổn định hơn (spottier encode speed). Tôi mặc định sử dụng WebP vì nó giải mã nhanh và hoạt động ở mọi nơi trong năm 2026.

1. Thay đổi kích thước theo kích thước hiển thị. Một bức ảnh 4000 pixel trong một ô kích thước 400 pixel lớn hơn gấp mười lần so với cần thiết. Giới hạn hình ảnh nội dung ở mức 1600 đến 1920 pixels trên cạnh dài.

2. Chuyển đổi sang WebP với chất lượng 75 đến 82. Phạm vi này gần như không thể phân biệt được với nguồn đối với ảnh chụp và loại bỏ nhiều byte nhất. Nếu đẩy thấp hơn, hiện tượng banding sẽ xuất hiện ở bầu trời và các gradient màu.

3. Giữ một biến thể AVIF chỉ dành cho phần hero nếu bạn hỗ trợ nó, vì mã hóa AVIF chậm và chỉ đáng giá cho hình ảnh trở thành phần tử Largest Contentful Paint của bạn.

Để biết kích thước chính xác theo trường hợp sử dụng, hướng dẫn thay đổi kích thước hình ảnh cho web có các con số này. Để đạt chất lượng mà không bị lỗi (artifacts), quy trình nén hình ảnh mà không mất chất lượng sẽ hướng dẫn tôi cách thiết lập WebP.

Làm thế nào để nén và chuyển đổi trước khi gửi đi?

Việc nén nên xảy ra trong quá trình build, không bao giờ trong trình duyệt. Mục tiêu là một nguồn hình ảnh duy nhất trở thành các biến thể tối ưu tự động.

## Chuyển hero sang WebP ở kích thước hiển thị, chất lượng 80
cwebp -q 80 -resize 1920 0 hero.jpg -o hero-1920.webp

Đối với một thư mục đầy đủ, tôi sử dụng một vòng lặp nhỏ để xuất ra nhiều chiều rộng khác nhau. Kỷ luật quan trọng là không bao giờ cam kết một bức ảnh thô 5 MB.

• Đặt mức chất lượng tối thiểu là 70 cho nội dung và 75 cho ảnh sản phẩm, sau đó tinh chỉnh bằng mắt thường trên hình ảnh thực tế.
• Loại bỏ metadata (EXIF, color profiles bạn không cần) — nó có thể thêm hàng chục kilobytes mà không mang lại lợi ích thị giác nào.
• Tạo một biến thể cho mỗi breakpoint thay vì một hình ảnh khổng lồ cho mọi thiết bị.
• Tự động hóa trong CI để một hình ảnh chưa tối ưu không bao giờ đến được môi trường sản xuất.

Một lỗi phổ biến là nén tệp tải lên nhưng quên mất tất cả các thumbnail và biến thể responsive mà CMS tạo ra. Chạy quy trình trên tất cả các kích thước, chứ không chỉ nguồn gốc. Đây là bước tôi đã đo lường mức giảm mạnh nhất về trọng lượng trang — thường từ 70 đến 80 phần trăm so với bản gốc.

Làm thế nào để lazy-load dưới phần cuộn?

Hình ảnh dưới phần cuộn không được chặn lần hiển thị đầu tiên (first render). Lazy loading nguyên bản thực hiện điều này bằng một thuộc tính và không cần JavaScript.

<img src="gallery-1-800.webp"
     width="800" height="600"
     loading="lazy" decoding="async"
     alt="Ảnh sản phẩm trong ánh sáng tự nhiên">

Hai thuộc tính quan trọng hơn người ta nghĩ:

1. loading="lazy" trì hoãn việc tải cho đến khi hình ảnh gần viewport, vì vậy nó không bao giờ cạnh tranh với lần hiển thị đầu tiên (first paint).
2. width và height cho phép trình duyệt dự trữ ô chứa trước khi hình ảnh đến, điều này ngăn chặn Cumulative Layout Shift.

Không lazy-load hình ảnh hero hoặc LCP — điều đó làm chậm phần tử quan trọng nhất trên trang. Quy tắc tôi tuân theo: lazy-load mọi thứ dưới phần cuộn, eager-load (tải ngay) hình ảnh mà người dùng nhìn thấy đầu tiên.

CDN tăng tốc hình ảnh như thế nào?

CDN phục vụ hình ảnh từ một máy chủ gần mỗi khách truy cập, điều này cắt giảm vòng khứ hồi mạng (network round-trip) vốn chi phối lần hiển thị đầu tiên trên thiết bị di động và lưu lượng quốc tế. Trên trang khách hàng, việc thêm CDN phía trước các hình ảnh đã giảm LCP thêm 400 milliseconds đối với khách truy cập ngoài khu vực gốc (origin region).

CDN cũng cung cấp cho bạn khả năng biến đổi tức thời (on-the-fly transforms): yêu cầu bất kỳ chiều rộng hoặc định dạng nào bằng URL, và edge sẽ tạo và lưu vào cache. Điều đó loại bỏ nhu cầu phải tự tạo trước hàng chục biến thể. Hướng dẫn CDN hình ảnh đề cập chi tiết về các header và khóa cache.

Đặt một giá trị dài Cache-Control: max-age=31536000, immutable trên các URL hình ảnh có fingerprint để khách truy cập quay lại tái sử dụng chúng. Xóa cache khi triển khai (deploy) khi fingerprint thay đổi.

Hình ảnh responsive phù hợp như thế nào?

Hình ảnh responsive cho trình duyệt biết chính xác biến thể nào cần tải xuống cho viewport hiện tại, vì vậy điện thoại sẽ không bao giờ tải hình ảnh hero của máy tính để bàn. Các thuộc tính srcset và sizes là cách gốc (native) và không phụ thuộc vào thư viện để làm điều này.

<img srcset="hero-640.webp 640w,
             hero-960.webp 960w,
             hero-1280.webp 1280w,
             hero-1920.webp 1920w"
     sizes="(max-width: 768px) 100vw, 50vw"
     src="hero-1280.webp"
     width="1280" height="853"
     loading="eager" fetchpriority="high"
     alt="Hình ảnh hero của một máy tính xách tay đang tải trang web">

Trình duyệt chọn biến thể nhỏ nhất vẫn lấp đầy ô chứa theo tỷ lệ pixel của thiết bị. Trên điện thoại thường là tệp 640w, chỉ bằng một phần tư byte của tệp 1920w. Thêm fetchpriority="high" vào hình ảnh LCP để trình duyệt ưu tiên nó trong quá trình tải sớm.

Làm thế nào tôi đo tác động của hình ảnh?

Bạn không thể cải thiện những gì bạn không đo lường được. Hai công cụ bao quát tốt cho công việc liên quan đến hình ảnh.

• PageSpeed Insights — chạy tại pagespeed.web.dev. Nó báo cáo dữ liệu trường (field data) từ người dùng thực và đánh dấu trực tiếp các hình ảnh quá khổ và thiếu định dạng thế hệ mới.
• Lighthouse — bài kiểm tra lab đằng sau PageSpeed Insights. Chrome tài liệu hóa việc kiểm tra hình ảnh trong hướng dẫn nhà phát triển Lighthouse. Nó nêu tên các hình ảnh cụ thể đang lãng phí byte.
• Chrome DevTools Network tab — lọc theo Img, sắp xếp theo kích thước, và ghi chú những thủ phạm hàng đầu. Đây là cách tôi tìm ra một hoặc hai hình ảnh đáng sửa chữa trước tiên.
• WebPageTest — một waterfall (thác nước) và filmstrip cho thấy chính xác khi nào mỗi hình ảnh được tải xuống và nó làm thay đổi bố cục như thế nào.

Khi lab và field không đồng nhất, hãy tin vào dữ liệu trường (field data). Một điểm lab sạch trên máy nhanh qua Wi-Fi chẳng có ý nghĩa gì nếu người dùng di động thực tế trên 4G vẫn phải chờ đợi. Bởi vì hình ảnh thúc đẩy Largest Contentful Paint trên hầu hết các trang, công việc với hình ảnh cũng là công việc Core Web Vitals — hướng dẫn tối ưu hóa hình ảnh cho Core Web Vitals liên kết hai điều này lại với nhau.

Tôi nên tránh những gì?

• Theo đuổi điểm số hoàn hảo, chứ không phải người dùng. Điểm 100 trong lab là vô giá nếu LCP thực tế vẫn là 4 giây.
• Nén quá mức (Over-compressing). Giảm chất lượng quá nhiều giúp tiết kiệm byte nhưng làm hỏng ảnh sản phẩm. Hãy thử nghiệm trên hình ảnh thực, không phải mẫu.
• 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 lần tải chậm đều là từ thiết bị di động. Tối ưu hóa cho điện thoại tầm trung trên 4G, chứ không phải laptop dev của bạn.
• Tối ưu một lần. Hiệu suất giảm dần khi hình ảnh và tính năng mới được triển khai. Hãy kiểm tra lại sau mỗi bản phát hành.
• Một hình ảnh khổng lồ cho mọi thiết bị. Nếu không có srcset, điện thoại sẽ tải hình ảnh hero của máy tính để bàn.

Điểm mấu chốt

Hình ảnh là đòn bẩy lớn nhất đối với tốc độ website vì chúng chiếm tỷ trọng lớn nhất về trọng lượng trang. Bốn giải pháp — định dạng hiện đại ở kích thước hiển thị, nén, lazy-loading và CDN — tuy không hào nhoáng nhưng chính là thứ đã đưa trang khách hàng của tôi từ 3.4 MB và LCP 4.8 giây xuống còn 690 KB và LCP 1.9 giây. Hãy thực hiện chúng theo thứ tự đó, đo lường từng bước, và sửa các hình ảnh lớn nhất trước.

Một lưu ý trung thực: các con số byte và giây chính xác ở trên là từ một trang khách hàng, và của bạn sẽ khác nhau tùy thuộc vào nội dung, lưu lượng truy cập và CDN. Hãy chạy PageSpeed Insights trên các URL của riêng bạn trước và sau khi tối ưu hóa, và để dữ liệu trường (field data) từ người dùng thực — chứ không phải điểm lab gọn gàng — là người đánh giá xem nó có hiệu quả hay không.

Tín dụng hình ảnh

• Màn hình máy tính hiện đại hiển thị công việc thiết kế web trong một không gian làm việc sáng tạo — photo by Tranmautritam trên Pexels
• Cận cảnh màn hình laptop hiển thị trang tìm kiếm đang tải — photo by cottonbro studio trên Pexels
• Lập trình viên gõ code trên laptop trong một không gian làm việc tập trung — photo by olia danilevich trên Pexels