Cách thay đổi kích thước hình ảnh cho web: Kích cỡ, Retina và srcset

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

Tôi đã thay đổi kích thước cùng một ảnh hero theo bốn cách và đo lường sự khác biệt: một JPEG camera 4.2MB, được phục vụ nguyên bản tại khe hiển thị 800px, đã trở thành WebP 94KB mà không mất chất lượng nhìn thấy được. Thay đổi kích thước hình ảnh cho web là lợi ích lớn nhất về trọng lượng trang có thể đạt được, và phần lớn nó phụ thuộc vào bốn quyết định: kích thước hiển thị, hệ số retina, định dạng và nén. Đây là quy trình làm việc tôi áp dụng trên mọi trang web mà tôi triển khai.

Câu trả lời nhanh: bạn nên thay đổi kích thước hình ảnh cho web như thế nào?

Hãy thay đổi kích thước mỗi hình ảnh thành khoảng gấp đôi chiều rộng mà nó hiển thị (hệ số retina), xuất nó dưới dạng WebP, nén ở chất lượng 80, và cung cấp một srcset ngắn để điện thoại và máy tính xách tay đều nhận được tệp phù hợp. Đối với một hero full-width hiển thị ở 1920px, thường chỉ cần một WebP từ 1920 đến 2560px ở chất lượng 80 là đủ. Nếu bỏ qua bước này, bạn buộc mọi thiết bị phải tải xuống các pixel độ phân giải máy tính để bàn.

Một hình ảnh web thực tế nên có kích thước bao nhiêu?

Kích thước đúng là kích thước hiển thị, chứ không phải kích thước nguồn. Mở DevTools, kiểm tra hình ảnh, đọc chiều rộng hộp CSS lớn nhất mà nó từng chiếm qua các điểm ngắt (breakpoints), sau đó xuất ra với chiều rộng đó nhân với mục tiêu mật độ của bạn.

Đối với hầu hết hình ảnh bài viết và sản phẩm nằm trong một phạm vi có thể dự đoán được. Tôi đo mọi khe trước khi xuất, bởi vì việc đoán mò là lý do khiến một bức ảnh 4000px lại xuất hiện trong cột 600px.

Không bao giờ để CSS thực hiện việc giảm kích thước. Một <img> được tạo kiểu là width: 400px vẫn tải xuống toàn bộ tệp — trình duyệt sẽ loại bỏ các pixel thừa sau khi byte đã truyền qua đường dây. Hãy thay đổi kích thước nguồn trước, sau đó chỉ tin tưởng vào CSS cho bố cục.

Từng bước: quy trình làm việc thay đổi kích thước của tôi

Đây là chuỗi chính xác mà tôi thực hiện. Tôi đã kiểm tra nó với một bản kiểm toán hình ảnh Lighthouse và nó luôn vượt qua bài kiểm tra "hình ảnh được định cỡ đúng cách".

• Đo chiều rộng hiển thị lớn nhất bằng DevTools.
• Nhân với 2 cho retina (chỉ nhân 3 cho các bức ảnh hero điện thoại dày đặc).
• Thay đổi kích thước xuống với bộ lọc chất lượng cao (Lanczos).
• Xuất dưới dạng WebP ở chất lượng 80, giảm xuống 75 nếu tệp vẫn nặng.
• Tạo một srcset ladder cho các khe phản hồi.
• Nén lại nếu tệp vẫn trên 200KB.

from PIL import Image

def resize_for_web(src, out, max_width=1440, quality=80):
    img = Image.open(src)
    if img.width > max_width:
        ratio = max_width / img.width
        img = img.resize((max_width, int(img.height * ratio)),
                         Image.LANCZOS)
    img.save(out, "WEBP", quality=quality)

Khi tôi đo lường nó, điều này đã biến một bức ảnh 4000x2667 (JPEG 4.2MB) thành WebP 1440x960 ở mức 94KB — giảm 98 phần trăm mà không mất độ sắc nét nhìn thấy được trên màn hình tiêu chuẩn. Các quy tắc sâu hơn về việc giữ chi tiết qua quá trình giảm kích thước mạnh mẽ có trong keep quality while resizing.

Retina và 2x: bạn có thực sự cần gấp đôi pixel không?

Phần lớn là có, đối với bất cứ thứ gì người dùng nhìn kỹ. Màn hình 2x chứa bốn lần số pixel trong cùng một không gian vật lý, vì vậy tệp 1x trông mềm mại. Quy tắc an toàn: xuất ở mức 2x chiều rộng CSS cho các hình ảnh nội dung.

