logo
07.01.2020 22:33
31
A kto z vas vobec riesi napr. webp :D

Co se právě děje na Webtrhu?

07.01.2020 22:41
32
Ja resim. Kde je jejich podpora tam davam WebP kde neni, tak optimalizovane jpg/png.
07.01.2020 23:13
33
Na tom mas predsa picture a srcset.. a bude to fungovat vsade ;) edit: okrem ios a macos, ovsem, mozno za 5 rokov
08.01.2020 09:34
34
Naneštěstí Safari na iOS, iPadOS a MacOS neumí WebP. A neumí ho ani KaiOS, což je tento mobilní operační systém s rostoucím podílem:
Systém KaiOS využívá již 100 miliónů zařízení | mobilenet.cz

Mně se WebP velice líbí (v režimu bezeztrátové i ztrátové komprese), ale z hlediska kompatibility je bezpečnější pořádně rekomprimovat JPG pomocí MozJPEG a PNG pomocí pngcrush:

GitHub - mozilla/mozjpeg: Improved JPEG encoder.

Squoosh

pngcrush - Wikipedia

PNG Crush
08.01.2020 09:44
35
Původně odeslal ne
Na tom mas predsa picture a srcset.. a bude to fungovat vsade ;) edit: okrem ios a macos, ovsem, mozno za 5 rokov
Jde o usporu prenesenych dat smerem k uzivateli. Samozrejme ze vim o srcset a picture, jednoduchy priklad:

<picture loading="lazy" class="lazy-images">
<source type="image/webp" data-srcset="/assets/img/img.webp 200w, /assets/img/img.webp 400w, /assets/img/img.webp 800w" />
<source type="image/png" data-srcset="/assets/img/image.png 200w, /assets/img/img.png 400w, /assets/img/img.png 800w" />
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAA fFcSJAAAADUlEQVR42mOsq6mrBwAE8QH5A52ECwAAAABJRU5Er kJggg==" alt="Placeholder" />
</picture>
Nebo na to pouziju nejakou CDNku (pokud je rozpocet a je to vyslovene treba nebo by bylo vhodne), ktera mi uz rovnou orizne pozadovany rozmer obrazku a naserviruje ho.
Naprilad neco takoveho:

<img src=”https://cdn.statically.io/img/webdev.imgix.net/native-lazy-loading/hero.png?auto=format&fit=max&w=1730?w=200&h=200&qu ality=90&format=webp" />
Nebo takoveho:

<img src=”https://res.cloudinary.com/demo/image/upload/w_300,h_100,c_scale/sample.jpg" />
08.01.2020 10:17
36
napr. moj fw automaticky vygeneruje nieco taketo:

<picture>
<source media="(min-width: 1200px)" type="image/webp" srcset="/_assets/stranka2/c2.jpg/1577543411/1140.0.75.48e1007c9721fc9736163179063c4a77.webp">
<source media="(min-width: 1200px)" srcset="/_assets/stranka2/c2.jpg/1577543411/1140.0.75.68d9ae0471543e5d74e015c8ed17f92c.jpg">
<source media="(min-width: 992px)" type="image/webp" srcset="/_assets/stranka2/c2.jpg/1577543411/992.0.75.959e831c21177069cbedb6f92fd4dca3.webp">
<source media="(min-width: 992px)" srcset="/_assets/stranka2/c2.jpg/1577543411/992.0.75.4082466a688bee67ab04209e3497b40c.jpg">
<source media="(min-width: 768px)" type="image/webp" srcset="/_assets/stranka2/c2.jpg/1577543411/768.0.75.37e541f07bea663fc46b4e6800aa8a0e.webp">
<source media="(min-width: 768px)" srcset="/_assets/stranka2/c2.jpg/1577543411/768.0.75.a8c38a1594a9f5b4062c7b6f9be81da1.jpg">
<source media="(min-width: 576px)" type="image/webp" srcset="/_assets/stranka2/c2.jpg/1577543411/576.0.75.778db1c93e95d1b5737b97bf04415f93.webp">
<source media="(min-width: 576px)" srcset="/_assets/stranka2/c2.jpg/1577543411/576.0.75.554fcc8eafe22061d48e6344a88429f7.jpg">

<img src="/_assets/stranka2/c2.jpg/1577543411/1140.0.75.68d9ae0471543e5d74e015c8ed17f92c.jpg" class="d-block w-100">
</picture>
vyzera to na prvy pohlad hrozostrasne, ale na jeden "tah":

- vyriesi rozne velkosti pre rozne velkosti obrazovky
- poskytne webp alternativu pre podporujuce zariadenia


sice som zdrojak zvacsil o cca 1kb na tento obrazok, ale:

- pri desktope s podporou webp som usetril 24kb (65kb jpg, 41kb webp)
- pri malom mobile s podporou webp (android 4.2 +) az 43kb (65kb jpg, 22kb webp)

pri cca vyse 80% podpore webp sa to urcite oplaca (a podpora postupne rastie), a to pisem len o jednom jedinom obrazku. Pri 20 obrazkoch bude zdrojak vacsi o 20kb, ale celkovy prenos sa znizi o 480kb, co uz je podstatny rozdiel.

