I’ve designed two images for the section that I am working on. The first one is for Desktop and tablet and the second one for mobile horizontal and vertical.
Whenever I change the picture in mobile it also changes the pictures for tablet and desktop. How do I make sure that the different resolutions keep their respective image?
Instead of changing the image (which would affect all breakpoints) you can have two images, one displayed on a set of breakpoints and the other hidden on them. Then repeat. Note: hidden elements are still loaded by browsers. With background images you can set them per breakpoint (or the cascade) and they would only load if the viewport matched.
An image, used as an image (when you drag it into your page from the Asset Manager), is declared in the DOM, that means it’s written in the HTML code.
Responsivity tuning is not affecting HTML, it’s affecting CSS. So if you change the image, you change it in the HTML and the change can be seen on all breakpoints.
You need to add your 2 images, give them each a class, like .desktop-image and .mobile-image, and set their visibility per breakpoint: turn the mobile one display:hidden for desktop, and do the opposite for mobile.
Hi Vincent, thank you for your reply. On my side, I resolved the picture sizes issue by implementing your solution above. I am also using lightboxes to show more product pictures and here comes another problem. When the lightboxes is open to display, my product pictures are showing off twice the time. Could you give me a solution, please?
I wonder if there’s a better way to do this? A picture element with sources built into Webflow would be awesome.
It’s important to make people aware who choose this method that it’s not very good practice to include multiple images and hide/show them depending on the screen size.
As mentioned, browsers will load both images. That means a 1920px wide hero image could be hidden on a mobile device, so the user does not see it and you show your mobile version instead, but that user will still have to download the image even if it’s not visible. So it can really slow down your page load and total file size transfer.
It may also be poor for accessibility, as I imagine a screen reader would pick up on both images, leading to repeated content.
It would be great for Webflow to enable some sort of art direction feature to avoid performance and accessibility issues without custom code.
You can construct that using custom elements, and fully use the art direction feature. It’s easy to setup.
However I’ve really never found it necessary.
This part isn’t quite incorrect-
Browsers only load resources when they’re needed. Try it- setup two images, one desktop only and one mobile only, publish and watch the network tab.
The browser will only load the image it needs, when it needs it, unless you override that with eager load setting. And it will cache that image normally so that further breakpoint changes don’t reload those images.
By comparison the art direction feature behaves a bit strangely in my view- as you change breakpoints, it will keep re-downloading the images every time, with every media change.
That’s possible, and hidden elements are used often to assist a11y. In general for images the alt is what matters to screen readers, so I’d put it on the mobile image only- since that’s visible to screen readers and also the one most relevant to Google’s mobile-first SEO.
If you actually have two different images with different content and different alt texts, that’s already a confusing situation for screen readers and SEO. I don’t see a sensible use case for that approach.
I actually ended up doing that approach and made a component that uses the custom elements to make a picture element and src elements. It’s pretty cool.
Interesting about your point on performance, I tested that out and didn’t realise that. I guess the exception then is for hero images, which is why I made the custom element component as then both the images should have loading="eager" set. Hero images are an important use case too, as that’s the one image every user will load.
I didn’t know that about picture elements redownloading on resize, however, I don’t really think that’s an issue as not many people will keep resizing their window and if they are they’re probably on desktop so performance is less of an issue. Plus it will be after the initial load.
(I’m a big fan of the picture element )
But then the desktop version has no alt text? I’m not sure how screenreaders interact with hidden images, so I would opt for both having the alt text. Especially if the image doesn’t load/there’s a broken link on desktop to avoid an broken image with no indicator of what it is.
I think <picture> is a neater solution though.
We’re definitely talking about some pretty niche points though… Either way, I think art direction is a very useful responsive web design tool to have.
Since hero images are at the top of the page, loading: eager wouldn’t do anything- the image is already visible so the browser will already load it straightaway. I’d leave it as lazy and give it a height for layout efficiency and scrollTo positioning.
Some thoughts;
It’s unlikely that a user will resize the desktop browser to mobile width, so you’re probably not trying to do an “instant” load at the breakpoint transition by eager loading.
Using eager on the desktop hero would just unnecessarily new bandwidth, both for you and for mobile users.
Swiper heroes might be a different case, but I would assume swipers preload. If you were building a swiper with different images for mobile, I’d probably do an entirely separate swiper element for mobile and show/hide at different breakpoints.
From an SEO perspective, I’d want the alt on both, but if your project is prioritizing the a11y ux, always test it on a popular screenreader. It’s the only way you’ll know. You just have to choose you priorities and accept any trade-offs.
I like it too, but really dislike that duplicate downloading. It’s like it’s skipping the cache. That’s not a problem for mobile users unless you have different images at landscape and portrait and they keep rotating their phone. For desktop users, if you had different images at desktop+ breakpoints, they’d hit those extra downloads a lot, which would introduce a weird resize-redraw delay on a large primary image like a hero.
It’s not an area I’ve researched but I find myself wondering why Webflow’s used srcset for its responsive images instead of <picture>. Picture appears to be better supported than srcset, but srcset has a better intrinsic fallback for e.g. the 0.5% still using IE. I’d guess that’s the reason- global support. It would be bad form to publish sites that just have no images on IE… even though it’s, you know… IE.
I wonder if there’s also any SEO advantage to sticking with <img> as the primary element.
Direct support for a picture element would be kind of cool, perhaps with breakpoint-specific overrides ( in settings hahaha ) for alternate images, but it gives me a headache trying to imagine how image variants would work with the CMS.
)
Since hero images are at the top of the page,