Placeholdery dla obrazków

Cześć, pracuję nad sklepem dla klienta. Sklep opiera się na ogromnej liczbie zdjęć (duże zdjęcia produktowe, sporo zdjęć w megamenu itp). Strona zajmuje >10mb nawet po optymalizacji więc pierwszy load jest trochę powolny. Trochę zacząłem w temacie działać i przede wszystkim dla dużych zdjęć stosuję SQIP + podmianę po załadowaniu strony.

Chciałeś iść o krok dalej i dać SQIP dla wszystkich zdjęć, ale zastanawiam się jednak czy dla zdjęć below the fold / ukrytych w nierozwiniętym menu zamiast SQIP nie dać encodowanych placeholderów typu szare tło bezpośrednio w html i Js-em podmieniać na właściwy obrazek. Dzięki temu ograniczyłbym ilość requestów do serwera.

Zastanawiam się czy to ma sens i czy ewentualnie nie wpłynie na SEO. Może są jakieś inne fajne sposoby rozwiązania problemu. Lazy load już stosuję, ale np. obrazki z megamenu i tak ładują się od razu.

Trochę czytałem o kwestiach grafik, ale trudno mi się zdecydować w którą stronę iść, zwłaszcza, że nie jestem frontendowcem.

A mógłbyś napisać to po polsku? Siedzę w webmasterce ze 20 lat i rozumiem tylko połowę z tego, co napisałeś.

Zaczęłabym od optymalizacji wielkości i stopnia kompresji samych zdjęć. A w ogóle to pokaż stronę, to będzie o czym rozmawiać.

Wybacz - nie siedzę w froncie więc może nazywam rzeczy źle.

SQIP - czyli SVG-Based Image Placeholder - coś takiego jak to: https://github.com/axe312ger/sqip/tree/legacy#readme czyli zastępowanie grafiki docelowej takim 1kb podglądem i później jak już strona się załaduje to dociągnięcie właściwej grafiki za pomocą JS. Idea dla mnie jest taka aby szybko wyświetlić użytkownikowi docelową stronę, odblokować JS itp, a dopiero potem dociągnąć właściwe obrazki np. gdy użytkownik przesunie stronę w dół czyli tzw lazy loading treści.

Minus tego jest taki, że do serwera lecą 2 requesty o obrazek - najpierw ten SQIP, a potem docelowy. Dlatego myśłałem aby część SQIP'ów zastąpić encodowanym obrazkiem - czyli kodujesz obrazek do base64 i umieszczasz go w tagu jako src="data:xkskskkks" - wtedy obrazek jest pobierany 1 requstem razem z samą stroną. Normalnie tą technikę stosuje się do małych rzeczy typu ikonki, ale pomyślałem że gdybym zamiast SQIP jako placeholdery użył po prostu gify z 1 kolorem to by były malutkie więc samej strony jakoś znacznie nie dociążą. Chciałbym użyć tej techniki np. dla obrazków w megamenu bo ono jest i tak zwinięte, więc zanim użytkownik je rozwinie to obrazki się zapewne dociągną w tle.

Czy teraz opis jest klarowny?

Niestety stronki nie pokażę, bo te eksperymenty robię na localhost póki co.

W każdym razie w skrócie chcę aby strona z 10mb zeszła do powiedzmy czegoś w granicach 1mb + reszta aby dociągała się w tle już po wyrenderowaniu samej strony przez przeglądarkę.

Krok 1: ustawić właściwe rozmiary dla obrazków
Krok 2: skompresować obrazki (tinypng jest super)
Krok 3: użyć tagu picture i formatu webp
Krok 4: lazy loading obrazków (np to: https://apoorv.pro/lozad.js/)

Zacznij od tego, jak już ogarniesz to wróć i powiedz jakie są efekty i wtedy można myśleć dalej.

Dzięki za wskazówki.

Krok 1 już się dzieje.
Krok 2 jest już podpięty kontener dockerowy, który na bieżąco dba o kompresowanie/optymalizowanie obrazków, generowanie SQIP itp
Krok 3. Nie znałem tego - chyba muszę dopisać generator webp do kontenera.
Krok 4. wykorzystuję native lazy load - większość obecnych przeglądarek już to wspiera. Jest jakiś powód aby dokładać to rozwiązanie pomijając support w starszych przeglądarkach?

Ogólnie dobrze kombinujesz. Nie widząc, co tam masz, trudno napisać coś więcej.

A swoją drogą, to nie kumam, dlaczego tag: lowsrc uznano za przestarzały.

@Freja Draco: nie lowsr ale lowsrc. Wiem wiem, czepiam się ;)

Czemu to wycofali - też nie wiem, było sensowne.
Ale są obejścia - chociażby

<img src="lowres.jpg" onLoad="this.src='highres.jpg';this.onload=new Function();" width="?" height="?">

A odnośnie samego uzasadnienia wycofania tej opcji - znalazłem coś takiego (aczkolwiek nie przemawia to do mnie):

The W3C Recommendation defining HTML5 has a list of obsolete, nonconforming features, including the lowsrc attribute. Its recommendation is to make a progressive JPEG image whose first scan has the same level of spatial detail as the 50 kB image and whose later scans fill in the extra details in the full 800 kB image. This mechanism presumably requires user agents to use HTTP range requests to determine how much data to retrieve relative to the size at which the image is displayed, just as they use range requests to seek through the source of an audio or video element.

hadwao napisał(a):

Krok 4. wykorzystuję native lazy load - większość obecnych przeglądarek już to wspiera. Jest jakiś powód aby dokładać to rozwiązanie pomijając support w starszych przeglądarkach?

Wg can i use na iOS Safari i Chrome to nie działa... więc teraz musisz sobie odpowiedzieć na pytanie jaki masz target na stronie o jeślito jest np 50-60% mobile z czego większość to iPhone no to trochę lipa...

Dodatkowo jeśli użyjesz JS to możesz np ustawić lazy loading dla obrazków, które nie sa widoczne ale są w aktualnym obszarze, przykład: menu gdzie po najechaniu myszką pojawia się jakaś sekcja i w niej obrazki... możesz odpalićdla tych obrazków lazy loading wtedy kiedy ty chcesz a nie wtedy kiedy znajdują się w aktualnie widocznym obszarze.