We’re excited to announce that starting today, all inline images will automatically scale for every device size and resolution. In our internal tests, this update can improve mobile page load speeds for image heavy pages by as much 10x. For a full walkthrough of the update, check out our blog post and landing page.
If you have an existing site, a migration process will start the next time you open the Designer. Read the help doc for more info on how to use the feature. Let us know if you have any questions!
I read that everything above 3200px will be shrunk down. So maybe producing 3200px wide images is the right workflow from now on. This needs confirmation
This is a fantastic addition! And looking forward to background images and rich text images being optimised also!
So now, the next big questions…
When do bulk image uploads come?
And dynamic lightboxes?
Maybe we should give you some breathing space after this huge release…but they are just so important and crucial for some clients…and I imagine that this release makes it less cumbersome on the servers to serve up dynamic galleries…
Are these two features on the roadmap? It’s so important that clients can upload a gallery with the click of a button rather than having to upload each image individually into the CMS. Any info on this would be helpful so that I can tell my clients that this will be possible…even if it’s a way off…
@esoteric_designs
You can use the keyboard shortcut cmd + shift + o on mac, or ctrl + shift + o on windows. This will reveal a checkbox in image settings to turn it off for an image element.
Can you DM me or contact support@webflow.com with some info about your site and the image being affected so we can look into the compression?
Thanks
@krubens@chrisgreer33@vincent@jdesign
We create variants up to 3200px wide as long as the master is larger than the variant. We do not apply any compression to the master image you upload but do make it available in the srcset list. This means you should be able to upload an optimized 3200px (that’s 1600px at 2x).
As an example if you have an image that’s shown at it’s largest at 800px then our 1600px variant is the largest that will ever get used (when viewed on a retina screen) and uploading a ‘larger than 1600px’ un-optimized image or optimized 1600px image would be fine.
The full set of variant widths we currently generate is 500, 800, 1080, 1600, 2000, 2600, 3200.
So if I’m understanding correctly, we should save an image at the largest size we want it displayed? For example, for a hero image, we’d save it at 3,200 pixels, but for a smaller image, we might save it at 1,000, correct? We don’t save every image at 3,200, right? Sorry for any ignorance, just trying to understand.
It’s up to you. If a 3200px variant is generated and available in srcset, the browser will only use it if the image is rendered at a size that requires it, so it doesn’t hurt having larger images/variants than needed.
The main point is that if you upload a master at exactly 3200px we won’t compress it, but will generate and compress the smaller variant sizes (2600px and under).
Also note that depending on the filetype and content, our compression may or may not be noticeable. We’ve tried to fine-tune it to look great in most cases.
For example:
The compression for a scenic jpg from a 2020px master to the 2000px variant may not be as noticeable as doing the same for an image with text or fine details. In some cases a png may be better.
With any type of image content a 2400px master would result in a better 2000px variant than a 2020px master because there’s more information to start with.
