Optimization of images in a site

According to many feedbacks, most SEOs and website editors think that images are well optimized. However, this is rarely the case, especially in e-commerce. Here are the important mistakes you should avoid…Optimizing an image in an HTML page, you probably know how to do it, but how to make sure that all the images included in all the pages of the site are perfect? There are no broken, ultra-large or too heavy images?

Images that degrade speed

This is clearly the main problem: some images take too long to display, which slows down the entire page loading process.

For example, an ecommerce site had photos on about ~15% of its product sheets without any compression work. As the images were quite large, it could be seen on the download time of the image files. The customer did not realize this because with the number of products (~1600), he “could not test everything”.

The solution was quite simple: resize the images too large, and then pass all the images in a compression tool. It is “enough” to clearly identify the faulty images…

The RM Tech appendix, which lists the “faulty” images, allowed him to “immediately identify the wrong images” and “prioritize the resizing and compression work”.

Large images for thumbnails

Here is a classic case of listings pages, both in Prestashop and other ecommerce product categories as well as in WordPress sites. The problem comes from the theme that did not plan to create thumbnails (a reduced size image obtained from the reference image of an article or product).

The result: you end up with 20 to 50 images to load into the page, sometimes all as heavy as if they took the entire width of the page. Even with lazyloading it’s a disaster. To find them, you have to compare the sizes imposed in the attributes of the IMG tag in HTML (or after rendering but it is more complex) with those of the image file.

This is what RM Tech does, even going so far as to calculate the ratio of the number of pixels.

External images in HTTP

You have switched your site to HTTPS, well done. You thought about switching to HTTPS all your page URLs, CSS and JS scripts, and even your images: congratulations again.

But what happens quite often according to these feedbacks is to forget that you sometimes use images hosted on other sites. If they are in HTTP, then the user’s browser takes great pleasure in scaring him with broken padlocks and other red color codes.

Pages too heavy with too many images

This is also a fairly common case: you reflect mainly frame by frame. Each one is correct, not too big, not too heavy, well compressed. Cool! Cool!

But how many images per page do you put together? If there are too many, it ends up overloading the whole thing… OK, lazy loading does wonders, but there are limits despite everything…

The importance of Meta Description for natural referencing