Tôi có nên nhúng hình ảnh dưới dạng dữ liệu / base64 trong CSS hoặc HTML

Để giảm số lượng yêu cầu trên máy chủ, tôi đã nhúng một số hình ảnh (PNG & SVG) dưới dạng BASE64 trực tiếp vào css. (Nó tự động trong quá trình xây dựng)

như thế này:

background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAFWHRTb2Z0d2FyZQBBZG etc...);

Đây có phải là một thực hành tốt? Có một số lý do để tránh điều này? Có một số trình duyệt chính không có hỗ trợ url dữ liệu?

Câu hỏi bổ sung: Có ý nghĩa gì khi làm điều này cho CSS & JS không?

Đây có phải là một thực hành tốt? Có một số lý do để tránh điều này?

Đó là một cách thực hành tốt thường chỉ dành cho các hình ảnh CSS rất nhỏ sẽ được sử dụng cùng nhau (như các họa tiết CSS) khi khả năng tương thích IE không thành vấn đề và việc lưu yêu cầu quan trọng hơn khả năng lưu trữ.

Nó có một số nhược điểm đáng chú ý:

• Hoàn toàn không hoạt động trong IE6 và 7.

• Hoạt động cho các tài nguyên chỉ có kích thước tối đa 32k trong IE8 . Đây là giới hạn áp dụng sau khi mã hóa base64. Nói cách khác, không dài hơn 32768 ký tự.

• Nó lưu một yêu cầu, nhưng thay vào đó là trang HTML! Và làm cho hình ảnh không thể truy cập. Chúng được tải mỗi khi trang chứa hoặc biểu định kiểu được tải.

• Mã hóa Base64 kích thước hình ảnh tăng 33%.

• Nếu được phục vụ trong một tài nguyên được nén, data:hình ảnh gần như chắc chắn sẽ là một sự căng thẳng khủng khiếp đối với tài nguyên của máy chủ! Theo truyền thống, hình ảnh rất nặng về CPU để nén, với kích thước giảm rất ít.

Các câu trả lời phổ biến ở đây dường như cho thấy điều này là không cần thiết, vì một loạt các lý do chính đáng. Tuy nhiên, tất cả những điều này dường như bỏ bê hành vi ứng dụng hiện đại và quá trình xây dựng.

Không phải là không thể (và thực sự khá dễ dàng) để thiết kế một quy trình đơn giản sẽ đi qua một hình ảnh thư mục và sẽ tạo ra một CSS duy nhất với tất cả các hình ảnh của thư mục này.

Css này sẽ được lưu trữ đầy đủ và sẽ giảm đáng kể các chuyến đi khứ hồi đến máy chủ, được đề xuất chính xác bởi @MemeDeveloper, một trong những lượt truy cập hiệu suất lớn nhất.

Chắc chắn, đó là hack. không còn nghi ngờ gì nữa giống như các sprite là một hack. Trong thế giới hoàn hảo, điều này sẽ không cần thiết, cho đến lúc đó, đó là một cách thực hành nếu điều bạn cần khắc phục là:

1. Trang có nhiều hình ảnh không dễ "đánh vần".
2. Chuyến đi khứ hồi đến máy chủ là một nút cổ chai thực tế (nghĩ di động).
3. tốc độ (đến mức mili giây) thực sự quan trọng đối với trường hợp sử dụng của bạn.
4. Bạn không quan tâm (nếu bạn muốn, nếu bạn muốn web đi tiếp) về IE5 và IE6.

quan điểm của tôi

Đó không phải là một thực hành tốt. Một số trình duyệt không hỗ trợ URI dữ liệu (ví dụ IE 6 và 7) hoặc hỗ trợ bị hạn chế (ví dụ 32KB cho IE8).

Xem thêm bài viết Wikipedia này để biết chi tiết đầy đủ về các nhược điểm của URI dữ liệu:

• Lược đồ URI dữ liệu

Nhược điểm

