Designing for speed and hacking user perception (Chrome Dev Summit 2019)

[@jenstornell]

About the squoosh.app. In theory that app is great. In real life we generate thumbnails of the images (on our server), which means that the size reduction is lost.

[@petecapecod]

Hi great video 👍 but any chance you peeps at Google can start adding the GitHub links in the details section?? That'd be wicked cool 💯😎

[@Mustafa-ux]

Peter Cruckshank let me get that sorted for you.

[@petecapecod]

@@Mustafa-ux That would be awesome, thanks so much 😀

[@Mustafa-ux]

@@petecapecod Added :) but for ease here are all of the links :) Squoosh App → squoosh.app/ Squoosh Repo → github.com/GoogleChromeLabs/squoosh Speed matters ebook → bit.ly/speedebook PWA ebook → bit.ly/pwawebbook UX Course → bit.ly/mobileUXdesign

[@hobbyturystaSEO]

from now on I m Your fan. organic sub :D

[@Mustafa-ux]

Thank you :)

[@yt-sh]

Great talk!

[@KirillKhalitov]

Progressive text loading looks like an ancient display, that render any image line by line because of technical limitations.

[@craigadolph9720]

Nice talk, maybe 2nd best overall ? 😘

[@jimfear9128]

developers.google.com/speed/webp

[@danh5637]

That was a great presentation :) Can I ask what data you have to support your claims though about adding 'perceptual' speed hacks. Surely this adds more complexity to code and design and creates an overall slower page, versus say a hyperlight website where the overall speed is low and it can progressively up-fill with more size dense assets after. Interestingly the old 90s progressive gifs sorted this problem out that you had some immediate feedback as it 'ressed up' in the days of dialup. But it seems like adding extra code to solve essentially the same thing seems silly. What progressive formats do we have now that get rid of this over engineering.

[@Mustafa-ux]

So we did a number of studies at Google and research widely shared online, I tried to include the links in the video where possible. The Ebooks at the end allude to a lot more of the research. Its a matter of context, if you are slowing things down and making the experience worse, then don't employ every single suggestion. However the data shows that fast experiences feel slow to users who do not use some of these techniques. You have to pick your places on the web then test with real people :)

[@fxnoob]

thanks for knowledge sharing!

[@Mustafa-ux]

No problems :))

[@TopicalAuthority]

Thank you!

[@erlinvazquezcastellanos4052]

Amazing 👌

[@sandracade3487]

Oh, I think that was just fine.

[@NABZ028]

thanks very interesting !

[@BruceArmstrong09121997]

Mozilla replaced some parts of browser code with RUST code... And gets performance boost..for firefox Why don't u do something like that ?

[@BruceArmstrong09121997]

@Pure thoughtsyup we know that rust's evolution will take years . Or it just might not happen.. Still porting some parts of code into rust changes the speed drastically.clearly dominates other browsers including chrome.. I'm supporting rust cause it have the potential to be like C Language

[@pushqrdx]

@@BruceArmstrong09121997 but rust itself has nothing to do with speed though

[@BruceArmstrong09121997]

@@pushqrdx actually rust is developed by Mozilla to compete with C+ speed along with providing memory safely that C lacks.. As both rust and c are pretty low level.. and every other languages are built basically on top of c Where rust can perform faster and safer at the same time.. than C

[@BruceArmstrong09121997]

@@pushqrdx Rust core team says . It's basic goal is to provide memory safety along with performance competing with c

[@BruceArmstrong09121997]

@intrnl web assembly can work anywhere.. Even for web ... Its not a assembly or web.. Its gettin close tho..

[@RadoslavSharapanov]

Or remove Angular.

[@RadoslavSharapanov]

​@intrnl 100% of the time the Angular bundle is a few hundreds of KB.