Trong mô-đun này, bạn sẽ tìm hiểu cách cho phép trình duyệt lựa chọn hình ảnh để trình duyệt có thể đưa ra quyết định tốt nhất về nội dung cần hiển thị. srcset
không phải là phương thức hoán đổi nguồn hình ảnh tại các điểm ngắt cụ thể và không nhằm hoán đổi hình ảnh này bằng hình ảnh khác. Những cú pháp này cho phép
trình duyệt để giải quyết một vấn đề rất khó khăn không phụ thuộc vào chúng tôi: yêu cầu và hiển thị liền mạch nguồn hình ảnh được điều chỉnh cho phù hợp với ngữ cảnh duyệt web của người dùng,
bao gồm kích thước khung nhìn, mật độ hiển thị, lựa chọn ưu tiên của người dùng, băng thông và vô số các yếu tố khác.
Đó là một câu hỏi lớn – chắc chắn là nhiều hơn những gì chúng tôi muốn xem xét khi chúng tôi chỉ đơn giản là đánh dấu một hình ảnh cho web và để thực hiện tốt việc này cũng liên quan đến nhiều hơn thông tin mà chúng tôi có thể tiếp cận.
Mô tả mật độ bằng x
<img>
có chiều rộng cố định sẽ chiếm cùng một dung lượng khung nhìn trong mọi ngữ cảnh duyệt web, bất kể mật độ của người dùng
hiển thị—số pixel vật lý tạo màn hình. Ví dụ: một hình ảnh có chiều rộng vốn có là 400px
sẽ chiếm gần như
toàn bộ khung nhìn của trình duyệt trên cả Google Pixel nguyên bản và Pixel 6 Pro mới hơn nhiều – cả hai thiết bị đều có 412px
chuẩn hoá
khung nhìn rộng pixel logic.
Tuy nhiên, Pixel 6 Pro có màn hình sắc nét hơn: 6 Pro có độ phân giải vật lý là 1440 × 3120 pixel, trong khi Pixel có kích thước 1080 × 1920 pixel, nghĩa là số lượng pixel phần cứng tạo nên màn hình.
Tỷ lệ giữa pixel logic của thiết bị và pixel vật lý là tỷ lệ pixel của thiết bị trên màn hình đó (DPR). DPR mới là được tính bằng cách chia độ phân giải màn hình thực tế của thiết bị cho pixel CSS của khung nhìn.
Vì vậy, Pixel gốc có DPR là 2,6, trong khi Pixel 6 Pro có DPR là 3,5.
iPhone 4, thiết bị đầu tiên có DPR lớn hơn 1, báo cáo tỷ lệ pixel của thiết bị là 2 – độ phân giải vật lý của màn hình là gấp đôi độ phân giải logic. Mọi thiết bị trước iPhone 4 đều có DPR là 1: một pixel logic so với một pixel vật lý.
Nếu bạn xem hình ảnh có chiều rộng 400px
đó trên một màn hình có DPR là 2
, thì mỗi pixel logic sẽ được kết xuất trên bốn trong số
pixel vật lý của màn hình: hai pixel ngang và hai pixel dọc. Hình ảnh này không được hưởng lợi từ màn hình với mật độ điểm ảnh cao—hình ảnh này sẽ trông
giống như trên màn hình có DPR là 1
. Tất nhiên, mọi thứ "vẽ" bởi công cụ hiển thị của trình duyệt—văn bản, hình dạng CSS hoặc SVG,
chẳng hạn – sẽ được vẽ cho phù hợp với màn hình có mật độ điểm ảnh cao hơn. Nhưng như bạn đã tìm hiểu từ Định dạng và nén hình ảnh, hình ảnh đường quét đã được khắc phục
lưới pixel. Mặc dù hình ảnh đường quét có thể không phải lúc nào cũng rõ ràng, nhưng hình ảnh đường quét được tăng kích thước để phù hợp với màn hình có mật độ điểm ảnh cao hơn sẽ trông
có độ phân giải thấp so với trang xung quanh.
Để tránh việc nâng cấp hình ảnh, hình ảnh kết xuất phải có chiều rộng nội tại ít nhất là 800
pixel. Khi thu nhỏ
để vừa với một không gian có bố cục rộng 400 pixel logic, thì nguồn hình ảnh 800 pixel đó có mật độ pixel gấp đôi — trên màn hình có DPR là 2
,
ảnh đó trông đẹp và sắc nét.
Vì màn hình có DPR là 1
không thể tận dụng mật độ tăng của hình ảnh, nên hình ảnh sẽ được giảm tỷ lệ để khớp với
và như bạn đã biết, hình ảnh được điều chỉnh theo tỷ lệ sẽ trông ổn. Trên màn hình có mật độ điểm ảnh thấp, hình ảnh phù hợp với mật độ điểm ảnh cao hơn
sẽ trông giống như bất kỳ hình ảnh có mật độ điểm ảnh thấp nào khác.
Như bạn đã tìm hiểu trong phần Hình ảnh và hiệu suất, một người dùng có màn hình với mật độ điểm ảnh thấp xem nguồn hình ảnh được thu nhỏ xuống 400px
sẽ chỉ cần nguồn có chiều rộng vốn có là 400px
. Mặc dù một hình ảnh lớn hơn nhiều sẽ phù hợp
cho tất cả người dùng về mặt trực quan, nhưng
nguồn hình ảnh có độ phân giải cao được kết xuất trên màn hình nhỏ, có mật độ thấp sẽ trông giống như mọi hình ảnh nhỏ, có mật độ thấp khác, nhưng cảm thấy chậm hơn nhiều.
Như bạn có thể đoán, các thiết bị di động có DPR là 1 là rất hiếm, mặc dù vấn đề này vẫn phổ biến trong "máy tính" bối cảnh duyệt web. Theo dữ liệu Theo Matt Hobbs, khoảng 18% số phiên duyệt web trên GOV.UK từ tháng 11 năm 2022 báo cáo DPR là 1. Mặc dù hình ảnh có mật độ điểm ảnh cao sẽ giống theo cách mà người dùng có thể mong đợi, nhưng chúng sẽ tốn băng thông và chi phí xử lý cao hơn nhiều so với mối quan tâm đặc biệt của người dùng trên các thiết bị cũ và kém mạnh mẽ hơn vẫn có khả năng sử dụng màn hình với mật độ điểm ảnh thấp.
Việc sử dụng srcset
đảm bảo rằng chỉ các thiết bị có màn hình độ phân giải cao mới nhận được nguồn hình ảnh đủ lớn để trông sắc nét mà không truyền cùng loại đó
chi phí băng thông cho những người dùng có màn hình có độ phân giải thấp hơn.
Thuộc tính srcset
xác định một hoặc nhiều ứng dụng được phân tách bằng dấu phẩy để hiển thị hình ảnh. Mỗi ứng cử viên bao gồm
hai thứ: một URL, giống như cách bạn sử dụng trong src
và cú pháp mô tả nguồn hình ảnh đó. Mỗi ứng cử viên tại srcset
được mô tả theo chiều rộng vốn có ("cú pháp w
") hoặc mật độ dự định ("cú pháp x
").
Cú pháp x
là cách viết tắt của "nguồn này phù hợp với màn hình có mật độ này" – một đề xuất theo sau là 2x
là
phù hợp với màn hình có DPR là 2.
<img src="low-density.jpg" srcset="double-density.jpg 2x" alt="...">
Trình duyệt hỗ trợ srcset
sẽ hiển thị hai đề xuất: double-density.jpg
, trong đó 2x
mô tả là phù hợp
đối với các màn hình có DPR là 2 và low-density.jpg
trong thuộc tính src
– ứng viên được chọn nếu không có gì phù hợp hơn là
được tìm thấy trong srcset
. Đối với trình duyệt không hỗ trợ srcset
, thuộc tính và nội dung của thuộc tính đó sẽ bị bỏ qua (nội dung của src
)
sẽ được yêu cầu, như thường lệ.
Bạn có thể dễ dàng nhầm lẫn các giá trị được chỉ định trong thuộc tính srcset
với hướng dẫn. 2x
đó thông báo cho trình duyệt rằng
tệp nguồn được liên kết sẽ phù hợp để sử dụng trên màn hình có DPR là 2 (thông tin về chính nguồn đó). Không cho biết
trình duyệt cách sử dụng nguồn đó, chỉ cần thông báo cho trình duyệt cách sử dụng nguồn. Đó là một sự khác biệt nhỏ nhưng quan trọng:
là hình ảnh mật độ kép, không phải là hình ảnh để sử dụng trên màn hình có mật độ kép.
Sự khác biệt giữa cú pháp cho biết "nguồn này phù hợp với màn hình 2x
" và một dòng có nội dung "sử dụng nguồn này trên màn hình 2x
"
được in rất ít, nhưng mật độ hiển thị chỉ là một trong số rất nhiều yếu tố liên kết mà trình duyệt sử dụng để quyết định về ứng cử viên
để hiển thị, chỉ một số dữ liệu trong số đó bạn có thể biết. Ví dụ: riêng lẻ, bạn có thể xác định rằng người dùng đã bật
Tuỳ chọn trình duyệt tiết kiệm băng thông thông qua truy vấn nội dung nghe nhìn prefers-reduced-data
và sử dụng lựa chọn đó để luôn chọn người dùng xem hình ảnh có mật độ điểm ảnh thấp
bất kể mật độ hiển thị là như thế nào—nhưng trừ phi được mọi nhà phát triển triển khai một cách nhất quán trên mọi trang web, thì sẽ không mang lại nhiều lợi ích cho người dùng.
Họ có thể được tôn trọng lựa chọn ưu tiên của mình trên một trang web và có thể lại bị "bóp méo" hình ảnh ở trang tiếp theo.
Thuật toán lựa chọn tài nguyên mơ hồ có chủ ý mà srcset
/sizes
sử dụng giúp trình duyệt quyết định chọn mật độ thấp hơn
hình ảnh bị sụt giảm băng thông hoặc dựa trên lựa chọn ưu tiên để giảm thiểu mức sử dụng dữ liệu mà chúng tôi không phải chịu trách nhiệm về cách thức, thời điểm hoặc thời điểm
ngưỡng nào. Không có nghĩa là bạn phải thực hiện trách nhiệm và thực hiện các công việc khác mà trình duyệt được trang bị tốt hơn để xử lý cho bạn.
Mô tả chiều rộng bằng w
srcset
chấp nhận loại mã mô tả thứ hai cho các đề xuất nguồn hình ảnh. Đây là một công cụ mạnh mẽ hơn nhiều – và để đáp ứng mục đích của chúng tôi, một
dễ hiểu hơn rất nhiều. Thay vì gắn cờ ứng viên là có kích thước thích hợp cho mật độ hiển thị nhất định,
cú pháp w
mô tả chiều rộng vốn có của mỗi nguồn đề xuất. Xin nhắc lại, mỗi đề xuất đều giống hệt nhau cho các phương diện – cùng một
cùng nội dung, cùng mức cắt và tỷ lệ khung hình. Nhưng trong trường hợp này, bạn muốn trình duyệt của người dùng chọn giữa hai đề xuất:
nhỏ.jpg, một nguồn có chiều rộng vốn có là 600px và large.jpg, một nguồn có chiều rộng vốn có là 1200px.
srcset="small.jpg 600w, large.jpg 1200w"
Thao tác này không cho trình duyệt biết phải làm gì với thông tin này mà chỉ cung cấp cho trình duyệt danh sách các đề xuất để hiển thị hình ảnh.
Trước khi trình duyệt có thể quyết định nguồn nào sẽ hiển thị, bạn cần cung cấp cho trình duyệt đó một ít thông tin hơn:
mô tả cách hình ảnh sẽ hiển thị trên trang. Để làm việc đó, hãy sử dụng thuộc tính sizes
.
Mô tả mức sử dụng bằng sizes
Các trình duyệt chuyển hình ảnh hoạt động cực kỳ hiệu quả. Yêu cầu đối với thành phần hình ảnh sẽ bắt đầu diễn ra trong thời gian dài trước khi yêu cầu biểu định kiểu hoặc JavaScript – thường là ngay cả trước khi mã đánh dấu được phân tích cú pháp hoàn toàn. Khi trình duyệt đưa ra những yêu cầu này, trang không có thông tin nào về chính trang, ngoài mã đánh dấu — thậm chí trang có thể không đưa ra yêu cầu cho biểu định kiểu bên ngoài, chứ chưa nói đến áp dụng chúng. Tại thời điểm trình duyệt phân tích cú pháp đánh dấu của bạn và bắt đầu đặt theo yêu cầu, chỉ có thông tin ở cấp trình duyệt: kích thước khung nhìn của người dùng, mật độ pixel trên màn hình của người dùng, lựa chọn ưu tiên của người dùng, v.v.
Điều này không cho chúng tôi biết bất kỳ điều gì về cách hình ảnh sẽ được hiển thị trong bố cục trang, thậm chí hình ảnh không thể sử dụng khung nhìn
làm proxy cho giới hạn trên của kích thước img
, vì kích thước này có thể chiếm một vùng chứa cuộn theo chiều ngang. Vì vậy, chúng ta cần
cung cấp cho trình duyệt thông tin này và làm việc đó bằng mã đánh dấu. Đó là tất cả những gì chúng tôi có thể sử dụng cho những yêu cầu này.
Giống như srcset
, sizes
được thiết kế để cung cấp thông tin về hình ảnh ngay khi mã đánh dấu được phân tích cú pháp. Giống như srcset
là viết tắt của "đây là các tệp nguồn và kích thước vốn có của chúng", thuộc tính sizes
là viết tắt của "ở đây"
là kích thước của hình ảnh được kết xuất trong bố cục". Cách bạn mô tả hình ảnh tương ứng với khung nhìn, cũng là khung nhìn
kích thước là thông tin bố cục duy nhất mà trình duyệt có khi yêu cầu hình ảnh.
Việc này nghe có vẻ hơi phức tạp trên báo in nhưng thực tế sẽ dễ hiểu hơn nhiều:
<img
sizes="80vw"
srcset="small.jpg 600w, medium.jpg 1200w, large.jpg 2000w"
src="fallback.jpg"
alt="...">
Ở đây, giá trị sizes
này thông báo cho trình duyệt rằng không gian trong bố cục mà img
chiếm dụng có chiều rộng là 80vw
— 80% của
khung nhìn. Hãy nhớ rằng đây không phải là hướng dẫn mà là mô tả về kích thước của hình ảnh trong bố cục trang. Không có nội dung "thực hiện việc này"
chiếm 80% khung nhìn," nhưng "hình ảnh này sẽ chiếm 80% khung nhìn khi trang hiển thị".
Là nhà phát triển, công việc của bạn được hoàn thành. Bạn đã mô tả chính xác danh sách các nguồn ứng cử viên trong srcset
và chiều rộng của hình ảnh mình
trong sizes
, và cũng giống như với cú pháp x
trong srcset
, phần còn lại sẽ do trình duyệt thực hiện.
Nhưng nếu muốn hiểu rõ cách thông tin này được sử dụng, hãy dành một chút thời gian để xem qua các quyết định mà trình duyệt của người dùng sẽ tạo khi gặp mã đánh dấu này:
Bạn đã thông báo cho trình duyệt rằng hình ảnh này sẽ chiếm 80% khung nhìn hiện có, vì vậy, nếu chúng ta kết xuất img
này trên
thiết bị có khung nhìn rộng 1000 pixel, hình ảnh này sẽ chiếm 800 pixel. Sau đó, trình duyệt sẽ lấy giá trị đó và chia cho
chiều rộng của từng nguồn hình ảnh đề xuất mà chúng ta đã chỉ định trong srcset
. Nguồn nhỏ nhất có kích thước vốn là 600 pixel,
vậy: 600÷800=.75. Hình ảnh trung bình rộng 1200 pixel: 1200 ÷ 800=1,5. Ảnh lớn nhất có chiều rộng là 2000 pixel: 2000 ÷ 800=2,5.
Kết quả của các tính toán đó (.75
, 1.5
và 2.5
) là các tuỳ chọn DPR được điều chỉnh riêng cho phù hợp với
kích thước khung nhìn. Do trình duyệt cũng có sẵn thông tin về mật độ hiển thị của người dùng, trình duyệt đưa ra một loạt các quyết định:
Ở kích thước khung nhìn này, đề xuất small.jpg
sẽ bị loại bỏ bất kể mật độ hiển thị của người dùng là bao nhiêu, với DPR được tính toán thấp hơn
so với 1
, thì nguồn này sẽ yêu cầu nâng cấp hình ảnh cho mọi người dùng, nên cách này không phù hợp. Trên thiết bị có DPR là 1
, medium.jpg
sẽ cung cấp
kết quả phù hợp nhất — nguồn đó phù hợp để hiển thị ở DPR là 1.5
, vì vậy, nguồn này lớn hơn một chút so với mức cần thiết, nhưng hãy nhớ rằng việc giảm quy mô sẽ
một quy trình liền mạch về mặt hình ảnh. Trên thiết bị có DPR là 2,large.jpg
là kết quả phù hợp nhất, nên sẽ được chọn.
Nếu hình ảnh tương tự được hiển thị trên khung nhìn rộng 600 pixel, kết quả của tất cả toán học đó sẽ hoàn toàn khác: 80vw bây giờ là 480px.
Khi chúng tôi phân chia các nguồn' chiều rộng dựa vào đó, chúng ta sẽ có 1.25
, 2.5
và 4.1666666667
. Ở kích thước khung nhìn này, small.jpg
sẽ được chọn
trên các thiết bị 1x và medium.jpg
sẽ khớp trên các thiết bị 2x.
Hình ảnh này sẽ trông giống nhau trong tất cả các ngữ cảnh duyệt web sau: tất cả các tệp nguồn đều giống hệt nhau, chỉ khác kích thước,
và mỗi hình ảnh sẽ được hiển thị rõ nét ở mức mật độ hiển thị của người dùng cho phép. Tuy nhiên, thay vì phân phối large.jpg
cho mọi người dùng
để phù hợp với khung nhìn lớn nhất và màn hình có mật độ điểm ảnh cao nhất, người dùng sẽ luôn được cung cấp ứng viên phù hợp nhỏ nhất.
Khi sử dụng cú pháp mô tả thay vì cú pháp có quy định, bạn sẽ không cần đặt điểm ngắt theo cách thủ công cũng như không cần xem xét các khung nhìn và
DPR—bạn chỉ cần cung cấp thông tin cho trình duyệt và cho phép trình duyệt xác định câu trả lời cho bạn.
Vì giá trị sizes
tương ứng với khung nhìn và hoàn toàn độc lập với bố cục trang, nên giá trị này sẽ thêm một lớp chức năng.
Hiếm có một hình ảnh chỉ chiếm một tỷ lệ phần trăm khung nhìn mà không có lề có chiều rộng cố định, khoảng đệm hay ảnh hưởng nào
từ các thành phần khác trên trang. Bạn thường cần biểu thị chiều rộng của hình ảnh bằng cách sử dụng kết hợp các đơn vị; tỷ lệ phần trăm, em
, px
, v.v.
May mắn là bạn có thể sử dụng calc()
tại đây—bất kỳ trình duyệt nào có hỗ trợ gốc dành cho hình ảnh thích ứng cũng sẽ hỗ trợ calc()
, cho phép chúng tôi
đơn vị CSS kết hợp và khớp (ví dụ: một hình ảnh chiếm toàn bộ chiều rộng khung nhìn của người dùng, trừ đi lề 1em
ở hai bên):
<img
sizes="calc(100vw-2em)"
srcset="small.jpg 400w, medium.jpg 800w, large.jpg 1600w, x-large.jpg 2400w"
src="fallback.jpg"
alt="...">
Mô tả điểm ngắt
Nếu đã dành nhiều thời gian làm việc với bố cục thích ứng, có thể bạn sẽ nhận thấy một số nội dung bị thiếu trong các ví dụ sau:
thì không gian mà hình ảnh chiếm trong bố cục rất có khả năng thay đổi trên các điểm ngắt của bố cục. Trong trường hợp đó, bạn cần
để truyền thêm chi tiết cùng với trình duyệt: sizes
chấp nhận một tập hợp các đề xuất được phân tách bằng dấu phẩy cho kích thước được hiển thị của
hình ảnh, cũng giống như srcset
chấp nhận các đề xuất được phân tách bằng dấu phẩy cho nguồn hình ảnh. Những điều kiện đó sử dụng cú pháp truy vấn nội dung đa phương tiện quen thuộc.
Cú pháp này sẽ khớp đầu tiên: ngay khi điều kiện của nội dung nghe nhìn trùng khớp, trình duyệt sẽ ngừng phân tích cú pháp thuộc tính sizes
và giá trị
đã chỉ định sẽ được áp dụng.
Giả sử bạn có một hình ảnh chiếm 80% khung nhìn, trừ đi một em
khoảng đệm ở hai bên, trên khung nhìn có kích thước trên 1200px
nhỏ hơn, nhưng nó chiếm toàn bộ chiều rộng của khung nhìn.
<img
sizes="(min-width: 1200px) calc(80vw - 2em), 100vw"
srcset="small.jpg 600w, medium.jpg 1200w, large.jpg 2000w"
src="fallback.jpg"
alt="...">
Nếu khung nhìn của người dùng lớn hơn 1200 px, calc(80vw - 2em)
sẽ mô tả chiều rộng của hình ảnh trong bố cục của chúng ta. Nếu
Điều kiện (min-width: 1200px)
không khớp, trình duyệt sẽ chuyển sang giá trị tiếp theo. Vì không có một khu vực cụ thể
điều kiện đa phương tiện gắn với giá trị này, 100vw
được dùng làm mặc định. Nếu bạn viết thuộc tính sizes
này bằng cách sử dụng
max-width
truy vấn phương tiện:
<img
sizes="(max-width: 1200px) 100vw, calc(80vw - 2em)"
srcset="small.jpg 600w, medium.jpg 1200w, large.jpg 2000w"
src="fallback.jpg"
alt="...">
Bằng ngôn từ đơn giản: "(max-width: 1200px)
có khớp không? Nếu không, hãy tiếp tục. Giá trị tiếp theo (calc(80vw - 2em)
) không có điều kiện đủ điều kiện,
nên đây là kết quả được chọn.
Giờ thì bạn đã cung cấp cho trình duyệt toàn bộ thông tin về phần tử img
của mình – các nguồn tiềm năng, chiều rộng vốn có,
và cách bạn dự định hiển thị hình ảnh với người dùng—trình duyệt sẽ sử dụng một bộ quy tắc không rõ ràng để xác định việc cần làm
thông tin đó. Nếu điều đó nghe có vẻ mơ hồ, thì đó là do vấn đề này do thiết kế tự nguyện. Thuật toán lựa chọn nguồn được mã hoá trong
Thông số kỹ thuật HTML rõ ràng không rõ ràng về cách chọn nguồn. Khi nguồn, phần mô tả và cách
hình ảnh sẽ được kết xuất đã được phân tích cú pháp toàn bộ, trình duyệt có thể tự do làm bất cứ điều gì nó muốn—bạn không thể biết chắc chắn
nguồn mà trình duyệt sẽ chọn.
Cú pháp có nội dung "sử dụng nguồn này trên màn hình có độ phân giải cao" có thể dự đoán được, nhưng sẽ không giải quyết được vấn đề cốt lõi bằng hình ảnh theo bố cục thích ứng: tiết kiệm băng thông cho người dùng. Mật độ pixel của màn hình chỉ liên quan giới hạn đến Internet tốc độ kết nối mạng (nếu có). Nếu bạn đang sử dụng một máy tính xách tay các dòng hàng đầu nhưng duyệt web bằng kết nối có đo lượng dữ liệu, được chia sẻ Internet với điện thoại của bạn hoặc sử dụng kết nối Wi-Fi trên máy bay bị rung, bạn có thể chọn không sử dụng các nguồn hình ảnh có độ phân giải cao, bất kể chất lượng hiển thị của bạn.
Việc đưa ra ý kiến cuối cùng cho trình duyệt giúp trình duyệt cải thiện hiệu suất nhiều hơn so với những gì chúng ta có thể quản lý bằng một quy tắc nghiêm ngặt
của bạn. Ví dụ: trong hầu hết các trình duyệt, img
sử dụng cú pháp srcset
hoặc sizes
sẽ không bao giờ bận tâm đến việc yêu cầu một nguồn có kích thước nhỏ hơn
khác với một phương diện mà người dùng đã có trong bộ nhớ đệm của trình duyệt. Điểm mấu chốt trong việc thực hiện một yêu cầu mới cho một nguồn là gì
trông giống hệt nhau, khi trình duyệt có thể liên tục giảm tỷ lệ nguồn hình ảnh đã có? Nhưng nếu người dùng điều chỉnh tỷ lệ
khung nhìn cho đến thời điểm cần hình ảnh mới để tránh nâng cấp hình ảnh, thì yêu cầu đó vẫn sẽ được thực hiện, vì vậy, mọi thứ
theo cách bạn mong đợi.
Việc thiếu kiểm soát rõ ràng đó có vẻ hơi đáng sợ khi xét về mặt giá trị, nhưng vì bạn đang sử dụng các tệp nguồn có cùng giá trị
nội dung, chúng tôi ít có khả năng
hiển thị cho người dùng trạng thái "bị hỏng" so với src
nguồn đơn lẻ, bất kể
quyết định do trình duyệt đưa ra.
Đang dùng sizes
và srcset
Có rất nhiều thông tin – cho cả bạn, người đọc và cho trình duyệt. srcset
và sizes
đều là cú pháp dày đặc,
mô tả lượng thông tin gây sốc tương đối ít ký tự. Tức là, tốt hơn hay tệ hơn, theo thiết kế: khiến cho
những cú pháp này ít phức tạp hơn và dễ phân tích cú pháp hơn nhờ con người chúng ta có thể khiến trình duyệt khó phân tích cú pháp hơn. Chiến lược phát hành đĩa đơn
một chuỗi càng phức tạp hơn thì càng có khả năng xảy ra lỗi phân tích cú pháp hoặc sự khác biệt ngoài ý muốn về hành vi
từ trình duyệt này sang trình duyệt khác. Tuy nhiên, có một ưu điểm ở đây: cú pháp mà máy học dễ đọc hơn là cú pháp được viết dễ dàng hơn
dễ dàng hơn.
srcset
là một trường hợp rõ ràng cho hoạt động tự động hoá. Hiếm khi bạn tự tạo nhiều phiên bản hình ảnh cho một
môi trường sản xuất, thay vào đó tự động hoá quy trình bằng một trình chạy tác vụ như Gulp, trình gói như Webpack, bên thứ ba
CDN như Cloudinary hoặc chức năng đã tích hợp sẵn trong CMS mà bạn chọn. Có đủ thông tin để tạo các nguồn của chúng tôi
ngay từ đầu, hệ thống sẽ có đủ thông tin để ghi chúng vào một thuộc tính srcset
khả thi.
sizes
khó tự động hoá hơn một chút. Như bạn đã biết, cách duy nhất để một hệ thống có thể tính kích thước của một hình ảnh
bố cục được hiển thị là kết xuất bố cục. Rất may là một số công cụ cho nhà phát triển đã xuất hiện để loại bỏ
quá trình viết các thuộc tính sizes
bằng tay – với hiệu quả cao mà bạn không thể tự so khớp bằng tay.
Ví dụ: respImageLint là một đoạn mã dùng để xem xét các thuộc tính sizes
của bạn
để đảm bảo tính chính xác và đưa ra đề xuất để cải thiện. Dự án Lazysizes sẽ bị xâm phạm
tốc độ tính hiệu quả bằng cách trì hoãn các yêu cầu hình ảnh cho đến khi bố cục đã được thiết lập, cho phép JavaScript
tạo sizes
giá trị cho bạn. Nếu đang sử dụng một khung kết xuất hoàn chỉnh phía máy khách như React hoặc Vue, thì có một
số lượng giải pháp để soạn thảo và/hoặc tạo các thuộc tính srcset
và sizes
. Chúng ta sẽ thảo luận thêm về những vấn đề này trong CMS và Khung.