A TO SA OPLATI! :D

edit: v request hlavicke sa da pozriet ci prehliadac akceptuje image/webp, ak nie, tak sa mu samozrejme alternativa neposle.
08.01.2020 10:30
37
No tak spravne. Ja to mam jinak resene, v jedne lajne pouziji potrebne velikosti, ale predtim jsem to taky delal jako ty a ta CNDka v tom je jeste lepsi, ta posle obrazek, ktery ted aktualne je vyzadovan uzivatelem.

Opravdu se usetri strasna kvanta prenesenych dat.
08.01.2020 10:33
38
Původně odeslal petrx
Mně se WebP velice líbí (v režimu bezeztrátové i ztrátové komprese), ale z hlediska kompatibility je bezpečnější pořádně rekomprimovat JPG pomocí MozJPEG a PNG pomocí pngcrush:
prave preto ten picture srcset a type .. pokial prehliadac podporuje webp, tak si ho sam bezpecne prevezme, ked nie, prevezme si dalsiu alternativu podla poradia.. ak prehliadac nepodporuje picture tak ho bude ignorovat a zobere si klasicke img.. tam nie je co pokazit..

---------- Příspěvek doplněn 08.01.2020 v 10:37 ----------

Původně odeslal Oleg
No tak spravne. Ja to mam jinak resene, v jedne lajne pouziji potrebne velikosti, ale predtim jsem to taky delal jako ty a ta CNDka v tom je jeste lepsi, ta posle obrazek, ktery ted aktualne je vyzadovan uzivatelem.

Opravdu se usetri strasna kvanta prenesenych dat.
jj tak CDN je ina kava, tam je to samozrejme este o kus lepsie, ale pokial clovek nechce / nema nato, tak picture je vyborna alternativa
08.01.2020 10:46
39
Tak jiste, ale proc nepouzijes neco jak to mam ja, usetris si tim dalsich nekolik KB/stranka

<source type="image/webp" data-srcset="/_assets/stranka2/c2.jpg/1577543411/1140.0.75.48e1007c9721fc9736163179063c4a77.webp 1200w, /_assets/stranka2/c2.jpg/1577543411/1140.0.75.48e1007c9721fc9736163179063c4a77.webp 992w, /_assets/stranka2/c2.jpg/1577543411/1140.0.75.48e1007c9721fc9736163179063c4a77.webp 768w, /_assets/stranka2/c2.jpg/1577543411/1140.0.75.48e1007c9721fc9736163179063c4a77.webp 576w" />
misto:

<source media="(min-width: 1200px)" type="image/webp" srcset="/_assets/stranka2/c2.jpg/1577543411/1140.0.75.48e1007c9721fc9736163179063c4a77.webp">
<source media="(min-width: 992px)" type="image/webp" srcset="/_assets/stranka2/c2.jpg/1577543411/992.0.75.959e831c21177069cbedb6f92fd4dca3.webp">
<source media="(min-width: 768px)" type="image/webp" srcset="/_assets/stranka2/c2.jpg/1577543411/768.0.75.37e541f07bea663fc46b4e6800aa8a0e.webp">
<source media="(min-width: 576px)" type="image/webp" srcset="/_assets/stranka2/c2.jpg/1577543411/576.0.75.778db1c93e95d1b5737b97bf04415f93.webp">
Rozdil v techto radkach je 188 bajtu * kolik toho mas na webu * pocet navstev a uz se to nascita docela dost (u malych webu nonsense)

A samozrejme, pokud neni CDNka, super je napsat snippet, ktery fakt da ten potrebny rozmer pro danou chvili, tim se usetri cca 400 bajtu oproti 4 radkum kodu.

P.S. fakt jde o to udelat co nejjednodussi strom DOMu
08.01.2020 11:07
40
descriptory v srcset sa daju pouzit tusim iba v tagu img.. lenze v img neexistuje media (ten je iba v source), cim nemam ako prehliadacu povedat aky format obrazok je..

ty to tam v tvojej ukazke musis mat inak vyriesene

edit: nie media, type som myslel
08.01.2020 11:23
41
picture > source media moc casto nepouzivam, neni potreba, spise tag img.

ale nefunguje neco jako toto?

<picture>
<source srcset="img-1200px.jpg 1200w, img-992px.jpg 992w, img-768px.jpg 768w, img-576px.jpg 576w">
</picture>
08.01.2020 11:35
42
vyskusam.. uprimne, robil som to davnejsie a uz si nepamatam ci som skusil aj toto

---------- Příspěvek doplněn 08.01.2020 v 12:12 ----------

takze descriptory funguju aj v picture > source > srcset .. clovek sa uci cely zivot.. dik Oleg :)
09.01.2020 14:32
43
Dovolím si ještě ocitovat:

https://medium.com/@addyosmani/the-c...8-7d8950fbb5d4

