2009-10-15 8 views
25

Nhanh hơn bao nhiêu để sử dụng base64/line để hiển thị hình ảnh thay vì chỉ đơn giản là liên kết đến tệp cứng trên máy chủ?Nhanh hơn bao nhiêu để sử dụng hình ảnh inline/base64 cho một trang web hơn là chỉ liên kết đến tệp cứng?

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

Tôi chưa thể tìm thấy bất kỳ loại chỉ số hiệu suất nào về điều này.

Tôi có một vài mối quan tâm:

  • Bạn không còn đạt được lợi ích của bộ nhớ đệm
  • Không phải là một base64 A LOT kích thước lớn hơn những gì một kích thước tập tin PNG/JPEG?

Hãy xác định "nhanh" như trong: thời gian cần thiết cho một người dùng để xem đầy đủ render trang web HTML

Trả lời

3

Bạn không còn đạt được lợi ích của bộ nhớ đệm

Cho dù vấn đề đó có thay đổi tùy theo mức độ bạn phụ thuộc vào bộ nhớ đệm hay không.

Không phải là base64 Lớn hơn nhiều so với kích thước tệp PNG/JPEG?

Thuật toán nén/định dạng tệp là giống nhau, tôi lấy nó, tức là PNG.

Sử dụng Base-64, mỗi ký tự 8 bit đại diện cho 6 bit: do đó dữ liệu nhị phân đang được giải nén theo tỷ lệ từ 8 đến 6, tức là chỉ khoảng 35%.

5

Làm thế nào nhanh hơn nhiều là nó

Xác định 'nhanh hơn'. Bạn có nghĩa là hiệu suất HTTP (xem bên dưới) hoặc hiển thị hiệu suất không?

Bạn không còn đạt được lợi ích của bộ nhớ đệm

Trên thực tế, nếu bạn đang làm điều này trong một file CSS nó vẫn sẽ được lưu trữ. Tất nhiên, bất kỳ thay đổi nào đối với CSS sẽ làm mất hiệu lực bộ nhớ cache.

Trong một số trường hợp, điều này có thể được sử dụng như một sự tăng hiệu suất rất lớn qua nhiều kết nối HTTP. Tôi nói một số tình huống bởi vì bạn có thể tận dụng các kỹ thuật như hình ảnh sprites cho hầu hết các công cụ, nhưng nó luôn luôn là tốt để có một công cụ trong kho vũ khí của bạn!

+0

Bạn cũng sẽ được hưởng lợi rất nhiều từ số lượng yêu cầu HTTP cũng giảm. –

+1

Hãy xác định "nhanh hơn" như sau: thời gian để người dùng xem trang web HTML được hiển thị đầy đủ – Tim

36

'Nhanh hơn' là một điều khó có thể trả lời bởi vì có rất nhiều cách giải thích có thể và tình huống:

mã hóa Base64 sẽ mở rộng hình ảnh bằng một phần ba, mà sẽ tăng cường sử dụng băng thông. Mặt khác, bao gồm nó trong tập tin sẽ loại bỏ một chuyến đi vòng GET đến máy chủ. Vì vậy, một đường ống với thông lượng lớn nhưng độ trễ kém (chẳng hạn như kết nối internet vệ tinh) có thể sẽ tải một trang có hình ảnh được inline nhanh hơn nếu bạn đang sử dụng các tệp hình ảnh riêng biệt. Ngay cả trên đường DSL (nông thôn, chậm) của tôi, các trang web yêu cầu nhiều chuyến đi khứ hồi mất nhiều thời gian hơn để tải hơn những chuyến đi chỉ tương đối lớn nhưng chỉ yêu cầu một vài GET.

Nếu bạn thực hiện mã hóa base64 từ các tệp nguồn với mỗi yêu cầu, bạn sẽ sử dụng nhiều CPU hơn, đập bộ đệm dữ liệu, v.v. (Tất nhiên bạn luôn có thể sử dụng memcached hoặc như vậy để giải quyết vấn đề đó).

Thực hiện điều này sẽ ngăn chặn hầu hết các hình thức lưu vào bộ nhớ cache, có thể bị tổn thương rất nhiều nếu hình ảnh được xem thường xuyên - một biểu tượng được hiển thị trên mọi trang, thường có thể được lưu trong trình duyệt (hoặc proxy) bộ nhớ cache như mực hoặc bất kỳ thứ gì) và được yêu cầu mỗi tháng một lần. Nó cũng sẽ ngăn chặn nhiều máy chủ web tối ưu hóa có để phục vụ các tệp tĩnh bằng cách sử dụng các API hạt nhân như sendfile (2).

Về cơ bản, thực hiện việc này sẽ giúp trong một số trường hợp nhất định và gây tổn thương cho người khác. Bạn cần phải xác định tình huống nào là quan trọng đối với bạn trước khi bạn có thể thực sự tìm ra nếu đây là một thủ thuật đáng giá cho bạn.

+0

Hãy xác định "nhanh hơn" như sau: thời gian người dùng xem trang web HTML được hiển thị đầy đủ – Tim

+0

Caching/perf trên máy chủ kết thúc có thể không được như vậy vấn đề. Bạn vẫn có thể lưu các trang của bạn vào các tệp một phần, vì vậy không cần phải liên tục chuyển đổi hình ảnh thành base64. Nếu trang của bạn không thay đổi thường xuyên, bạn cũng có thể yêu cầu trình duyệt tự lưu trữ tệp html. –

15

Tôi đã thực hiện so sánh giữa hai trang HTML có chứa 1800 hình ảnh một pixel.

Trang đầu tiên tuyên bố những hình ảnh inline:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAANSURBVBhXYzh8+PB/AAffA0nNPuCLAAAAAElFTkSuQmCC"> 

Trong một giây, hình ảnh tham khảo một tập tin bên ngoài:

<img src="img/one-gray-px.png"> 

tôi thấy rằng khi tải nhiều lần cùng một hình ảnh, nếu nó được khai báo nội tuyến, trình duyệt thực hiện yêu cầu cho mỗi ảnh (tôi giả sử nó giải mã nó một lần cho mỗi ảnh), trong khi trong trường hợp khác, ảnh được yêu cầu một lần cho mỗi tài liệu (xem hình ảnh so sánh bên dưới).

Tài liệu có hình ảnh nội tuyến tải trong khoảng 250ms và tài liệu có hình ảnh được liên kết sẽ hoạt động trong 30 giây.

(Tested với Chromium 34)

Kịch bản của một tài liệu HTML với nhiều trường hợp của hình ảnh trong dòng tương tự không có ý nghĩa nhiều tiên. Tuy nhiên, tôi thấy rằng plugin jquery lazyload định nghĩa trình giữ chỗ nội dòng theo mặc định cho tất cả hình ảnh "lười", có thuộc tính src sẽ được đặt thành nó. Sau đó, nếu tài liệu chứa rất nhiều hình ảnh lười, một tình huống như hình được mô tả ở trên có thể xảy ra.

Timeline comparison

+2

Bạn đã bật bộ nhớ đệm chưa? –

+0

Nếu bạn đặt hình ảnh base64 của bạn vào lớp CSS thay vì thẻ img, nó sẽ nhanh như chớp và bạn kiểm soát bộ nhớ cache và vòng đời. –