Pusty obraz. Czego używać: obraz JPEG Base64 vs 1x1

12

Tworzę stronę internetową i chcę, aby zapytania HTTP były jak najmniejsze, aby uzyskać lepszą szybkość i seo strony. Właśnie utworzona przeze mnie strona pokazuje obrazy na przewijaniu (obrazy mają atrybut data-scr, który jest konwertowany na src, gdy użytkownik przewija w dół odpowiedni obraz).

Ponieważ wszystkie obrazy mają data-srcatrybut zamiast src, W3C pokazuje mi błędy.

W tej chwili znalazłem dwie opcje rozwiązania tego problemu:

  1. Początkowy kod src wszystkich obrazów ma być adresem URL pustego obrazu 1x1
  2. Początkowy plik src wszystkich obrazów ma być 64 pustym obrazem bazy danych

Kiedy używam adresu URL pustego obrazu 1x1, wtedy (testowane przez tools.pingdom.com) pokazuje 1 żądanie HTTP. Gdy używam pustego obrazu bazy danych 64, pokazuje on tyle żądań, ile zdjęć na stronie.

Który z nich jest bardziej wydajnym sposobem na zwiększenie prędkości witryny i zmniejszenie liczby żądań HTTP? (załóżmy, że użytkownik ładuje stronę internetową z prędkością 14,4 kb / s - pierwsza prędkość Internetu).

Ale dla SEO?

Czy jest jakaś inna opcja?