Nơi tôi cố tình phá vỡ quy tắc đó:

• Các nền trang trí mờ hoặc chuyển màu có thể giữ gần 1x.
• Hình ảnh dưới phần cuộn (below-the-fold) nơi độ sắc nét ít quan trọng hơn có thể sử dụng 1.5x.
• Biểu tượng và logo tốt hơn nên là SVG, vốn độc lập với độ phân giải.

Hướng dẫn hình ảnh web của Google khuyến nghị các mô tả mật độ (density descriptors) hoặc mô tả chiều rộng (width descriptors); mô tả chiều rộng qua srcset dễ hiểu hơn nhiều, vì vậy đó là điều tôi mặc định sử dụng.

Phục vụ các biến thể phản hồi bằng srcset

Một tệp cho mỗi hình ảnh hiếm khi phù hợp với mọi thiết bị. Điện thoại không cần một tệp 1440px, và màn hình 4K cũng không nên hài lòng với kích thước 480px. srcset cho phép bạn cung cấp nhiều chiều rộng và để trình duyệt tự chọn.

<img
  src="hero-960.webp"
  srcset="hero-480.webp 480w, hero-720.webp 720w,
          hero-960.webp 960w, hero-1440.webp 1440w"
  sizes="(min-width: 900px) 720px, 92vw"
  alt="Minh họa hero về đường chân trời thành phố lúc hoàng hôn"
  width="960" height="640" loading="lazy">

Thuộc tính sizes phải nói sự thật về khe hiển thị. Nếu bạn để nó ở giá trị mặc định 100vw, trình duyệt sẽ giả định hình ảnh trải dài toàn bộ viewport và tải xuống biến thể lớn nhất. Việc chọn các chiều rộng nào để tạo là một quyết định riêng — phương pháp tôi sử dụng để cắt giảm ladder này có trong responsive image breakpoints.

Kích thước tệp so với kích thước: cái nào quan trọng hơn?

Cả hai đều quan trọng, nhưng vì những lý do khác nhau. Kích thước quyết định số lượng pixel; nén và định dạng quyết định byte trên mỗi pixel. Một hình ảnh được định cỡ đúng cách với việc nén kém vẫn nặng, và một hình ảnh nhỏ nhưng bị nén quá mức trông sẽ bị lỗi.

Mục tiêu tôi hướng tới là dưới 200KB đối với hầu hết các hình ảnh nội dung, và dưới 100KB đối với bất cứ thứ gì nằm trên phần cuộn (above the fold) ảnh hưởng đến Largest Contentful Paint. Khi một tệp vượt qua mức đó, đòn bẩy đầu tiên tôi kéo là chất lượng nén, sau đó là định dạng. Phân tích chi tiết cấp byte về cách nén giảm trọng lượng có trong compress without losing quality.

Lighthouse gắn cờ các hình ảnh quá kích thước như một cơ hội cụ thể. Chạy nó từ Chrome DevTools hoặc làm theo tài liệu Lighthouse — bản kiểm toán "hình ảnh được định cỡ đúng cách" báo cáo chính xác bạn lãng phí bao nhiêu KB bằng cách phục vụ nhiều pixel hơn mức khe cần.

Chọn định dạng phù hợp

Định dạng là nơi rất nhiều byte bị ẩn giấu. Tôi mặc định sử dụng WebP cho hầu hết mọi thứ mang tính nhiếp ảnh, với AVIF khi tôi có thể đảm bảo fallback. Việc khớp định dạng với nội dung quan trọng như kích thước: một PNG được dùng cho ảnh thì nặng hơn cùng tệp dưới dạng WebP mà không mang lại lợi ích gì.

Hướng dẫn hình ảnh phản hồi MDN đề cập đến phần tử <picture> để phục vụ AVIF với fallback WebP hoặc JPEG. Tôi chỉ tìm đến <picture> khi tôi cần đàm phán định dạng; đối với các ảnh phản hồi đơn giản, srcset là đủ.

Những lỗi tôi thấy khi kiểm toán trang web

Khi tôi kiểm toán một trang web chậm, các vấn đề về hình ảnh lặp lại. Đây là những thứ tôi sửa thường xuyên nhất.

• Tải lên các tệp độ phân giải camera và giảm kích thước chúng bằng CSS.
• Một tệp khổng lồ cho mọi điểm ngắt thay vì srcset ladder.
• Quên width và height, điều này gây ra dịch chuyển bố cục (layout shift).
• Để sizes ở giá trị mặc định khiến trình duyệt lấy tệp lớn nhất.
• Tải tất cả hình ảnh một cách háo hức (eagerly) thay vì trì hoãn những cái nằm dưới phần cuộn.

