Hình ảnh trống. Sử dụng gì: Hình ảnh JPEG Base64 so với 1x1


11

Tôi đang xây dựng một trang web và tôi muốn thực hiện các truy vấn HTTP càng ít càng tốt để có tốc độ và seo trang web tốt hơn. Trang tôi vừa tạo đang hiển thị hình ảnh trên cuộn (hình ảnh có dữ liệu thuộc tính được chuyển thành src khi người dùng cuộn xuống ở hình ảnh tương ứng).

Bởi vì tất cả các hình ảnh có data-srcthuộc tính thay vì src, W3C hiển thị cho tôi các lỗi.

Tại thời điểm này, tôi tìm thấy hai lựa chọn, để giải quyết vấn đề này:

  1. Src ban đầu của tất cả các hình ảnh là một url của hình ảnh 1x1 trống
  2. Src ban đầu của tất cả các hình ảnh là một cơ sở dữ liệu 64 hình ảnh trống

Khi tôi đang sử dụng URL của hình ảnh 1x1 trống, sau đó (được thử nghiệm với tools.pingdom.com), nó sẽ hiển thị 1 yêu cầu HTTP. Khi tôi đang sử dụng một hình ảnh trống cơ sở dữ liệu64 thì nó sẽ hiển thị nhiều yêu cầu bằng số lượng hình ảnh trên trang.

Cách nào trong số chúng là cách hiệu quả hơn, cho một trang web có tốc độ nhanh hơn và thực hiện ít yêu cầu HTTP hơn? (giả sử rằng người dùng đang tải trang web ở tốc độ internet 14,4kbps - tốc độ internet đầu tiên).

Nhưng đối với SEO?

Có lựa chọn nào khác?


8
"Khi tôi đang sử dụng một cơ sở dữ liệu 64 hình ảnh trống thì nó sẽ hiển thị nhiều yêu cầu bằng số lượng hình ảnh trên trang." - có gì đó hơi sai ở đó? Điểm chung của việc sử dụng URI dữ liệu là không có yêu cầu HTTP bên ngoài. (Chỉ những tác nhân người dùng không hiểu URI dữ liệu mới có thể thực hiện yêu cầu HTTP.)
MrWhite

Nếu hình ảnh trống sẽ lớn hơn 1x1 px (tôi đoán là vậy), tôi sẽ khuyên bạn nên hình ảnh nền lớn hơn (10x10 px, 100x100 px) vì kết xuất sẽ nhanh hơn .
totymedli

3
Sử dụng không? Bạn có thể tạo thẻ img một cách linh hoạt đồng thời bạn chuyển đổi data-src thành src. Thay vì có hình ảnh trống với src dữ liệu, bạn có thể lưu trữ danh sách hình ảnh và tạo thẻ khi cần.
the_lotus

@Pharap không hoạt động vì trình duyệt sẽ tải xuống hình ảnh ngay cả khi chúng bị ẩn.
DisgruntledGoat

Bất cứ điều gì bạn chọn để phân phối nội dung, mã hóa nó dưới dạng png8 có thể sẽ nhanh hơn JPEG.
symcbean

Câu trả lời:


12

Tùy chọn hình ảnh base64 nên được sử dụng trong đó bạn chỉ có một số lượng hình ảnh rất nhỏ và bạn muốn loại bỏ chi phí mạng khi tìm nạp hình ảnh từ máy chủ. Tuy nhiên từ những gì bạn đang chỉ ra trong câu hỏi tôi cho rằng điều này có thể mở rộng đến một số lượng lớn hình ảnh. Trong trường hợp này, tôi sẽ sử dụng một hình ảnh trong suốt 1px x 1px từ máy chủ với thời gian lưu trữ bộ đệm dài vì nó sẽ được tìm nạp từ máy chủ một lần sau đó được lưu trong trình duyệt và bất kỳ máy chủ proxy trung gian nào.