Byte-for-byte, JavaScript is still the most expensive resource we send to mobile phones, because it can delay interactivity in large ways.
If client-side JavaScript isn’t benefiting the user-experience, ask yourself if it’s really necessary. Maybe server-side-rendered HTML would actually be faster. Consider limiting the use of client-side frameworks to pages that absolutely require them. Server-rendering and client-rendering are a disaster if done poorly.
Pinterest reduced their JavaScript bundles from 2.5MB to < 200KB and Time-to-Interactive reduced from 23s to 5.6s. Revenue went up 44%, sign-ups are up 753%, weekly active users on mobile web are up 103%.

AutoTrader reduced their JavaScript bundle sizes by 56% and reduced Time-to-Interactive for their pages by ~50%.

Nikkei reduced their JavaScript bundle size by 43% and Time-to-Interactive improved by 14s.
If you spend a long time parsing and compiling script in a JavaScript engine, that delays how soon a user can interact with your experience.
Another thing to keep in mind with JavaScript is that all bytes are not equal. A 200 KB script and a 200 KB image have very different costs.
If we’re fortunate, we may have a high-end or median end phone. The reality is that not all users will have those devices.
Android phones are getting cheaper, not faster, over time. These devices are frequently CPU poor with tiny L2/L3 cache sizes. You are failing your average users if you’re expecting them to all have high-end hardware.
On an iPhone 8 (using the A11 chip) it takes nine seconds less to process CNN’s JavaScript than it does on an average phone. That’s nine seconds quicker that experience could get interactive.
*****

https://v8.dev/blog/cost-of-javascript-2019

On mobile, it takes 3–4× longer for a median phone (Moto G4) to execute Reddit’s JavaScript compared to a high-end device (Pixel 3), and over 6× as long on a low-end device (the <$100 Alcatel 1X)
09.01.2020 15:21
44
dalsim paradoxom su aj obrazky (sice sme ich uz riesili vyssie, ale iny priklad)...

ak mame na layoute sirokom 1200px+ (teda typicky desktop) 4 obrazky v jednom riadku vedla seba, pretoze sa nam tam pohodlne zmestia, tak kazdy z nich ma realne pod 300px

na slabsom mobile (oproti desktopu, notebooku) mame layout 360px a obrazok sa nam zmesti na riadok len 1, lebo 2 by boli uz mrnave

teda vo vysledku vykonny desktop stahuje 300px obrazky a slabsi mobil 360px a viac ( iphone 414px a podobne) - jasne, da sa to optimalizovat (lazyload, nizsia kvalita atd..), ale aj tak.. malokto to robi..
09.01.2020 15:40
45
@ne
Nepochopil jsme dost dobre jak to myslis, mas nejaky demo URL, abych to lepe pochopil? Vyresit se da vse. Jinak jsem rad, ze deskriptory funguji, alespon nekolik KB k dobru, at slouzi.

@petrx to nikdo v realu neseri, spise se snazi vse gzipnou a prohnat pres CDNka, samozrejme, ze zpracovani 200KB JS je narocnejsi nez vykreslit 200KB obrazek :)
Podarilo se ti vyresit rychlost webu?
09.01.2020 16:00
46
nemam po ruke demo, ale vysvetlim trebars na bootstrape..

col-xl-3 - desktop - layout 1140px - 4 obrazky = 1.obrazok 285px
col-lg-4 - tablet - layout 992px - 3 obrazky = 1.obrazok 330px
col-md-4 - tablet - layout 768px - 3 obrazky = 1. obrazok 256px
col-sm-6 - tablet - layout 576px - 2 obrazky = 1. obrazok 288px

vacsina mobilov je ale pod 576px (uvazujeme o portrait mode, drviva vacsina ludi tak surfuje), teda xs.. viac ako jeden obrazok na riadku sa uz zobrazuje zle, lebo zacina byt moc maly, teda ho zaobrazime na 100% width

co znamena, ze na 360px mobil layout potrebujeme stiahnut 360px obrazok.. na iphone uz 414px.. nestaci nam ziadny pre vacsie layouty (viewporty)

co je trochu paradox, pretoze na desktop verzii (kedze nizsia pixel density) sa mi pohodlne napr. v galerii zmestia 4 obrazky vedla seba, potrebna velkost obrazku je teda na vykonnejsom zariadeni mensia ako na slabsom mobile.. a to absolutne ignorujem retiny a vyssie pdi, kde by mal ist obrazok s nasobne vyssim rozlisenim..

---------- Příspěvek doplněn 09.01.2020 v 21:53 ----------

Ako to vlastne ostatny riesite?
10.01.2020 19:31
47
Původně odeslal Oleg
@petrx to nikdo v realu neseri, spise se snazi vse gzipnou a prohnat pres CDNka, samozrejme, ze zpracovani 200KB JS je narocnejsi nez vykreslit 200KB obrazek :)
Podarilo se ti vyresit rychlost webu?
HTTP komprese a CDN jsou super a pomohou na desktopu, ale na obyčejných a slabších mobilech je problémem zpracování Javascriptu.

Rychlost webu jsem na některých webech vyřešil minimalizací Javascriptu. Ale u jednoho klienta je teď s Javascriptem malér -- malý firemní web je vytvořen jako SPA v Javascriptu a je to hrozně pomalé na mobilech a dodavatel by za předělání do HTML chtěl milion Kč...