MM PP
źródło
8
„Gdy używam pustego obrazu bazy danych 64, pokazuje tyle żądań, ile zdjęć na stronie”. - coś tam jest nie tak? Cały sens używania identyfikatora URI danych polega na tym, że nie ma zewnętrznego żądania HTTP. (Tylko aplikacje
klienckie
Jeśli pusty obraz będzie większy niż 1x1 px (tak mi się wydaje), polecam większy obraz w tle (10x10 px, 100x100 px), ponieważ renderowanie będzie szybsze .
totymedli 15.04.16
3
Używać żadnego? Możesz utworzyć znacznik img dynamicznie, jednocześnie konwertując dane src na src. Zamiast mieć pusty obraz z danymi-src, możesz przechowywać listę obrazów i generować znacznik w razie potrzeby.
the_lotus
@Pharap, który nie działa, ponieważ przeglądarka pobierze obrazy, nawet jeśli są ukryte.
DisgruntledGoat 15.04.16
Niezależnie od tego, co wybierzesz do dostarczania treści, kodowanie jej jako png8 będzie prawdopodobnie szybsze niż JPEG.
symcbean

Odpowiedzi:

12

Opcji obrazu base64 należy używać tam, gdzie masz tylko bardzo małą liczbę obrazów i chcesz wyeliminować narzut sieci związany z pobieraniem obrazu z serwera. Jednak z tego, co wskazujesz w pytaniu, zakładam, że może to być skalowane do dużej liczby obrazów. W takim przypadku użyłbym pojedynczego przezroczystego obrazu 1px x 1px z serwera o długim okresie trwałości pamięci podręcznej, ponieważ zostanie on pobrany z serwera, a następnie buforowany w przeglądarce i dowolnych pośrednich serwerach proxy.

Jako przykład ten obraz miałby około 95 bajtów ( https://commons.wikimedia.org/wiki/File:1x1.png ), w przypadku ciągu obrazu zakodowanego w standardzie base64 rozmiar byłby równy temu obrazowi rozmiar pliku, ale będzie powtarzany dla każdego obrazu, do którego go dodasz.

W przypadku 2-5 zdjęć rozmiar i szybkość byłyby znikome i zmniejszyłyby ruch serwera poprzez wyeliminowanie jednego całego pobierania, ale w tym przypadku rozmiar strony zacząłby być zbyt duży, co wpłynęłoby na czas ładowania i z kolei ranking SEO.

Chris Rutherfurd
źródło
6
Puste base64 obraz może mieć 55 bajtów: data:image/gif;base64,R0lGODlhAQABAAAAACwAAAAAAQABAAA=. Jeśli adres URL obrazu jest nieco dłuższy (np. Przykład.com / templates / template-name / files / 1x1.png ), obraz base64 będzie zalecany, ponieważ nie tworzysz zapytań HTTP i jest on mniejszy w bajtach niż adres URL obrazu (powtarzany dla każdego obrazu na stronie) + rozmiar obrazu zewnętrznego.
NETCreator Hosting
@ NETCreatorHosting-WebDesign Dziękujemy za komentarz. Porównałem rozmiar witryny przy użyciu obrazu base64 i obrazu zewnętrznego, a rozmiar jest mniejszy przy użyciu obrazu base64. Używam około 40 obrazów na stronie.
MM PP
Lub możesz przesłać obraz do katalogu głównego witryny i użyć względnego adresu URL, dzięki czemu strona będzie znacznie mniejsza.
NETCreator Hosting
3
gzip zajmie się powtórzeniami, więc posiadanie 400 obrazów zakodowanych w formacie base-64 na stronie nie będzie kosztować więcej przepustowości niż 400 adresów URL obrazów.
user2428118
3
@Aron Jeśli Twoja strona ma 25,6 MB (400 82-bajtowych identyfikatorów URI danych z 64kB między nimi = 25 568 800 bajtów), masz większe problemy do zmartwienia o ponad 32,8 kB obrazów zakodowanych w base64.
user2428118
5

Zdecydowanie skorzystaj z identyfikatora URI danych, chyba że potrzebujesz obsługi IE <8. (Obsługa przeglądarki ).

Osadzanie wielu małych obrazów bezpośrednio w kodzie HTML może wyglądać na zajęcie większej przepustowości niż bezpośrednie łączenie się z nimi, ale wzrost zostanie złagodzony przez gzip ; jedyna różnica w rozmiarze strony wynika z różnicy długości między jednym identyfikatorem URI danych pustego obrazu a jednym adresem URL obrazu na serwerze. Puste GIF może być tak małe jak 43 bajtów. Podstawowy kodowany 64, to 82 bajty. Nie ma sposobu, aby kiedykolwiek działał gorzej niż żądanie HTTP> 500 bajtów , odpowiedź o podobnej wielkości, a wtedy nawet nie biorę pod uwagę rozmiaru pakietu TCP i innych kosztów ogólnych.

Oto 43-bajtowy obraz GIF w kodowaniu Base 64:

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

Jeśli chodzi o SEO, spójrz na kod źródłowy witryny Google, na przykład Google News , i wyszukaj data:image/gif,base64

użytkownik2428118
źródło
Twój obraz jest duży. Sprawdź komentarz powyżej dla wersji 55-bajtowej.
Joshua
1
Ta odpowiedź na StackOverflow z raportowanymi testami (maj 2014) wydaje się wskazywać, że osadzanie dużych liczb (~ 1800) obrazów 1px jest znacznie wolniejsze niż wielokrotne łączenie z tym samym obrazem zewnętrznym. Obraz zewnętrzny jest wymagany raz i zapisywany w pamięci podręcznej, podczas gdy przeglądarka musi dekodować każdy identyfikator URI danych osobno w ramach procesu analizy HTML - wydaje się, że jest to wąskie gardło. Wydaje się to sugerować, że identyfikatory URI danych powinny być ograniczone do niewielkiej liczby (małych) obrazów.
DocRoot 16.04.16
@Joshua Chociaż ten obraz wyświetla się poprawnie w mojej przeglądarce (Firefox), nie można go otworzyć za pomocą innych programów (np. Paint), więc bym go nie używał.
user2428118 16.04.16
2

W tej chwili znalazłem dwie opcje, aby rozwiązać ten problem: Początkowy plik src wszystkich obrazów jest pusty w bazie danych 64

Ta opcja wymaga nie tylko nowoczesnej przeglądarki, ale może być wolniejsza po stronie klienta, ponieważ przeglądarka musi bazować na dekodowaniu danych obrazu w celu wygenerowania obrazu.

Początkowy kod src wszystkich obrazów ma być adresem URL pustego obrazu 1x1

Jest to ruch OK, pod warunkiem, że pusty adres URL obrazu dla wszystkich miejsc obrazu jest dokładnie tym samym adresem URL i ma długi okres trwałości pamięci podręcznej zdefiniowany w nagłówku HTTP „kontrola pamięci podręcznej”. Problem polega na tym, że gdy ładowane są nowe pliki obrazów, kwadraty obrazu będą przeskakiwać do nowego rozmiaru, co może sprawić, że użytkownik nie będzie tak wspaniały.

Prawie idealnym pomysłem jest to ...

Gdy strona się uruchomi, zaprezentuj siatkę z polami o stałym rozmiarze, które mogą pomieścić każdy obraz. Jest ok, jeśli cała siatka nie mieści się na ekranie. Następnie utwórz javascript, który będzie wykonywany po załadowaniu HTML, i w tym javascript utwórz nowy element obrazu i dołącz go do każdej komórki siatki, a następnie ustaw źródło obrazu na poprawny plik obrazu. Rób to, dopóki pierwszy ekran się nie zapełni. następnie wykryj przewijanie w javascript, a następnie, gdy nastąpi przewijanie, powtórz powyższy proces dla nowych komórek.

Teraz, jeśli chcesz tego, co najlepsze z najlepszych, a jakość nie stanowi wielkiego problemu, to zalecam (zaimplementowałem również na mojej stronie) to zbudowanie siatki i ustawienie jej w taki sposób, aby obraz tła tej siatki był arkusz sprite wszystkich obrazów sformatowanych jako kwadraty obrazów. Ta metoda jest elastyczna i szybka do załadowania, ponieważ do wszystkich obrazów wymagane jest jedno żądanie.

Oto szablon HTML do użycia, jeśli chcesz wybrać szybką trasę. Składane są tylko dwa żądania. Kod HTML i jeden obraz. W tym kodzie zakładam, że każdy obraz z arkusza ma 100 pikseli szerokości i 200 pikseli wysokości i że każdy obraz jest idealnie wyrównany obok siebie, bez przerw.

<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>

W moim kodzie dodałem 3 kropki. Oznacza to, że możesz nadal dodawać obrazy, zwiększając liczby i zwiększając pozycję o 100 za każdym razem, pod warunkiem, że arkusz sprite ma tylko jeden rząd obrazów. Ponadto w przypadku niektórych przeglądarek, takich jak Opera, może być konieczne dodanie znaku ujemnego przed wartościami pozycji tła, aby je uruchomić.

Mikrofon
źródło
2
O ile twoje obrazy nie są wielkości pół gigabajta, nie ma mowy, aby dekodowanie obrazu base64 miało jakikolwiek wymierny wpływ na wydajność.
user2428118
To zależy również od systemu komputerowego. Jeśli klient nadal ma staroświecki komputer, taki jak pentium 1, może to oznaczać pogorszenie wydajności.
Mike
1

Obraz, ponieważ łatwość konserwacji.

Z mojego doświadczenia wynika, że ​​lepiej jest używać obrazu. Jest to bardziej oczywiste w rzeczywistym kodzie i łatwiejsze do zapamiętania. Wątpię, czy pamiętasz zakodowany ciąg przezroczystego obrazu, a nawet jeśli tak, twoi następcy / uczelnie.
Jeśli wrócisz do tego kodu po kilku tygodniach, zapomniałeś base64.

Utrzymanie kodu będzie znacznie prostsze, jeśli użyjesz obrazu, minimalne pro nie obciążają tego.

Martijn
źródło
Wiele osób używa skryptów do generowania wartości base-64, więc wymóg zapamiętywania takich wartości jest poza oknem, chyba że OP użyje tylko zestawu plików HTML do przedstawienia kodu swojej witryny.
Mike
1

A może tylko ~ 3 dodatkowe bajty, 0 dodatkowych żądań http i 0 dodatkowych długości img src (lub 0 niebuforowanych symboli zastępczych obrazu danych). Czy możesz użyć pustego pliku src dla obrazu?

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

A jeśli mają alttagi, możesz ukryć je przed błędem / błędem obrazu:

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

Wyświetla: nic. Odcięcie znacznika alt ma niewielkie opóźnienie FOUC od granicy symbolu zastępczego obrazu. Być może to też można usunąć.

dhaupin
źródło
2
Chociaż pusty srcatrybut nadal będzie generował błędy w walidatorze W3C (co wydaje się być problemem).
MrWhite
@ w3dk Tak, to do bani, ale z drugiej strony przechodzi bardzo niewiele modernizacji.
dhaupin
Jeśli chcesz przekazać reguły W3C, musisz podać coś dla src, nawet jeśli jest to adres URL, który zwraca błąd 404. Polecam również określenie wartości atrybutów szerokości i wysokości obrazu, aby użytkownicy widzieli na początku rzeczywiste symbole zastępcze zamiast małych pudełek, które wypełniają się w połowie procesu ładowania.
Mike