• URI dữ liệu không được lưu trữ riêng biệt từ các tài liệu chứa của chúng (ví dụ: tệp CSS hoặc HTML) để dữ liệu được tải xuống mỗi khi tài liệu chứa được tải xuống.
• Nội dung phải được mã hóa lại và nhúng lại mỗi khi có thay đổi.
• Internet Explorer thông qua phiên bản 7 (khoảng 15% thị trường tính đến tháng 1 năm 2011), thiếu hỗ trợ.
• Internet Explorer 8 giới hạn URI dữ liệu ở độ dài tối đa 32 KB.
• Dữ liệu được bao gồm dưới dạng một luồng đơn giản và nhiều môi trường xử lý (như trình duyệt web) có thể không hỗ trợ sử dụng các bộ chứa (như multipart/alternativehoặc message/rfc822) để cung cấp độ phức tạp cao hơn như siêu dữ liệu, nén dữ liệu hoặc đàm phán nội dung.
• Các URI dữ liệu được mã hóa Base64 có kích thước lớn hơn 1/3 so với tương đương nhị phân của chúng. (Tuy nhiên, chi phí này giảm xuống còn 2-3% nếu máy chủ HTTP nén phản hồi bằng gzip)
• URI dữ liệu làm cho phần mềm bảo mật khó lọc nội dung hơn.

Tôi đã sử dụng dữ liệu của bạn trong khoảng một tháng và tôi đã ngừng sử dụng chúng vì chúng làm cho các kiểu dáng của tôi hoàn toàn to lớn.

Data-uri's hoạt động trong IE6 / 7 (bạn chỉ cần cung cấp tệp mhtml cho các trình duyệt đó).

Lợi ích tôi nhận được từ việc sử dụng dữ liệu của bạn là hình ảnh nền của tôi được hiển thị ngay khi biểu định kiểu được tải xuống, trái ngược với tải dần dần mà chúng ta thấy khác

Thật tuyệt khi chúng tôi có sẵn kỹ thuật này, nhưng tôi sẽ không sử dụng nó quá nhiều trong tương lai. Tôi khuyên bạn nên thử nó mặc dù, chỉ để bạn biết cho chính mình

Tôi muốn sử dụng CSS Sprites hơn để kết hợp các hình ảnh và lưu theo yêu cầu. Tôi chưa bao giờ thử kỹ thuật base64 nhưng dường như nó không hoạt động trong IE6 và IE7. Cũng có nghĩa là nếu bất kỳ hình ảnh nào thay đổi thì bạn phải phân phối lại toàn bộ bị mất, trừ khi bạn có nhiều tệp CSS, tất nhiên.

Tôi không có ý tưởng nào về các thực tiễn tốt nhất nói chung nhưng tôi không muốn thấy điều đó nếu tôi có thể giúp đỡ. :)

Các trình duyệt web và máy chủ có toàn bộ tải các bộ nhớ đệm được tích hợp sẵn, vì vậy tôi có thể nghĩ rằng cách tốt nhất của bạn là chỉ cần máy chủ của bạn nói với khách hàng để lưu các tệp hình ảnh. Trừ khi bạn đang có vô số hình ảnh thực sự nhỏ trên một trang thì tôi sẽ không nghĩ rằng chi phí chung của nhiều yêu cầu là vấn đề lớn. Các trình duyệt thường sử dụng cùng một kết nối để yêu cầu nhiều tệp, do đó không có kết nối mạng mới nào được thiết lập nên trừ khi lưu lượng truy cập qua các tiêu đề HTTP là đáng kể so với kích thước của tệp hình ảnh, tôi sẽ không lo lắng về nhiều yêu cầu quá nhiều .

Có những lý do tại sao bạn nghĩ rằng có quá nhiều yêu cầu đến máy chủ tại thời điểm này?

Tôi sẽ đề xuất nó cho các hình ảnh nhỏ được sử dụng rất thường xuyên, ví dụ như các biểu tượng phổ biến của một ứng dụng web.

• Nhỏ, vì mã hóa Base64 tăng kích thước
• Thường được sử dụng, bởi vì điều này biện minh cho thời gian tải ban đầu dài hơn

Tất nhiên các vấn đề hỗ trợ với các trình duyệt cũ hơn phải được ghi nhớ. Ngoài ra, có thể là một ý tưởng tốt để sử dụng khả năng của khung để tự động nội tuyến các hình ảnh một url dữ liệu như ClientBundle của GWT hoặc ít nhất là sử dụng các lớp CSS thay vì trực tiếp thêm vào kiểu của phần tử.

Thông tin chi tiết được thu thập tại đây: http://davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/