Statistics keep repeating to us about the strong correlation between a drop in the page load speed of a site and an increase in the bounce rate with a decrease in conversion. I won't discover America if I say that the site is slowed down by a bloated payload (with poorly optimized images and redundant HTML). This forces the server to do unnecessary work. A huge layer of this work is associated with the problems of image optimization.
Correctly selected images, by themselves, attract attention well and help to increase conversions, spread information on social networks and other visitor interactions. Therefore, they continue to be actively posted on web pages. But how this affects the loading speed of these pages is an interesting question. It all depends on the optimization strategy.
I think that strategies based on the thesis that images are static content are not very effective (I will develop this idea and give arguments over the course of the article). Mobile devices now account for a large share of Internet traffic, but there is a problem: these devices have different sizes, screen resolutions, operating systems and application software (for example, browsers). How to make a web page quickly (!) And correctly load on any platform and look the same at the same time?
In this article, we will reduce the solution to image optimization at the development stage, project assembly and / or at the stage of maintaining the finished site.
True, some optimization strategies can significantly complicate the design and development process, as well as add maintenance headaches. I am generally silent about the growing waste of resources and time during assembly. There are many methods and tools for optimizing images. But some of them are not easy to use without automating complex and repetitive processes. We will look at four strategies and find out which one allows you to better automate and make flexible (dynamic) image optimization for different devices.
We will test four strategies. First, without optimizing the images, we will simply feed a simple adaptive code to the server with all the breakpoints and image options for them. Then we will look at optimization at the build stage, where special tools and services help prepare the necessary variants of images. The third strategy is run-time optimization: before submitting the page, an automated tool or online service applies optimization to the image according to a given template or based on information from the browser. The last strategy is to use information about the device and browser obtained through other specialized services to generate and deliver optimized images (I will definitely talk about them at the end of the article).
Attention! Spoiler!
A device-specific image optimization strategy will give the best results. In this article, we'll look at the pros and cons of implementing each strategy and their impact on the web application development process.
The ultimate goal of image optimization is to improve the loading speed of web pages. I use Google PageSpeed Insight to audit pages . It allows you to easily analyze the effectiveness of individual strategies. As I wrote above, we will be auditing mobile pages.
Strategy # 1: responsive code without optimization
I took the standard responsive code without using any image optimization: the browser, based on the screen size, simply selects a more or less suitable option from a set of identical images of different sizes. There are several breakpoints in the code for images of different sizes. They are determined by the display sizes of mobile phones, tablets and desktop computers.
But here again the problem: there are thousands of such configurations, and every day there are more of them. We have to add more and more breakpoints. However, this requires more development time, leads to an overgrowth of the code base and, in the future, to confusion and errors.
Here's an example with four breakpoints in the srcset attribute:
<img srcset = "image-1920.jpg 1920w,
image-1280.jpg 1280w, image-640.jpg 640w, image-480.jpg 480w" sizes = "(min-width: 36em) 50vw, 100vw" src = " image-320.jpg "alt =" Responsive image syntax "/>
Now think about how much of this code you can have in your project ...
Moreover, images for each of the listed sizes need to be created separately. This takes time, as well as additional storage space.
You can also implement responsiveness with CSS media queries. Alternatively, you can use the new and elements
<source>
, where <picture> is a container for one or more <source & gt elements and one <img & gt element. However, all these approaches do not allow you to create scalable solutions.
Finally, these approaches do not take into account the specifics of the device. Every time you write code like this, you are just trying to guess which breakpoints to use and what image sizes you will need. In addition, there is no guarantee that the options you have chosen well today will work tomorrow.
Benefits:
- no need to buy software or pay for a subscription to additional software or services;
- It is relatively easy to write responsive code based on a well-documented standard.
Disadvantages:
- additional space is required to store images of different sizes;
- additional time and effort is required to implement such “adaptive multivariance”;
- the growth of the code and the complexity of its maintenance;
- this code does not work the same in all browsers;
- no reliance on device context;
- Scaling requires a separate CDN (Content Delivery Network);
- it takes a lot of time to finalize for new devices, image formats, and so on.
Test results
Tests show that I chose not the best formats, and even without compression. And my images are too big.
Strategy # 2: Build-time Optimization
One way to make it easier to create image variations is to use specialized image editing or compression services such as Kraken , Compressor.io , mozjpeg, and squoosh.
You upload your images and the service processes and optimizes the images on its server. Then you can use the optimized images in your project. You can set standard or custom optimization settings: lossy or lossless compression, resizing, downscaling, and so on. Some services can provide several versions of the same image at once in accordance with the required dimensions.
What if you go for broke and use the Grunt or Gulp builder to optimize your images ? To do this, it is enough to assign the appropriate tasks to be performed during the build. Image processing itself can be handled by the imagemin js package .
It can be installed via npm or used via the command line interface. It is a modular solution with plugins for compressing various image formats: for example, imagemin uses mozjpeg for JPEG and pngquant for PNG compression. Setting image optimization options is similar to many SaaS tools.
When implementing this strategy, the biggest burden falls on the developers. They must first automate batch processing of images with tweaking of third-party tools, and then periodically update their code to support new image formats.
Benefits:
- image optimization is performed on a foreign server;
- services process images quickly enough;
- optimization control can be built into your development and deployment workflow;
- services have a convenient interface for setting optimization parameters;
- many free tools (or free plans) with fairly rich functionality.
Disadvantages:
- again it takes a lot of time to implement adaptive multivariance;
- there is still no reliance on the device context (size, screen resolution, and so on);
- still needs space to store many images;
- still needs a CDN;
- even more man-hours are needed to further implement integration with third-party products through the API;
- every time new variants of images appear, you also need to run the entire optimization process for already existing variants;
Test results
In terms of points, it is slightly better than the first strategy. Complaints about compression have calmed down, but about formats and too large sizes - they remain.
It is important to note that the total payload has dropped to 1.4 MB. This is 80% less than a solution without a strategy gives us, and 50% less than a strategy with an adaptive code.
Strategy # 3: Run-time Optimization
When we visit the page from a certain device, the browser sends a request with an HTTP header to the server. The header stores information about the access context and image formats.
Run-time optimization runs on the server, just before the response (content) is sent to the browser. The goal of such optimization is to reduce the transmitted amount of data in order to speed up the loading of the web page.
For example, the header from the Chrome browser looks like this:
image / avif, image / webp, image / apng, image / *, * / *; q = 0.8
With the advent of Client Hints, you can transfer more information in additional fields, for example, DPR (device pixel ratio, "pixel density", a value similar to the resolution) and Viewport-Width (screen width).
Client Hints is a protocol by which the browser, in the HTTP request header, can tell the server what type of content it would like to receive. Client Hints add additional fields to HTTP request headers containing information about the browser. One of the key features of this protocol is to inform the server about the size of the images the page needs.
Using this data, run-time optimizers determine how to compress images and in what format to output them. However, for flexible resizing, you still need to manually implement adaptive logic based on breakpoints.
These tasks are performed by SaaS optimizers such as Cloudinary and imgix. These platforms usually have an automatic optimization option when the image server or proxy decides how best to optimize the content. But you can also customize the optimization parameters yourself using the API (usually using simple URL parameters).
ImgIx is a CDN (Amazon CloudFront) add-on that allows real-time image processing before adding to the cache. ImgIx provides all the necessary functionality for image processing, as well as a number of additional functions, for example, Monochrome, Blur, Halftone.
Often such services can serve as CDNs as well. And Cloudinary has its own DAM (Digital Asset Management) system.
Everything is fine, but such optimizers cannot yet analyze the device context. The HTTP header could convey user agent data and signal that the page has been opened, for example, from the Chrome browser on an Android device. But this is not enough. Nothing is said about whether it is a phone or a tablet, and what are its diagonal, screen resolution.
Images are also stored on the platform's servers, not on your own resources. However, you usually have a fixed quota of disk space with some margin in case of new images.
Benefits:
- very little effort is required to optimize images;
- run-time CDN ;
- , , DAM ;
- URL;
- , /
- , ;
:
- , ;
- src , , -;
- - ;
- usually works slower on the first requests, because the service has to get an image from a third-party source and then optimize it with no cache at all.
Test results
The claims about compression and formats have almost disappeared, but you can still
find fault with the size.
Compared to the previous two strategies, the payload is down 88%. Now it is only 897 KB.
Strategy # 4: Optimize for Device Context
As in the previous strategy, we need a service with an image server. It should use request headers for dynamic context sensitive optimization. For example, a browser can declare support for AVIF via Accept in an HTTP request. Then the service will think about what kind of image it should display in the AVIF format. And this is where the "magic" begins.
For example, consider the ImageEngine service . It is able to get full information about the device from the access context using the WURFL js library ... In addition to the browser and OS, it can determine the exact make and model of the device, as well as screen characteristics (resolution, PPI, and many others). It also supports Client Hints, including the save-data header, which not all services work with.
This allows such an optimizer to offer more relevant image options for all occasions, while ensuring the optimal balance of payload and image quality.
These services also use CDNs to speed up image delivery and improve cache hit rates. This approach has a huge advantage in the mobile segment of the Internet, since there are so many devices with different screen parameters.
This strategy requires almost no code completion. It's easy enough to update the src attribute values of the img tag by linking them to the optimization service. And that's all.
Benefits:
- requires minimal effort in development and maintenance;
- can be effectively configured and forgotten (when using automatic optimization settings);
- automatic and manual optimization of images using directives in the URL;
- the greatest possible savings in image payload while maintaining maximum quality;
- you can implement and start using this strategy in a matter of minutes;
- the optimization service usually offers the best price / bandwidth ratio;
- no overgrowth of the codebase: no adaptive code and no breakpoints.
Disadvantages:
- src , , - ( );
- ;
- , , .
Now Google PageSpeed Insights is happy.
Most indicators have improved significantly. The service automatically started using new image formats (for example, AVIF with optimal compression according to the access context). In addition, for different screen sizes, images automatically change length and width, and are also scaled.
Our total payload has decreased by about 95%:
And you will be happy
As you can see, all strategies have their pros and cons. There is no doubt that image optimization services, especially those based on device context, have an edge.
The third and fourth strategies will allow you to rationally build the development process with minimal problems at the stage of creating, maintaining and storing images. Moreover, you won't need to write convoluted and non-scalable responsive code. Image optimization will work reliably and flexibly to meet new business requirements and needs.
Don't worry about losing control over your image optimization settings, because you can make your adjustments using APIs or simple URL parameters.
Of course, you will have to pay for such a pleasure. But the service representatives assure that inexpensive tariff plans are provided for individuals, as well as for small and medium-sized businesses.
Cloud VDS from Macleod are great for website hosting.
Register using the link above or by clicking on the banner and get a 10% discount for the first month of renting a server of any configuration!
