Top 6 Tips For ecommerce optimize image
In this blog, I'll explore six tips to optimize images on your eCommerce website. It is not uncommon for an eCommerce page to reference hundreds of images. These images are everything from full-sized product images, smaller product thumbnails, category images, banners, page decorations, and button icons. Given their abundance, how can you make sure that they are fast and efficient?
The first tip to optimize the image used on your site is to eliminate cumulative layout shifts. Cumulative Layout Shift-- or CLS for short-- is where the contents of a page visibly move around on the screen. You know those sites, you stop reading or you try and click on a link, and suddenly the page content moves. It's really annoying. Images can contribute to this problem if used incorrectly.
CLS is so impactful to a user's experience. Google has defined CLS as one of three Core Web Vitals. These are factors that Google considers important for user experience on all web pages. So why can images cause CLS? To load a page, your web browser starts to download the HTML markup of the page. Most browsers will start displaying the top of the page before the whole page has been downloaded. To reduce your wait time, any references to images encountered are added to a queue of resources to download. JavaScript and CSS files are also added to the queue. These files are then downloaded in parallel to the main page a few at a time.
The problem is when the browser does not know the image dimensions before rendering the page content. Layout shift occurs if the browser discovers it did not leave the right amount of space for an image. CLS is often easy to spot on a page manually, watching it load. But there are also automated tools that can measure it. But let's first take a slight detour and talk about lab versus field data. Lab data is collected by testing tools that you point at your web page, such as Google's Lighthouse.
You can perform a lab test at any time and have complete control over the process. Field data is collected by measuring what happens to real users on your site. In production, field data can be collected using JavaScript you embed in your own web pages or via anonymized data collected by Chrome. Chrome makes data for popular sites available in the Chrome User Experience Report, or CrUX, for short. Lab data can be easier for developers to collect and analyze, but it has some limitations.
For example, data can miss shifts that occur after a page finishes loading. Ultimately, it is field data that demonstrates whether you've really solved a problem for your users. PageSpeed Insights is a useful tool, as it presents both lab and field data in one report. For CLS, look for warnings such as avoiding large layout shifts and images that do not have explicit width and height. Just be aware that layout shifts in the report can be caused by things other than images, such as JavaScript. Fixing image CLS issues can be as simple as including image dimensions in the HTML markup.
That way, the browser immediately knows exactly how much space to reserve for the image. There are other CSS tricks that can be used as well if the CSS is loaded properly.
Also Read: Basic requirements of e-Commerce
The second tip is to pick the right width and height for your images. Larger files take longer to download, particularly, on mobile phones with slower network connections.
Larger files also require more time to process, especially on mobile phones with less powerful CPUs. Sizing images correctly can be complicated by the range of device sizes and resolutions that access your site. If the browser shrinks or crops the image, the download file is larger than needed, which is wasteful. One easy way to detect incorrectly sized images is using the properly sized images section under Opportunities in the PageSpeed Insights report. Page speed insight identifies images on a page that have larger dimensions than needed, listing the URLs. Once you have detected there is a problem, how to fix it.
Responsive images refer to techniques to make images behave well on different-sized devices. For example, in HTML, there is a source set attribute that allows you to list URLs for different sizes and formats of images so the browser can pick the best one to download. This requires you to resize the images in advance or perform imagery sizing on demand. If resizing images is too much work for your own site, consider using a Content Delivery Network or CDM. Many such services can resize images and convert them to more efficient formats on your behalf. The next tip is to think about the file format of your images such as whether to use PNG, JPEG, or webP files.
The file format affects the file size. Care should be taken, however, as formats such as JPEG and webP can reduce files using lossy compression algorithms. Lossy means image quality may be reduced as a trade-off for reducing the file size. If pixel-perfect images are required, such as for button icons, less efficient, but pixel-perfect formats should be used. While lower-quality images may sound like a bad idea, remember that the degradation in quality may not be noticeable to shoppers. And the speed benefit can be substantial.
Also Read - Best Ways to Hide Website in Google Search Result
Shoppers may abandon your page if it takes too long to load. To detect if your site can benefit from using a different image format, look at the serve images in the Next Gen Format section of the PageSpeed Insights report. This report lists images on a page that are candidates to be converted to a more efficient file format. So is there a single best image format to use? One complication is not all image formats will work on all browsers. The caniuse.com site can be used to check which browsers support which image file formats.
For example, webP is now supported by almost all browsers in use. So offers a good combination of efficiency and adoption. Alternatively, rather than picking a single format, you can have your website return the most efficient format that the browser says it supports. Again, this is a service offered by CDMs.
Tip number four is to use the right quality factor for your images to encode them efficiently while retaining the desired image quality.
The Encode Images Efficiently section of the PageSpeed Insights report can be used to identify candidate images for compression optimization. The report also shows potential file size savings. Be aware, however, that the report does not perform a visual check on your compressed images. The report is based on commonly used compression factors. To find a quality factor you are happy with, use your favorite image conversion tool on several images using different quality values.
A common default value for webP is 75. The Squoosh. app site can be useful for this purpose, as it makes it easy to compare the before and after version of images. Remember also, there are times when you want higher resolution images, such as when you want to allow the shopper to Zoom in on a product image. Want to go deeper? Jake and Surma have a great session on image compression they gave at Web. dev Live.
Tip number five is to tell the browser how long it can safely cache images. When you return an image from your site, you can include an HTTP response header with caching guidance, such as how long it is recommended for a browser to cache an image. One approach to detect if the HTTP response cache headers have been set appropriately on your site is, again, to use the PageSpeed Insights report. The Serve Static Assets With an Efficient Cache Policy section of the PageSpeed Insights report identifies images that may benefit from caching improvements.
Another approach is to use a networking tab in developer tools, inside Chrome, to examine the HTTP cache response headers. To fix issues on your site, check to see if you have platform or web server settings you can change to adjust the cache lifetime for images on your site. If you do not change images frequently, or if you always give images a new URL, then you can set a very long cache lifetime. In addition to a cache duration, using a CDN frequently makes downloads faster by caching copies of your images in multiple locations around the world, closer to where users connect from.
The final six tip is a more advanced tip. Correctly sequencing the order in which resources-- including images-- are downloaded can significantly improve page performance. Because downloading the images one by one can be slow, browsers using HTTP1 typically download several images in parallel over independent network connections to the website. If the website supports HTTP2, most browsers now multiplex downloads over a single network connection. This is generally faster and avoids problems such as large files blocking the downloads of smaller files. Whichever approach is used, there is still a network bandwidth bottleneck. In general, you want images to be downloaded in the following order.
First, you want to download large hero images at the top of the page, as they can affect the largest Contentful Paint score for the page. Largest Contentful Paint, or LCP for short, is the time it takes to show the user the main content of the screen. Largest Contentful Paint, like cumulative layout shift, is a core web vital metric. Next, you want other images that will be visible without scrolling to be downloaded. Images that are visible without the user scrolling are referred to as above the fold. The rest are referred to as below the fold.
As a web page may be viewed on devices with different screen sizes, it is common to estimate which images are above and below the fold by checking your site on multiple devices. Finally, you want images to be downloaded that is just off the screen so that they can be ready for display when a user starts scrolling. Other images that are not likely to be displayed soon are often best to load lazily.
Also Read - Do URL Structure Changes Affect SEO Performance
If the user does not scroll the page, fetching them would be a waste of resources. To detect if your site is loading images efficiently, again, the PageSpeed Insights report can help. For example, the Defer Offscreen Images section of the report identifies images that could be loaded after other images. There are other sections that can be useful, such as Avoid Chaining Critical Resources. Although these chains typically involve JavaScript and CSS files.
A common technique to improve the order of image loading is lazy loading. This is where images are not downloaded until the user scrolls to that portion of the page. Lazy loading was originally implemented using JavaScript. But now most browsers support the loading equals lazy attribute of HTML. Care should be taken, as performance degradation can occur if lazy loading is used for images above the fold. Recent versions of Lighthouse will highlight if an image is lazily loaded that will impact LCP. With the advent of HTTP2, there are additional optimizations that are possible if the browser and website both support HTTP2. An HTTP2 website can start pushing images to the browser that knows are going to be needed, without waiting for the browser to request them.
The HTTP/2 also allows browsers to more efficiently download multiple images in parallel over a single network connection. To take advantage of HTTP2, either your web server must be configured so it knows which resources to push, or use a CDN with HTTP2 support and configure it to push resources, as required.
To wrap up, I've shown common problems that it can occur on eCommerce sites with static images. Some have easy fixes, such as ensuring that image tags in HTML always specify the image width and height attributes, or using the loading equals lazy image attribute.
There are more advanced techniques that you can implement directly on your website, but it may be easiest to use a third-party CDN with suitable support. Such services can serve images in the best format supported by the browser, convert images from a single source image to more efficient formats as needed, pre-scale images to multiple sizes for efficient download and display across a range of devices, and compress images to reduce download sizes.
Comments
Post a Comment