Mục cuối cùng đó là hiệu suất miễn phí. Mẫu để trì hoãn các hình ảnh ngoài màn hình được đề cập trong lazy loading images — thêm loading="lazy" và trình duyệt sẽ bỏ qua các hình ảnh mà người dùng chưa cuộn đến.

Tóm tắt

Trước khi tôi triển khai một hình ảnh, tôi thực hiện danh sách này: thay đổi kích thước thành 2x chiều rộng hiển thị lớn nhất, xuất dưới dạng WebP, nén dưới 200KB, với srcset ladder, thuộc tính sizes trung thực, width và height rõ ràng, loading="lazy" dưới phần cuộn, và văn bản alt mô tả.

Một lưu ý thực tế: thay đổi kích thước là đòn bẩy lớn nhất, nhưng nó không phải là toàn bộ công việc. Tôi đã thấy các nhóm làm tốt về kích thước nhưng vẫn triển khai các trang chậm vì họ phục vụ tệp từ nguồn gốc mà không có caching, không CDN và không tên tệp được hash nội dung. Hãy đo bằng Lighthouse và hồ sơ thiết bị thực tế, sau đó tin vào những con số hơn là danh sách kiểm tra. Một WebP 94KB mà trình duyệt tải lại trên mỗi lần điều hướng vẫn là một sai lầm 94KB.

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

Hình ảnh hero web nên có kích thước bao nhiêu?

Khớp với kích thước hiển thị: khoảng 1600px chiều rộng cho hero full-width, 800–1200px cho hình ảnh cột nội dung. Xuất ở mức 2x kích thước hiển thị (cho retina) sẽ nhân đôi pixel; hãy phục vụ đúng kích thước cho từng thiết bị bằng srcset thay vì gửi một tệp khổng lồ.

Tôi có cần hình ảnh 2x cho màn hình retina không?

Đối với đồ họa sắc nét và ảnh hero, có — màn hình retina hiển thị sự mềm mại nếu không làm vậy. Đối với hình ảnh dưới phần cuộn và trang trí, thường chỉ cần một tệp 1x. Sử dụng srcset để phục vụ các biến thể 1x và 2x để thiết bị không phải retina không tải xuống tệp lớn.

Kích thước hay kích thước tệp quan trọng hơn?

Cả hai, nhưng kích thước tệp ảnh hưởng đến Core Web Vitals nhiều hơn. Thay đổi kích thước theo kích thước hiển thị trước (loại bỏ pixel lãng phí), sau đó nén về chất lượng mục tiêu (loại bỏ byte lãng phí). Hướng dẫn tốc độ web đề cập đến toàn bộ thứ tự này.

Làm cách nào để tôi phục vụ các biến thể phản hồi?

Sử dụng srcset với nguồn cụ thể theo kích thước và thuộc tính sizes mô tả chiều rộng hiển thị, cho phép trình duyệt chọn tệp phù hợp cho từng viewport. Tạo mỗi kích thước từ bản gốc, sau đó để trình duyệt lựa chọn. Xem responsive images guide.

srcset là gì?

Một thuộc tính HTML liệt kê nhiều nguồn hình ảnh ở các kích thước khác nhau, cho phép trình duyệt chọn đúng cái theo viewport. Nó phục vụ một tệp nhỏ cho màn hình nhỏ và một tệp lớn cho màn hình lớn, giúp tiết kiệm byte. Xem responsive images guide.

Thuộc tính sizes là gì?

Một thuộc tính HTML cho biết trình duyệt hình ảnh hiển thị rộng bao nhiêu ở mỗi điểm ngắt, để trình duyệt có thể chọn đúng nguồn srcset trước khi tải xuống. Nếu không có sizes, trình duyệt sẽ đoán mò. Kết hợp srcset (các nguồn) với sizes (chiều rộng hiển thị) cho các hình ảnh phản hồi tải xuống hiệu quả. Xem responsive images guide.

Tín dụng hình ảnh

• Một chiếc MacBook trên bàn làm việc hiển thị bố cục trang web được thiết kế — photo by Tranmautritam on Pexels
• Ảnh chụp cận cảnh màn hình máy tính hiển thị các dòng mã nguồn — photo by Nemuel Sereti on Pexels
• Màn hình máy tính xách tay hiển thị trang web đang tải trong tab trình duyệt — photo by cottonbro studio on Pexels