I have some images in my web which linked from image hosting sites. All the images require 100% in width.
However, some images have extremely large pixel and therefore load slow.
How I can set the style to reduce the pixel of images while keep the images in 100% width in order to load faster?
For example, fix the horizontal pixel to 1440px and adjust the vertical pixel and keep it in 100% width?
You have very little control over an image that is hosted elsewhere. Some alternate ideas:
Cache them on another server and load from there
Preload for faster results (which might not work if the image is "above the fold") How exactly does link rel="preload" work?
Use the <picture> tag to specify a different image based on screen size: load images using the picture tag
Load a placeholder image first: How to load a small placeholder image before loading the actual content
you need to have 2 versions of each image, one with the original size and you can use this when user request to download the photo, and the other for the display and the UI, this will make your page load faster and less data bandwidth.
Related
I have converted the uploaded image into progressive in backend using Node GM and stored in the file. After that, I want to show that converted progressive images in front-end. My problem is when I rendered that image its getting rendered line by line. But compared to normal image these progressive images are loading first.
But I want to load that images from blur to normal.
How can I do this?
In the frontend, I have written the code using HTML like this.
<html>
<head></head>
<body>
<h1>Hello</h1>
<img style="width:50%" src="https://www.dropbox.com/s/p57ik1kl04k1iax/progressive3.jpg?raw=1" />
<img style="width:30%" src="https://www.dropbox.com/s/3nnc03tfwxrpu5q/Porsche-GT2-4K-UHD-Wallpaper.jpg?raw=1" />
</body>
</html>
At first I couldn't understand why this seemed to be loading in as a baseline image but using Chrome's developer tools, zooming in and throttling the connection showed me what was going on.
Your progressive image is loading in the way you expect, with an initial low resolution image, followed by progressively more detail. The first pass loads in line by line and therefore behaves like a baseline image.
The problem is that the image is so huge, at over 5000 pixels wide, that it's being resized in the browser to the extent that there's no visible improvement in picture quality after the initial image has been downloaded.
In order for the blurred-to-sharp effect to be noticeable, the image would need to be much smaller in pixel dimensions. If it's being embedded on a web page, resize it to the largest size you'd expect it to be viewed at, so at 50% of screen width on a 1920 wide screen, you would want to resize to 960 pixels across. Now the file size will also be much smaller and the image will download faster, so unless you are on a very slow connection it still might not be obvious that the jpeg is loading progressively.
If you need the full size image available to users for printing or some other purpose, then you can always add a separate link on the page along with a warning on the file size.
Eg.
Print quality image (11.1 MB)
You need to have two images
Big sized image
Small image
You need put
<img id="image" style="width:100%, height: auto; filter: blur(5px); transition: 1s filter linear;" src="small image source" />
then do
fetch('big image source').then((response) => response.blob()).then((blob) => {
let img = document.querySelector('#image');
img.onload = () => URL.revokeObjectUrl(img.src)
img.src = URL.createObjectUrl(blob)
img.style.filter = 'none';
})
I don't think it is possible to achieve whatever you are asking. While requesting for a static file, the response will be a stream which is sent in a linear manner (pixel by pixel, left to right, top to bottom). To achieve your desired style, you have to control how image is being streamed to the client. So, it is not possible to achieve this by just hosting a single static file.
But, can simulate this effect by hosting multiple copies of your image (of various resolutions) and load all those files one after the other.
Here is an article on how Medium does this.
Also, lazysizes might come in handy. Here is an example usage of lazysizes. If you inspect the network tab on this page, you can actually see two different sizes of same image being requested simultaneously.
We have a product details page on our website and it has a preview of a large image of the product. The problem is because of it being too large and hi-res, it takes time to load and render on our page. Now I've read about something called image upscaling or from what I've understood it works a bit more like lazyloading the images. So the concept is they generate a very small, in terms of file size and image dimension, version of the large image and set it as the initial preview of the image. Then size it up to same as the large image's original dimension. So it is stretched and they blur it out. They wait for the larger image to load then replace the smaller one with it once it is done loading. I've seen this in multiple blogs and news website and it seems like a very good solution. But my concern is, does this affect our page's SEO? If so, is there a way to implement this kind of behavior without hurting our page's SEO?
I understand that you have a problem with optimizing your images. To solve this, I recommend that you apply the following techniques:
Add the srcset attribute to the img element. The srcset attribute extends the functionality of the img element. If the browser does not support the srcset attribute, by default the image file is imported using the src attribute. If the browser supports the srcset attribute, you can specify a list of image sources and conditions (comma-separated) before the request is received. As a result, only those images that match the parameters of the device are downloaded and displayed.
Art direction in the responsive images with the element picture. If you want the images to vary depending on the characteristics of the device (art direction effect), use the element picture. The picture element specifies a declarative solution to provide multiple versions of the same image, depending on the various characteristics of the device: size, resolution, destination, and so on.
<picture>
<source media="(min-width: 800px)" srcset="head.jpg, head-2x.jpg 2x">
<source media="(min-width: 450px)" srcset="head-small.jpg, head-small-2x.jpg 2x">
<img src="head-fb.jpg" srcset="head-fb-2x.jpg 2x" alt="a head carved out of wood">
</picture>
In the above example, if the width of the browser is not less than 800 pixels, the head.jpg or head-2x.jpg format will be used (depending on the screen resolution of the device).If the width of the browser is from 450 to 800 pixels, the formats head-small.jpg or head-small-2x.jpg (also depending on the screen resolution of the device) are applied. If we are talking about a screen width of less than 450 pixels and a device with downward compatibility, the picture element will not be supported. In this case, the browser uses the img element to display the image on the screen (it must be enabled).
Images with relative dimensions. If the final image size is unknown, it is difficult to select the pixel density descriptor for image sources. This, in particular, refers to images that are stretched proportionally to the width of the browser and change their size depending on it. In this case does not indicate the fixed image size and pixel density. Instead, you can determine the size of the image being processed by adding a handle to width. This will allow the browser to automatically calculate the optimal pixel density and select the correct image to load.
<img src="lighthouse-200.jpg" sizes="50vw"
srcset="lighthouse-100.jpg 100w, lighthouse-200.jpg 200w,
lighthouse-400.jpg 400w, lighthouse-800.jpg 800w,
lighthouse-1000.jpg 1000w, lighthouse-1400.jpg 1400w,
lighthouse-1800.jpg 1800w" alt="a lighthouse">
This example shows an image that takes half the width of the viewport (sizes = "50vw" when applying the viewport) and depends on the width of the browser and its ratio of logical and physical pixels. As a result, the browser can select an image that will be displayed correctly in a window of any size.
Please note that images of the JPG-JPEG format have approximately 50% less volume than PNG. Therefore, they are easier and faster to load. To change the image format and resize images, you can use this tool Photo Editor Online. To compress images, you can use this tool - JPEG and PNG compressors.
The best solution is the use of Accelerated Mobile Pages AMP. Please note that in their implementation of the image element is also used the srcset attribute.
Original source ++ Use Cases and Requirements for Standardizing Responsive Images ++ Responsive images of MDN.
You can use for preloading images of the current web page with meta preload, eg: <link rel="preload" href="//examples.com/images/img1.jpg" as="image">
Read more Preload of W3C ++ Preloading content with rel="preload" of Moz.
For SEO I'm going to assume you want to go by googles standards for my answer.
lazy loading will help your bandwidth, not your SEO google will judge your website by full page load time.
I recommend you compress your images and that will be all the difference.
if you have any pictures you can load 20 pics and the have a button saying load more, then lazy load from there.
this would be a big SEO boost as your now loading half your website.
I wanted to prioritize loading of the logo of our website. I've found preload or prefetching images but this just loads the image after css has been loaded and evaluated. How could I force the image to load in parallel with the css assets so that on first page paint, the image immediately shows?
Two options come to mind:
Use an SVG version of your logo right in your html.
Use a Base64 encoded version of your logo if the size is small enough.
In my HTML5 mobile app, I am retrieving 10 images at a time from imgur (the user clicks a button to get more images). When the images are retrieved, I apply some formatting via CSS (mostly to the height and width so that it properly fits the dimensions of an iPhone).
My guess is that one of the reasons why it’s taking so long is because I’m applying formatting to the images once they’re retrieved and then showing these images. Would I be better off saving the images in the state they should be displayed with the right dimensions so I don’t have to apply any CSS to them? Would this help in getting the images to load faster?
Thanks!
According to this post, you should probably be grabbing only six at a time.
Also, open your browser's debugger, go to the NETOWRK tab and watch how long things are actually taking.
Are the images that you are loading actually bigger than the display size? If so, it will load slower not because of the CSS application, but because you are loading unnecessarily big images. You should always re-size the images that you use to the displaying size. You can also change the format and/or compression of the images to make it smaller, thus loading faster.
Are there any differences in performance or load/caching behavior when displaying images in img tags vs divs with image backgrounds?
My example:
I have a site with many overlapping images, some of which I will need to load dynamically with javascript. One issue is that I need to anchor the images to the right of the element, so that I can do a nice wipe-to-right effect. Because of this I was using a div with background image positioned right. Couldn't figure out how to do this with img but since divs are working for me I didn't know if this would matter...
AFAIK, browsers cache images the same whether they're in a DIV or an IMG. In any case, I think this one of those cases where specific performance is defined as an implementation detail internal to each rendering engine (and possibly the browsers built around them). As such, it's both out of our control as designers/developers and subject to change from browser to browser and version to version. In other words, I wouldn't spend too much time worrying about it.
The main performance difference is using background images allows you to use CSS sprites. Having one image contain a large number of images from your page means the user only has to make one request instead of one for each image.
Another difference is with responsive layouts. If you have an element that is only shown at certain screen widths (ie, not on mobile phones), it will still load the image if it is specified in the html (using display:none for instance), but most all browsers now will NOT load the image if is a background-image specified in unused media query-CSS rules. A lot of early responsive layouts got criticized because they still used the same bandwidth as the full size sites.
It is also useful with such designs because you can easily specify different images for different screen sizes. "Retina" displays on tablets and even laptops now won't look their best without 2x res graphics. So... even if you don't do such things now, it is probably a good practice to get into, because you might find yourself needing it soon!
I think by using background-image attribute in the div, the page layout gets loaded first and image present in the divs loaded later after the dom is loaded. so by using background-image the html layout is loaded faster on the web browser.
The only difference I can conceive of it this:
You can't scale images as backgrounds, although you can for img tags. This would open a scenario where background images loaded faster becuase it forces you to have the correct native size as opposed to downloading the entire image and scaling it. However, the converse could be true: given that you didn't care about image quality so much, you could deliver smaller imgs to your page and scale them up.
I'd stick with whatever rendered cleaner (and more consistently -- IE/FF/Chrome/Safari/etc).
Technical differences yes, most notably you can set the width/height of an IMG tag and it will stretch the image, which can be useful in some situations.
The main thing you've got to keep in mind though is the context of the image within the HTML document. If the image is content, say an image in a gallery, I'd use a IMG tag. If it is just part of the interface I might use a div instead.