JS se da vyresit na libovolnem webu, zalezi co se aktualne pouziva a proc a jak ho lze nahradit / optimalizivat nebo odstranit uplne. I na mobilu muze JS fungovat rychle. Napis mi do SZ URL, treba neco vymyslime.
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:
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:
vyzera to na prvy pohlad hrozostrasne, ale na jeden "tah":- vyriesi rozne velkosti pre rozne velkosti obrazovky- poskytne webp alternativu pre podporujuce zariadeniasice 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! :Dedit: v request hlavicke sa da pozriet ci prehliadac akceptuje image/webp, ak nie, tak sa mu samozrejme alternativa neposle.
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.
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 ----------
Napsal Oleg;1563036
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
Tak jiste, ale proc nepouzijes neco jak to mam ja, usetris si tim dalsich nekolik KB/stranka
misto:
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
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 vyrieseneedit: nie media, type som myslel
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 :)
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.
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)
![](”https://cdn.statically.io/img/webdev.imgix.net/native-lazy-loading/hero.png?auto=format&fit=max&w=1730?w=200&h=200&quality=90&format=webp")
![](”https://res.cloudinary.com/demo/image/upload/w_300,h_100,c_scale/sample.jpg")
Prodej
Více
