Kupte si prémiovou propagaci a toto místo bude vaše.
Stránka 2 z 2 PrvníPrvní 12
Zobrazují se odpovědi 31 až 47 z 47

Existuje vůbec rychlá single page aplikace?

  1. A kto z vas vobec riesi napr. webp :D

  2. Co se právě děje na Webtrhu?
  3. Ja resim. Kde je jejich podpora tam davam WebP kde neni, tak optimalizovane jpg/png.

  4. Na tom mas predsa picture a srcset.. a bude to fungovat vsade ;) edit: okrem ios a macos, ovsem, mozno za 5 rokov

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

  6. Citace Původně odeslal ne Zobrazit příspěvek
    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" />

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

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

  9. Citace Původně odeslal petrx Zobrazit příspěvek
    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 ----------

    Citace Původně odeslal Oleg Zobrazit příspěvek
    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

  10. 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
    Naposledy upravil Oleg : 08.01.2020 v 11:05

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

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

  13. 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 :)
    Naposledy upravil ne : 08.01.2020 v 12:34

  14. 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)

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

  16. @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?

  17. 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?

  18. Citace Původně odeslal Oleg Zobrazit příspěvek
    @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č...

Stránka 2 z 2 PrvníPrvní 12
Hostujeme u Server powered by TELE3