I want to know the benefits of using Picture tag vs the CSS media query in-terms of pure performance (website load time).
I am developing a website and clients are forcing me to use picture tag but I think both are same. Let me know your input.
<picture>
<source
media="(min-width: 650px)"
srcset="images/kitten-stretching.png">
<source
media="(min-width: 465px)"
srcset="images/kitten-sitting.png">
<img
src="images/kitten-curled.png"
alt="a cute kitten">
</picture>
or
using media query and targeting separate image tags.
Media query works this way:
Even when you are viewing a website in Desktop, it still downloads the styles of mobile.
Example: If you are hiding a small image in desktop, in a desktop still small image will be downloaded but won't be shown (if it is hidden).
Picture tag: If you have 3 different images for mobile, tablet and desktop.
Picture tag will download only mobile device image when a page loads (when on mobile), it will neglect other 2.
If you want to test:
1. Write HTML code as you have above for 3 different images.
2. Once you are in desktop, load the page. Now you have a desktop image which you can see.
3. Disconnect the internet from your laptop.
4. In your browser responsive mode, keep reducing the screen
5. When it hits the tablet width, you will see the image won't be visible and it will be broken.
6. That means the image for tablet was not downloaded earlier when page load.
I think the accepted answer/question is lacking some real world contextual details. When talking about performance, we're usually talking about performance on slower devices such as mobile devices, not desktops.
Example: If you are hiding a small image in desktop, in a desktop still small image will be downloaded but won't be shown (if it is hidden).
This is usually not a problem as desktops have faster processing and they don't run on data (larger bandwidth) unlike mobile devices.
The accepted answer never mentioned how CSS media queries behave on mobile devices - this method actually only applies the styles that satisfy the smallest media query. The reason why this method 'downloads' all styles on desktop is because of how media queries are usually written with mobile-first design, by setting a min-width criteria. So when loading the page in desktop, all your media queries would be satisfied thus they are all applied and the last one in the source order wins.
So in terms of performance on mobile devices, both methods are the same. Ultimately, the <picture> tag is still the most robust solution due to additional configuration options with the srcset attribute. However, sometimes you need to use CSS media queries instead of <picture> tags such as when dealing with background images.
Here's a recent guide from Google recommending CSS media queries for optimizing background images: https://web.dev/optimize-css-background-images-with-media-queries/
Related
I want to create banner image which is compatible in both mobile and laptop view. I want to store banner image with two different dimensions in database and use appropriately for mobile and laptop view. The two images should be same ( ie any of the image should not be cropped, stretched or any part of the image should not be lost)
How to create such a banner image using Figma. The image should be exactly same when viewed in laptop and mobile.
The image created with different dimensions should be exactly same
Figma files are viewed as static artboards. So you illustrate designs for different platforms. You cannot make 2-in-1 designs that morphs depending on whether you're viewing the Figma file on a Desktop Computer, or a Mobile phone. That can only happen in an actual implemented webpage with Responsive Design best practices, and then viewed in real web browsers.
In Figma, you simply create the design of the Desktop version of that page, containing that banner, and a separate design of the Mobile version of that page, with a copy of the banner image, but resized according to your specifications.
You then present this to the devs during the handover, telling them that those two designs are for the same page, but have to be implemented using Responsive Design.
My ranking from Google Page Speed insights is being severely penalised because of:
"Serve Images in Next-Gen Formats" more info on Google's help page here.
However, according to this, this and this those formats are supported very few browsers.
What do you do in this scenario? What
You could use the <picture> element to deliver a WebP image to users with browsers that support it, falling back to a JPEG or PNG for those that don't. The advantage of using the <picture> element rather than other fallback methods is that browsers that don't support the element will fallback to whatever source is defined in the <img> tag.
<picture>
<source srcset="img/yourImage.webp" type="image/webp">
<source srcset="img/yourImage.jpg" type="image/jpeg">
<img src="img/yourImage.jpg" alt="Your image">
</picture>
Here's a method for converting source images to WebP.
If you're using WordPress there are plugins that will automatically generate WebP images from your media library and include fallback functionality. The only one I've used is WebP Express but it served me reasonably well when a client was alarmed that their 100/100 PageSpeed Insight score took a nosedive to 30 overnight with the Lighthouse roll-out.
This does feel like another way for Google to push another propriety technology but then WebP compression is quite impressive compared to other 'next-gen' formats.
WebP is the one that currently has broader support, pretty much all major browser except Safari support it.
As colossalyouth mentioned on one of the answers you can use the picture tag to load webp images and in the case is not supported it will fallback to any other format you choose.
And if you are using background-image you can use something like modernizr to detect feature support by the browser and end up with CSS like the following:
my-selector {
background: url('../images/home-bg.webp') no-repeat scroll center center
}
.no-webp my-selector {
background: url('../images/home-bg.jpg') no-repeat scroll center center
}
I have actually done both things on my website and successfully implemented webp formats, I have created a detailed post on how I did it and the performance gains I had you can check it out here: Improve your website speed performance using next-gen formats
Until major browsers support those next-gen formats, it's probably best to continue using JPG/PNG, as they have wide-spread support. Most websites do indeed use JPG & PNG and it will take some time till browsers are in-line with next-gen tech.
You could always use an image CDN like ImageEngine. Full disclosure I work for the company behind ImageEngine.
It acts as a pull based CDN and will automatically transform your images to WebP or JPEG-2000 if the end users device supports that format. It will also automatically apply compression and resizing to further optimize your image content, but it will definitely help with your page speed.
You can sign up for a free trial and see how that improves your Google Page Speed score.
You can use a tool like https://www.imagecompress.org/ to convert your current image formats, and follow the example to update your old tags https://www.imagecompress.org/examples.
I recommend you to use "Enhanced Media Library" plugin if you're a wordpress user. It will simply allow you to directly upload Webp images without configuring anything manually.
WebP format will load faster and consume less cellular data. Anyone can work with the format and suggest improvements in WebP open source.
In <picture> attribute <source> can be used to load alternative image file formats that might not be supported in all browsers. For example, you can serve an image in WebP format to browsers that support it, while falling back to a JPEG on other browsers:
<picture>
<source type="image/webp" srcset="images/verz.webp">
<img src="images/banner.jpg" alt="Banner Image" width="100" height="100">
</picture>
Note: The element is currently available Chrome 38. Try it out with screen emulation in the Chrome DevTools. As per Google, WebP is supported in Chrome and Opera and provides better lossy and lossless compression for images on the web. WebP does not support all browsers. For other browsers, You'll need to serve a fallback PNG or JPEG image.
If your website is in WordPress. Use plugins that will automatically convert your uploaded images to the optimal formats.
Long time browser, first time caller....
I have recently re-written my website to use responsive images (which I am new to), but my s7 chrome seems to always load the "medium" sized image, which is the default src.
I have tried clearing cache and using incognito. It still appears that the medium image is loading, although the only way I'm deducing that is by selecting the image and loading in a new tab and reading the url. I'm not sure if this is accurate.
I've also tried changing the default src to the small image, but the medium is still loading.
However, on FF and Chrome desktop, even with developer tools set to mobile device, it seems to work correctly. Here's the relevant code:
<img
class="vertical"
src="../galleryphotos/doveinsnow_medium.jpg"
sizes=" (max-width: 675px) 271px,
(max-width: 1920px) 620px,
(min-width: 1921px) 1240px,
100vw"
srcset="../galleryphotos/doveinsnow_small.jpg 271w,
../galleryphotos/doveinsnow_medium.jpg 620w,
../galleryphotos/doveinsnow_large.jpg 1240w"
alt="Dove In Snow photograph"/>
Here is a link to the page with the above image, although every page on the site behaves the same way:
http://herschbachphotography.com/gallery_index/doveinsnow.html
What am I missing?
As far as I can see, everything is working well. I checked with Chrome Version 69.0.3497.100 (Official Build) (64-bit) and I can see all 3 versions of your image if I change the viewport from 675px to more than 1920px.
Here are 2 ways you could confirm which image is being shown.
If you place a different marker on each of the 3 images it will be easy to tell which one is being displayed.
Another way is to use Web Inspector (from within your browser, right click on your page then choose 'inspect')
Click the network tab, select img, then reload the page. You'll get full details of all the images on the page.
I hope this helps!
This is really weird behavior. Having difficulty even quantifying. Have had to revise a few times.
Best I can do is the following:
The tech stack for my app is Backbone Marionette, handlebars.js, require.js.
The app contains images mostly of icon size - say 32x32 and under. Some jpg, some png, some svg.
Some of the images, the same ones each time, don't display. That's a common issue on which many have posted. No big news there.
But if I hit the sleep button, leave the iPad sit for a minute or two until the unit really goes into hibernate mode, and then revive it, the images slowly and magically fade in. They don't abruptly display when the screen lights. They fade in afterward.
Doesn't work to just hit the sleep button and instantly revive. Have to wait a minute until it truly hibernates.
After true hibernation, no matter how many times I refresh the page, the images are there. But, if I go and clear the cache on Safari and load the page, the images are not there again - until I do that hibernate thing.
All of these images do display without fail in a browser on a PC (all flavors). It's just on the iPad that they don't.
I thought, at first, it was just images I was loading in collection views. It is not. I have a third party HTML5 video player in the app. It has a play button and other controls in svg format. This also exhibits the behavior above.
Once the iPad has hibernated and been revived, the images fade in. Only clearing cache makes them disappear again.
There are no 404 errors when the images don't display (checked in dev console on a MAC). In fact, if I just tap the screen where the video play button is supposed to display, the player begins. So the button seems to actually be there, just not painted on the screen - until you do that hibernate thing.
Some images in the app always load no matter what. I'm looking at those images to see if I can note anything special about them or the code which renders them.
I tend to think it's not the images themselves because the very same images in a plain web page always display on the iPad. Also, that third party video player in a plain web page displays the svg play button and controls without fail on the iPad.
It's just in my app that the behavior occurs. So it's logical to think my app is where the problem lies. I just can't seem to find a common thread for the images that always work vs ones that don't.
Not sure what code I can even post here. I'll look and see what might make sense to post.
Definitely a problem loading images dynamically via the framework. They are there but do not paint. No idea what the problem actually is. Literally only happens on Safari mobile browser. Can't make it happen anywhere else, even old IE. Know one solution that definitely works though. Preload all the images by explicitly including them in a div in your markup. When you load your marionette app, remove the div - $("#preload-images").remove(). Thereafter the images never fail to paint when added dynamically via marionette.
I have not been able to get IE mobile to stop automatically resizing my site design. I am using three stylesheets with media queries to display the site differently on different device screens. I've included the meta tag so it shows the mobile stylesheet on IE mobile but it keeps setting the viewport at 320X480 instead of using the actual size of 480X800. How can I force it to display at the actual screen size instead of scaling for a smaller resolution?
IE Mobile interprets width=device-width as width=320 (in portrait mode) and as width=480px (in landscape mode) for compatibility reasons. See http://blogs.msdn.com/b/iemobile/archive/2010/11/22/the-ie-mobile-viewport-on-windows-phone-7.aspx for full details.
As far as I can tell, the only way to force IE Mobile to display at "actual screen size" is by hardcoding the viewport value to be width=480 (portrait mode). Note that this might have unintended side effects in other browsers, or even already when you switch to landscape mode (too small/large zoom level).
Personally I always use the following:
<meta name="mobileoptimized" content="0" />
This is a very helpful page: http://msdn.microsoft.com/en-us/library/dd938878.aspx