Download presentation
Presentation is loading. Please wait.
1
Building Responsive Media for Optimal Performance
Robert Moseley – Cloudinary
2
<img src=“insufficient” />
The Web is FLUID VS Everything about bitmaps is fixed. [height/width/content, no such thing as PE or responsively designed JPEG] The web, on the other hand, is flexible: borderless/adaptable/FLUID we use the term “fluid layouts,” ideally the web extends that metaphor ***the web should be like water*** freely flowing, following the path of least resistance, filling devices of any shape and size work of being a web dev = shape and facilitate flow. the flow of bytes across the network, and the flow of content into all kinds of devices - past/present/future but right now, within this flow, there are all of these solid chunks — plague of single-source bitmap images I’m here to tell you: they’re gumming up the works Bitmaps are FIXED
3
BITMAP IMAGES ARE THE BIGGEST PERFORMANCE BOTTLENECK ON THE RESPONSIVE WEB
That’s a bold claim; luckily I brought some numbers to back it up. Here’s an incredible statistic from the HTTP archive
4
65% Of the web is IMAGES 65% of all of the web’s bytes are IMAGES. Most of the web is images!
5
And the size of those images is BALOONING - the per-page average image transfer size has tripled over the last 5 years. Why? are our images so big? why are they only getting bigger? for the answer, we have to follow the pixels
6
In 2012 average total page size was about 1MB, today images along average 1.3MB!
7
4 resolutions accounted for >70%
In 2009 4 resolutions accounted for >70% of all traffic (and they weren’t all that different) Way back in 2009, we only had a few different display sizes to account for, and they weren’t that different from one another
8
The top 4 resolutions accounted for <42%
In 2017 The top 4 resolutions accounted for <42% of all traffic (and they are totally different from each other!) Nowadays we have innumerable resolutions to deal with, the top 4 only account for 40% of all web traffic, and those are VASTLY different from each other. Yikes!
9
What we’ve done about it… is render our images as big as the BIGGEST screen that we want to worry about. then
10
slap a `max-width`=100% on ‘em
11
and let the browser cram them down to fit smaller viewports.
We do this because visually, it works. But it’s a performance DISASTER.. Every time we send someone more pixels than their device can display - we’re forcing them to load data that they can’t use. We’re sending them WASTE. How much waste? Tim Kadlec has done some execllent work to put a number on it. three years ago / 400 responsive pages -> published these numbers:
12
360px 760px 1260px 72% 53% 42% Viewport Wasted Image Bytes
On narrow viewports, 72% of image bytes are WASTE. put that another way, low-resolution devices are getting 4x as much as they need! Remember that first statistic - that 65% of the average webpage is images. if we can cut percentages like these, out of a percentage like that, we can save people enormous amounts of both time and money And! We need to worry about more than just byte sizes. Gigantic images affect *everything* they touch. The network connection is where our problems BEGIN
13
Great, let’s do it! But… how are responsive images done?
14
There are three main ways to handle responsive
There are three main ways to handle responsive. We’ll talk the pros and cons of each method and provide examples.
15
Method #1: JavaScript Pros: Easy to implement
Works across all browsers Cons: It’s JavaScript Adds extra weight (and wait) to the page Markup can be confusing Must create common naming pattern for all sizes of images
16
JavaScript Example <head> …
<script src=“responsive-lib.js” /> </head> <body> <img data-src=”//res.cloudinary.com/demo/w_auto/smiling_man.jpg" class="cld-responsive” /> <noscript><img src=“//res.cloudinary.com/demo/w_1920/smiling_man.jpg” /></noscript> ... <script>cloudinary.responsive()</script> </body> No src attribute?!? Most would be rightfully uncomfortable with this but there’s no way around it with modern browsers preloading images before even any CSS or JS is executed. For this reason, and the fact it’s not natural markup, there’s actually a more “modern” way of handling responsive images: Srcset.
17
Method #2: The “Srcset” attribute
Pros: Does not use JavaScript Very fast, also supports DPR Native markup browsers understand Cons: Lots of extra (somewhat confusing) markup Not supported on old crappy browsers Src can be defined as fall-back Polyfill can be used
18
Srcset Example <head> … </head> <body>
<img sizes="(max-width: 1000px) 100vw, 1000px" srcset=” //res.cloudinary.com/demo/w_200/smiling_man.jpg 200w, //res.cloudinary.com/demo/w_508/smiling_man.jpg 508w, //res.cloudinary.com/demo/w_721/smiling_man.jpg 721w, //res.cloudinary.com/demo/w_901/smiling_man.jpg 901w, //res.cloudinary.com/demo/w_1000/smiling_man.jpg 1000w” src=" //res.cloudinary.com/demo/w_1000/smiling_man.jpg" /> ... </body> In the srcset attribute we define the different image sources and let the browser know how wide each one is. In the sizes attribute we then use media query expressions to define the width of the image at any given point. These breakpoints should be the same of your page’s breakpoints.
19
Method #3: Client Hints! Pros:
Simple markup - only using src again! (well, “sizes” too…) No JavaScript Cons: Can be confusing as the same URL may return a different image response. We are not used to this, yet. Additional logic needed at CDN layer Only Chrome, Opera, and latest version of Android support CH
20
Client Hints Example ++++ A bunch of logic at the CDN layer…
<head> … <meta http-equiv="Accept-CH" content="DPR"> </head> <body> <img sizes="100vw" src=" //res.cloudinary.com/demo/w_auto/smiling_man.jpg" /> ... </body> ++++ A bunch of logic at the CDN layer… In the srcset attribute we define the different image sources and let the browser know how wide each one is. In the sizes attribute we then use media query expressions to define the width of the image at any given point. These breakpoints should be the same of your page’s breakpoints.
21
That’s all SO cool! But… how do I know which image sizes to create in the first place?
22
Creating too many images is not ideal as that will harm the cache rate, nullifying any benefit.
Do I create image sizes according to my breakpoint widths? No, the image sizes change even between breakpoints. What about creating images at regular intervals between max and min widths? No… I don’t care about the physical size, really just the bandwidth load. Oh I have an idea, the “Bandwidth Budget” I’ll call it!
23
There, I’m done! WTF, Bandwidth Budget? 5 dimensions: 200px 1000px
What’s that feature, Bandwidth Budget? 5 dimensions: 200px 400px 600px 800px 1000px There, I’m done!
24
This is ok, but… WTF, Bandwidth Budget? 5 dimensions: 200px 1000px
What’s that feature, Bandwidth Budget? 5 dimensions: 200px kb 400px kb 600px kb 800px kb 1000px kb This is ok, but…
25
WTF, Bandwidth Budget? 9 File Sizes: 20KB steps
28px 48px 68px 88px 108px 128px 148px What’s that feature, Bandwidth Budget? 9 File Sizes: 20KB steps Maximizes Bandwidth Savings
26
Find this stuff interesting? Want to learn more?
27
Thank you!
Similar presentations
