Images for Everyone
Presented by: Kornel Lesiński
Originally aired on October 26, 2021 @ 9:00 AM - 9:30 AM EDT
Overview of Cloudflare Images and Image Resizing products.
English
Transcript (Beta)
Hello everyone, my name is Kornel Lesiński. I'm a developer on Cloudflare image products including our new service Cloudflare Images.
So today I'm gonna introduce you to our image processing products, give you some background on our history and features and what we've added recently and you know how can you benefit from serving and storing images with us.
So one of the oldest products that we started with is called Polish and it offers conversion from JPEG to WebP format automatically for all of the images on your website.
However it doesn't do any resizing so it's still up to you to make sure all your images are properly formatted for whatever page layout you have.
Now image resizing is all about image performance.
If your image is too large, has too many pixels, there's a cost to delivering this extra unused data to all your visitors.
Especially if you need to just display a thumbnail, it doesn't make sense to send thousands and thousands of pixels which adds up to kilobytes or even megabytes just to display a small tiny image.
Wherever you embed an image on your page you always want that image to be at the right size.
Now historically it's been just done by web developer sort of offline maybe photoshop and exported for the web but if your website is large say it's you know maybe e-commerce website you might have your product image on a different size on product page or in a product category in a checkout page product listing email template.
So preparing all those sizes gets really tiring pretty fast and managing multiple copies of the images.
So that's why we've introduced image resizing product where you can use either a worker or a predefined URL scheme to ask for any image from anywhere on the Internet to be fetched resized and optimized just to the parameters you specify.
So if you need a new size of a thumbnail just say get my image from my server but it has to be 300 pixels wide and we've built a whole pipeline that will fetch that image apply resizing and other option cache the resized result and deliver it the best we can.
And this works very well and it's super flexible we still recommend it you know if you if you want this flexibility and freedom to use any format and thanks to integration with workers you can also have any URL scheme that you want you just write your worker javascript that takes parses the URL you know URL could be my assets and small and then in your worker you can say well if whatever URL says small then it actually means you know 300 by 200 pixels or something like that or you can hide where your full size images are stored by just putting that actual origin URL in your worker and present nice short SEO friendly URLs on your page.
However resizing just by fetching any arbitrary URL from the web has this problem of bandwidth cost.
We have all over 200 data centers and if every data center fetches an image from your origin that's like multiplying amount of bandwidth from your origin and some of the hosts charge a lot for this.
We've partially solved this problem by adding a tiered cache so if you ask for tier cache with your image resizing instead of each data center fetching your origin image individually we'll route it through selected top tier colors and try to cache them fetch them from few places and cache them in those key locations to avoid hitting your origin.
However for some of our customers even that is still expensive and they would rather have cheap storage directly at Cloudflare plus if you store images with us we have more time to optimize them or control how we store them how we cache them and we can add extra convenience on top of that.
So that's why we've come up with Cloudflare images.
Cloudflare images gives you the same logic and optimization that you get from image resizing product but it uses our own storage as the backend and you get an API for uploading images including a specific API for uploading images by end user where you can just let anyone's browser you know for a visitor any visitor to your website upload an image to your bucket without giving any extra permissions it just gives one time permission for you know one specific image and is controlled via the API.
So you know that's one cool feature that you can use with Cloudflare images that you couldn't just use with your server storage without writing a lot of that upload and verification logic yourself.
So with Cloudflare images we also focus on making pricing simpler with resizing you're not only paying us for the resizing product but you pay your host for whatever bucket or storage backend that you're using and you're paying for bandwidth between Cloudflare and your storage provider and managing two different bills is complicated could get expensive with Cloudflare images we've simplified the pricing and the important and very good thing for you is the pricing is per image per original full-size image that you upload with us and it's not per megabyte of images so we want to encourage you to upload the best quality image that you have so that we have enough pixels to work with when scaling images down to the right size because you know if you upload that web optimized small images to save on your storage space then we would already have to deal with compressed low quality input and you know we cannot make quality better so if you upload the low quality images we would be forced to pass on the low quality images in the output but if you can store original images with us then when you're making all the right sizes applying filters optimizations and choosing right compression quality we don't have to worry about any distortions already in and we know that whatever we produce is the best quality that we can get with Cloudflare images we support and resizing as well we support all the latest image formats and you get them automatically so we support WebP for Safari and we support the new AVI format for Chrome and Firefox also if you don't use these formats we have support for progressive JPEG and do very high quality delivery of progressive JPEG images with integrated progressive JPEG with low level properties of the HTTP2 protocol so when you have multiple progressive images on your website we're gonna split every sort of layer of progressive JPEG and set it in separate HTTP2 frame to ensure that all the previews of all the images on the page are rendered first before sending the heavy rest of the images unfortunately WebP format does not support progressive rendering so you don't get that faster preview with WebP but we also support AVIF and compression in AVIF is so good that it's competitive with progressive JPEG not by supporting progressive but just by being such a smaller file that it delivers entire file in almost half of the time now there's one more unique feature in Cloudflare images that we call variants variants are a sort of a preset for for your all your sizes templates for sizes of images that you have on your website so this could be something like a thumbnail a banner a promo image product preview wherever you have some specific sized slot on the page you give it a name and then that name let's it can be applied to an image and you predefine them all in the Cloudflare dashboard where you can choose scaling methods things like whether you want to apply blur to image for example and we'll be expanding number of options that you have there you can also define variants through Cloudflare images API so you can programmatically create delete manipulate those images and if you're using the programmatic API all of the options of image resizing are available to you so you can for example add watermarks to some of the variants of your images and the cool thing is about the variants because they're already they're defined in one place in the API dashboard you can change them after the fact so and when if you change them you don't have to change your image URLs it's typical for websites that once image is uploaded that image URL is used in many places it might be embedded in your blog post you might send them out in your emails or just embedded code of your page templates and once the image URL is used in many many places changing that becomes hard if you ever need it but sites do roll out new designs you might decide your sidebar is going to be wider so instead of chasing all of the URLs for all the images that could ever appear in the sidebar that might be in your database templates libraries and wherever you just need to change the definition of the variant that is used in Cloudflare images and will automatically purge the cache for you apply the new size of the variant and update all the images on the fly to use the new size as soon as possible our cache purging is pretty quick so it could be as quick as 30 seconds to have your all of the images using a specific variance react to the new requirements that you specify now for resizing we also have multiple options the default is scale down the terminology is borrowed from the CSS object fit property so we try to never enlarge images that applies to both Cloudflare images and image resizing so if you say you want image size at 300 pixels but you upload an image that has 100 pixels we leave it like that we will not pixelate it because there's there's just no point in doing that it will not look better it would be just waste of bandwidth to send those extra blurry redundant pixels but you know if you upload an image that has 1000 pixels well we'll still scale it down to 300 pixels but if you actually need images at exact dimensions that you specify then there's a cover that will enlarge and crop the image to exact width and height that is that you specify um what else is there uh with image resizing people sometimes say that they would prefer images to be sharper with image resizing we have sharpened parameters so you can just adjust it to your taste with Cloudflare images we're in the process of expanding the UI for defining custom options but you can already from the API ask for sharper images with the other side we've also added blurring for example we have a if you have a use case for displaying member -only images so imagine you have a paid website where some people have access uh to full quality uh images and you know someone who's not a member is not supposed to see the full image but you want to display something so you could display um a blurred preview we also support drawing watermarks on that so you could you know add a logo on that or some message hey you know you would see this image if you've logged in for example um so all these options can be also uh um simplified to be a variant so you can have full quality full access variant and preview with a watermark variant apply to the same image url now it might you might be wondering but what if someone figures out your URL scheme and changes to changes the preview urls to the full quality urls that's where our protection feature comes in how their images also supports signed urls so you can define that some of the images are protected and some variants cannot be freely used with any image that the variant is only applicable to you know protected image and requires assigned urls uh url assigning scheme is uh i've tried to keep it as simple as possible it needs a little bit of cryptography so there's a sort of a password secret that you will use with uh with a hash that is appended to the url and also you can append uh expiration date so with a few lines of server-side code and we have examples for that um you can generate uh temporarily expiring urls for specific variants of the image and that url only allows that specific variant of that specific image to be viewed and nothing else so with clouder images you can also manage your private uh uh private images you know for private view only uh using the signed urls apis uh now if you have any questions about this um you can ask for this segment uh i cannot ask your questions i cannot answer your questions in real time uh today but uh we'll schedule next segment next time and uh you know include include your questions uh in there uh you can also ask our on our forums um and also did you know that our documentation is open source and on github so if you find a typo or you know want to complain there uh we're also there and you can see our entire documentation system for uh for cloud third so it's at uh developersclutter.com right so um i finished before my time so i'm gonna rewind back to beginning and give you a summary of uh what has been about so uh image resizing and image optimizations are ultimately about performance we're focusing on delivering images as quickly as possible as efficiently as possible uh to your visitors um there has been there have been many many studies showing that uh faster more responsive websites uh give you better results whether you're you know selling something or when people engage with your website uh if website is slow then people just don't stick around they give up they move somewhere else if your website is quick and responsive um then people even instinctively feel this uh and get hooked up and you can browse more uh can do more things on your website there are uh some isps or in places in the world where bandwidth is still expensive so even if you said you know i don't care about performance that much my visitors are very patient it you know it might still be a matter of the cost and if you look at the breakdown of typical websites usage images are the majority of the bandwidth i'm assuming you're don't wasting too many bytes on unnecessary javascript libraries but you know assume if you don't throw in your website with javascript the next biggest problem is delivering images in a fast and efficient way and when we look at this you know it's a it's a matter of choosing right format it's a matter of choosing right quality but the biggest biggest mistake that people do is not resizing images properly for example you might have a blog with some kind of a cms that allows upload of an image to embed on the blog if that blog does not is not integrated with resizing you will find that people take photos straight from their digital camera they might be like 12 megabytes files and they'll just upload it and display it and because they're on your company wi-fi or you know they're using the have fiber optic connection using latest macbook they will not even notice how big and expensive the image they just embed it and we've seen many many customers that try to solve it by just chasing people and trying to educate them do not upload large images uh telling them you know you should choose this format if this or that format if that and there's like a whole flow chart but um why risk it you know you could just integrate uh with image resizing and make the problem go away just have your website specify this image needs to be is to have this size and let us do this and using Cloudflare for this is usually much much more convenient than rolling out your own resizing there are many server side tools libraries that you can do but if you do you're reinventing something that's already been done many times but you still have to worry about defining those sizes caching those results because you know resizing on every request is is going to be slow so you need to do proper caching if your website has any kind of a scale of traffic you'll also have to worry about cache stampede problems and different race conditions and cache flushing so we've already battled those problems we've already battled the scaling problems we've already dealt with compatibility issues across browsers and we have infrastructure to do all kinds of content negotiation and optimizations on our edge network so like for example taking advantage of the avif format is great because um it's the the first proper modern uh compression codec that is actually available in browsers and shipping now so it's not a promise of oh maybe something supported someday it is a codec that works in chrome and firefox uh today but because it works only in the latest versions of those modern browsers uh if you have visitors with safari Internet explorer or something else that does not support this format you have to deal with serving different types of images to different browsers this is super annoying because now you have to have a two or even three versions of every single image every single size of every single image and generating all of this manually is a chore and then you need to use hdb content negotiation to serve the right image to the right browser hdb content negotiation is the right solution for this the less and technically advanced solution is the picture element which lets you define different sources and uh declare media types for each source however the picture element first of all it needs adding a lot of markup to every instance of every image on the page whereas content negotiation is automatic it just works for any url plus um people do save and share images so if someone with a latest browser uh took a url of the image and sent of the image that was specifically url for the other format and then shared it with another person who uses a safari uh then that link would be broken because safari would get a format that does not support but if there is only one url that supports all of the formats depending on who's asking uh then that url will work uh for serve the right image for chrome users serve the right image for safari users um and even you know display proper thumbnail uh in whatever messenger messenger that is using that probably doesn't support either of these formats and needs a jpeg and of course it supports crawlers all kinds of bots so hdb content negotiation is the best way to serve images but that needs dealing with caches uh if you just had a server-side logic that uh detected the browser you wouldn't be able to cache the image at the cdn and every image request would have to go back to your origin server run your custom code detect the browser and surf the right image all the way from your origin server uh if you permitted that image to be cached and did not set proper vary headers only one of the versions would be cached and it would be a mess so we've seen people struggle with properly implementing this hdb content negotiation and fortunately uh when we we do it so we know how to deal with the code at the edge and because we perform the negotiation using our worker technology it's fast and it's done close to the user so images don't go all the way to the origin we just quickly detect the browser and fetch the right image from our edge cache on our uh on our network so there's no penalty for doing this content negotiation at the edge plus if you use image resizing and cloud for images you're benefiting from our delivery and we're constantly working on more things we'll be looking into specific better delivery for mobile devices you know you already can do some logic specific to mobile devices using a device negotiation we also add an extra header for workers where we try to detect whether you're dealing with a mobile device tablet or a desktop and because you can run worker on on the edge you can expand this logic to whatever you want you can add a custom device types different conditions maybe even detect which network request is coming from and don't have to worry about caching all of this properly because when your logic runs at the edge the logic part can run every time and doesn't have to be cached we only cache the file bodies that you're sending over one more thing common issue that people have with serving images is gif animations gif is a format from animated gif from 1989 computers were very different back then resolutions were much much smaller and the whole format is designed for really really tiny maybe animated smiley image but these days gif memes or screencasts or just taking a fragment of youtube video clip and embedding on a page that is a popular use for it so with clutter images we can convert those gifs to animated webp which makes it better but i would recommend not using gif at all and just embed a video file using modern codec most browsers support h.265 and mp4 and now av1 which is like avif but for video and animated so use video tag instead of gifs so we're that's all that's all time i had for you so thank you very much for listening try out clouds for images let us know what you what you think about it uh and let us know what you need we're deciding on the roadmap for it bye