IMAGEOPTIM CLI HOW TO

This section stops being about building websites and about building your site. If their experience is lessened by seeing loads of images loading later on in the page, then this technique has to some extent failed. What we want to achieve here is to load the smallest amount of images up front, but not make the fact that we are doing this obvious to the user. If I had my way we’d have shipped it and left for the day instead we need to determine when to load them on demand for the user. So now we have a really fast page albeit with no images. Once we wanted to load it we simply removed the class from the element.image-blocker What about background images? In order to remove those from the initial load we defined a css selector which we applied to all elements with background images. Of course, this only works for foreground images. For what it’s worth, we wrapped them in good old fashioned html comments but if I were to do it again I would use the data-src approach as it gives you an element to bind events to. There are a few ways to do this: many of the current Responsive Image polyfills send an image with an empty src attribute and include the actual src in a data attribute. Once we’ve worked out which are critical, we need to take all the other images off the page. Pocket) we still want them to be referenced within the page. If the Javascript breaks, or the user has turned it off, we still want these critical images to load if the user consumes the page via a different medium (eg. For this page, the critical images were the Logo and the Navigation Icon. If we’re going to load images with Javascript we need to work out which images are critical and which we will therefore include directly in the html. This will remain true until Resource Priorities become a legitimate standard. Once we have optimised the images there is very little else we can do without resorting to other loading techniques (read: Javascript). Define which images are critical to the page.

These are not simple to set up as you will require a server side solution to handle the content negotiation (not all browsers accept them), but there are significant gains to be made particularly on large images. It’s also worth mentioning at this point that there may be solutions for you outside of these traditional approaches, by using new image formats: WebP and Jpeg-XR. SVGO or grunt-svgmin can help you with this. Optimising SVG is also worthwhile as they’ll often be output with additional meta data. I would always advise running your images through all three – and luckily there are plugins that have been built to do this for you: ImageOptim-CLI & grunt-imageoptim. ImageAlpha is a tool for losslessly optimising PNG files which is also worth using. ImageOptim works for both JPEGs and PNGs, though for JPEGs I generally find better results with JPEGMini. For JPEGs that meant JPEGMini – a paid for, but fantastic, app. Then we ran all our images through optimisation tools. Some images required multiple variations dependant on viewport size. Optimise all the image assets.īefore we began optimising the images with tooling we started back in Photoshop, tweaking compression rates and image dimensions to find the best combination (or combinations). The techniques that worked for us may not work for your site but the broader concept of taking a step back and searching for possible optimisations is something which certainly will. Then we had to work out what we could load on demand for the user and how we could anticipate their actions. These took us quite a long way there and will work for every single site. Below is a comparison of the site before and after we optimised it:

IMAGEOPTIM CLI HOW TO

Almost all of the performance problems we faced stemmed from the amount, and the size, of the images we had to serve and there was no simple answer for how to offload them. When I got the design for the recent iteration of the Lonely Planet homepage I was initially skeptical of how we could make it performant given the abundance of high resolution images. These solutions alone won’t automatically solve the original problem of image-rich sites though. mDot sites are always believed to be more focused and lightweight and, whilst that is often the case, part of the reason for this perception is that many desktop sites are overly bloated to begin with.Īs an industry we’re pretty good at tackling these challenges and the discussions around responsive image and High DPI image solutions rage on towards a hopeful conclusion. Responsive Web Design gets a hammering within the performance field for producing heavy sites – with images usually taking the brunt of the blame.

Imageoptim cli