Ví dụ, hình ảnh này có kích thước khoảng 95 byte ( https: //commons.wik mega.org/wiki/File:1x1.png), đối với chuỗi hình ảnh được mã hóa base64, bạn sẽ thấy kích thước sẽ ngang bằng với hình ảnh này kích thước tệp nhưng sẽ được lặp lại cho mỗi hình ảnh duy nhất bạn thêm nó vào.

Đối với 2-5 hình ảnh, kích thước và tốc độ sẽ không đáng kể và sẽ làm giảm lưu lượng máy chủ bằng cách loại bỏ toàn bộ một lần tìm nạp, nhưng với kích thước trang đó sẽ bắt đầu quá lớn sẽ ảnh hưởng đến thời gian tải và lần lượt xếp hạng SEO.


6
Một hình ảnh base64 trống có thể có 55 byte : data:image/gif;base64,R0lGODlhAQABAAAAACwAAAAAAQABAAA=. Nếu URL của hình ảnh dài hơn một chút (ví dụ: example.com/temsheet/template-name/files/1x1.png ), hình ảnh cơ sở 64 sẽ được đề xuất vì bạn không tạo truy vấn HTTP và nó nhỏ hơn theo byte hơn URL hình ảnh (lặp lại cho mỗi hình ảnh trên trang) + kích thước hình ảnh bên ngoài.
NETCreator Hosting

@ NETCreatorhosting-WebDesign Cảm ơn bạn đã bình luận. Tôi đã so sánh kích thước trang web khi sử dụng hình ảnh base64 và hình ảnh bên ngoài và kích thước nhỏ hơn khi sử dụng hình ảnh base64. Tôi đang sử dụng khoảng 40 hình ảnh trên mỗi trang.
MM PP

Hoặc bạn có thể tải lên hình ảnh trên trang web gốc của bạn và sử dụng một url tương đối, vì vậy trang web sẽ nhỏ hơn nhiều.
NETCreator Hosting

3
gzip sẽ đảm nhiệm việc lặp lại, do đó, việc có 400 hình ảnh được mã hóa cơ sở 64 trong trang của bạn sẽ không tốn nhiều băng thông hơn 400 URL hình ảnh.
user2428118

3
@Aron Nếu trang của bạn có dung lượng lớn 25,6 MB (400 URI dữ liệu dài 82 byte với 64kB giữa chúng = 25,568,800 byte), bạn đã gặp vấn đề lớn hơn khi lo lắng về hơn 32,8 kB hình ảnh được mã hóa base64.
dùng2428118

5

Chắc chắn đi với URI dữ liệu, trừ khi bạn cần hỗ trợ cho IE <8. ( Hỗ trợ trình duyệt .)

Việc nhúng nhiều hình ảnh nhỏ trực tiếp vào HTML có thể trông giống như nó sẽ chiếm nhiều băng thông hơn so với liên kết trực tiếp với chúng, nhưng sự gia tăng sẽ được giảm thiểu bằng gzip ; sự khác biệt duy nhất về kích thước của trang sẽ đến từ sự khác biệt về độ dài giữa một URI dữ liệu của một hình ảnh trống và một URL của hình ảnh trên máy chủ của bạn. Một GIF trống có thể nhỏ tới 43 byte. Mã hóa cơ sở 64, đó là 82 byte. Không có cách nào có thể thực hiện kém hơn yêu cầu HTTP> 500 byte , một phản hồi có kích thước tương tự, và sau đó tôi thậm chí không tính đến kích thước gói TCP và các chi phí khác.

Dưới đây là hình ảnh GIF 43 byte được mã hóa cơ sở 64:

data:image/gif;base64,R0lGODlhAQABAIAAAP///////yH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==

Đối với SEO, có một cái nhìn vào mã nguồn của một trang web của Google, ví dụ như Google News , và tìm kiếm data:image/gif,base64...


Hình ảnh của bạn lớn. Kiểm tra bình luận ở trên cho phiên bản 55 byte.
Joshua

1
Câu trả lời này trên StackOverflow với các thử nghiệm được báo cáo (tháng 5 năm 2014) dường như cho thấy rằng việc nhúng số lượng lớn (~ 1800) của hình ảnh 1px chậm hơn đáng kể so với liên kết nhiều lần với cùng một hình ảnh bên ngoài. Hình ảnh bên ngoài được yêu cầu một lần và được lưu trong bộ nhớ cache, trong khi trình duyệt phải giải mã từng URI dữ liệu một cách riêng biệt như một phần của quy trình phân tích cú pháp HTML - điều này dường như là nút cổ chai. Điều này dường như gợi ý rằng các URI dữ liệu nên được giới hạn ở một số lượng nhỏ (nhỏ) hình ảnh.
DocRoot

@Joshua Mặc dù hình ảnh đó hiển thị chính xác trong trình duyệt của tôi (Firefox), nhưng nó không thể được mở bởi một số chương trình khác (ví dụ: Paint) vì vậy tôi tránh sử dụng nó.
user2428118

2

Tại thời điểm này, tôi tìm thấy hai tùy chọn, để giải quyết vấn đề này: src ban đầu của tất cả các hình ảnh là một cơ sở dữ liệu 64 hình ảnh trống

Tùy chọn này không chỉ yêu cầu một trình duyệt hiện đại mà còn có thể chậm hơn ở phía máy khách vì trình duyệt phải giải mã 64 dữ liệu hình ảnh để tạo ra hình ảnh.

Src ban đầu của tất cả các hình ảnh là một url của hình ảnh 1x1 trống

Đó là một động thái OK với điều kiện là URL hình ảnh trống cho tất cả các vị trí hình ảnh chính xác là cùng một URL và nó có tuổi thọ bộ đệm dài được xác định trong tiêu đề HTTP "kiểm soát bộ đệm". Vấn đề với điều này là khi các tệp hình ảnh mới tải, các ô hình ảnh sẽ chuyển sang kích thước mới có thể khiến trải nghiệm người dùng không tuyệt vời như vậy.

Ý tưởng gần như hoàn hảo là ...

Khi trang khởi động, hãy hiển thị một lưới với các hộp có kích thước cố định có thể chứa được mỗi hình ảnh. Sẽ ổn nếu toàn bộ lưới không vừa trên màn hình. Sau đó, tạo javascript thực thi sau khi tải HTML và trong javascript đó, tạo một thành phần hình ảnh mới và gắn nó vào từng ô của lưới sau đó đặt nguồn hình ảnh vào tệp hình ảnh chính xác. Làm điều này cho đến khi màn hình đầu tiên lấp đầy. sau đó phát hiện cuộn trong javascript và sau đó khi cuộn xảy ra, lặp lại quy trình trên cho các ô mới.

Bây giờ nếu bạn muốn thứ tốt nhất và chất lượng không phải là mối quan tâm lớn, thì điều tôi khuyên bạn (mà tôi cũng đã thực hiện trên trang web của mình) là xây dựng một lưới và đặt nó sao cho hình nền của lưới đó là một tấm sprite của tất cả các hình ảnh được định dạng như hình vuông của hình ảnh. Phương pháp này linh hoạt và tải nhanh vì một yêu cầu được yêu cầu cho tất cả các hình ảnh.

Đây là một HTML mẫu để sử dụng nếu bạn muốn đi theo con đường nhanh. Chỉ có hai yêu cầu được thực hiện. Mã HTML và một hình ảnh. Trong mã này, tôi giả sử mỗi hình ảnh từ trang tính có chiều rộng 100 pixel và chiều cao 200 pixel và mỗi hình ảnh được căn chỉnh hoàn hảo cạnh nhau không có khoảng trống.

<html>
<head>
<style type="text/css">
#imagegrid {background-color: black; background-image:url('http://example.com/url/to/imagesheet.jpg');}
A {display:block;width:100px;height:200px;margin:10px;float:left;}
#image1{background-position: 0px 0px}
#image2{background-position: 100px 0px}
#image3{background-position: 200px 0px}
...
#imageN{background-position: XXXpx 0px}
</style>
</head>
<body>
<div id="imagegrid">
<a href="image_one.htm" id="image1"></a>
<a href="image_two.htm" id="image2"></a>
<a href="image_three.htm" id="image3"></a>
...
<a href="image_N.htm" id="imageN"></a>
</div>
</body>
</html>

Trong mã của tôi, tôi đã thêm 3 dấu chấm. Điều đó có nghĩa là bạn có thể tiếp tục thêm hình ảnh bằng cách tăng số lượng và bằng cách tăng vị trí thêm 100 mỗi lần với điều kiện là trang sprite của bạn chỉ có một hàng hình ảnh. Ngoài ra, với một số trình duyệt như Opera, bạn có thể cần thêm một dấu âm trước các giá trị vị trí nền để chúng hoạt động.


2
Trừ khi hình ảnh của bạn có kích thước nửa gigabyte, không có cách nào giải mã hình ảnh cơ sở 64 sẽ có bất kỳ tác động có thể đo lường nào đối với hiệu suất.
dùng2428118

Nó cũng phụ thuộc vào hệ thống máy tính quá. Nếu khách hàng vẫn có một máy tính lỗi thời như pentium 1, thì có thể có một điểm nhấn về hiệu suất.
Mike

1

Các hình ảnh, bởi vì khả năng duy trì.

Theo kinh nghiệm của tôi, nó hoạt động tốt hơn để sử dụng hình ảnh. Điều này là rõ ràng hơn trong mã thực tế và dễ nhớ hơn. Tôi nghi ngờ bạn sẽ nhớ chuỗi được mã hóa cho một hình ảnh trong suốt và ngay cả khi bạn làm như vậy, người thành công / đồng nghiệp của bạn.
Nếu bạn quay lại mã này sau một vài tuần, bạn đã quên cơ sở64.

Sẽ rất nhiều simpeler để duy trì mã nếu bạn sử dụng hình ảnh, pro tối thiểu không nặng đến mức này.


Nhiều người sử dụng các tập lệnh để tạo các giá trị cơ sở 64, do đó, yêu cầu ghi nhớ các giá trị đó nằm ngoài cửa sổ trừ khi OP chỉ sử dụng một tập hợp các tệp HTML để thể hiện mã của trang web của mình.
Mike

1

Làm thế nào về chỉ ~ 3 byte thêm, 0 yêu cầu http thêm và 0 chiều dài img src thêm (hoặc 0 chỗ giữ hình ảnh dữ liệu không được lưu trữ). Bạn có thể sử dụng một src trống cho hình ảnh?

<img src data-src="banannanannas.jpg" />

Và nếu họ có altthẻ, bạn có thể ẩn chúng khỏi hình ảnh lỗi / lỗi:

<img src data-src="banannanannas.jpg" onerror="this.alt=''" alt="some desc" />

Hiển thị: không có gì. Việc hack thẻ alt có độ trễ FOUC nhẹ từ đường viền giữ chỗ hình ảnh. Có lẽ điều đó cũng có thể được làm sạch.


2
Mặc dù một srcthuộc tính trống vẫn sẽ ném lỗi trong Trình xác thực W3C (có vẻ là mối quan tâm).
MrWhite

@ w3dk Vâng, đó là hút, nhưng sau đó rất ít hiện đại hóa vượt qua.
dhaupin

Nếu bạn muốn vượt qua các quy tắc W3C, một cái gì đó cần được chỉ định cho src, ngay cả khi URL của nó trả về lỗi 404. Tôi cũng khuyên bạn nên chỉ định các giá trị của các thuộc tính chiều rộng và chiều cao cho hình ảnh để người dùng lần đầu tiên nhìn thấy chỗ giữ chỗ thực tế thay vì các hộp nhỏ tăng nửa chừng trong quá trình tải.
Mike
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.