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?

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.

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…

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

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.

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ąć.