There are many things that you can do to serve optimized images online to your site visitors. You can take it to a level of extreme care and granularity, which will take much time away from you. Or you can follow simple steps, which we outline in this post. Here we’re looking for the most efficient path with the least amount of effort to optimize. But first, let’s define what optimizing images means for the purpose of this article: serving your site visitors a good quality image regardless of the device, consuming the lowest amount of bandwidth, hence making your site fast and the page load inexpensive for you and for them. After all they pay for bandwidth to download it, and you pay for bandwidth to serve it.
Before you start writing an article in your content management system (CMS) and include images, you need to acquire them and edit them. When saving an image you can choose various sizes, and various formats. If you host a photo site and you will sell images in the highest resolution, then you are in the unique situation of wanting the absolute best resolution and quality you can get. So you will save and get ready for publishing with the highest res. In other cases you want to serve a good quality image to someone viewing it on a desktop, potentially with a nice and big monitor. At the same time you may not need the full native quality. In that case you can use JPEG options and play with quality settings. Experiment until you find what looks good to your eyes and whether you want full HD, 1920 x 1080, or 4K, 3840 x 2140 pixels, or less. Take a look at the size of each photo and determine whether your users really need to see images that big. Even if later on the image gets scaled it may get uploaded in your CMS in the native size, taking storage space. In many cases you might want to measure the width of your desktop theme, which, unless the image is opened full screen, is the highest size it will be served to any user. For example if your desktop theme is 900px wide, you could save images at 900px width with your choice of JPEG compression. Before publishing is the time you can change the JPEG compression settings and how much space a given image is going to take, natively.
Sizes to save in the CMS
When uploading images to your CMS you have the ability to choose which sizes it will store them in. WordPress provides 3 dimensions that you can edit. This means that if you store an image it will create 4 distinct copies of that image: a large, a medium, a thumbnail, plus the original image size you are uploading. This is handy: if your theme maker coded your theme correctly, it will serve the medium image to mobile users, the large image to desktop users, and the thumbnail if some widget calls for that size.
Now once we save an image WordPress puts the 4 copies on our server. For the purpose of this article we changed the large size width to 700px, and used a native image that was 768px wide. Let’s take a look at the uploads folder on the server:
Requirements for display list evolving requirements, such as the featured image being at least 696px and the site logo being on a white or clear background.
Data and metadata
Once you are writing your article or post, you can edit the image as well, the way you want it to show in that specific post. You can change the size – but warning: if you change the size at this point it may serve an image bigger than it will display it. If that’s a small difference it’s OK. But say you upload a full HD photo into your post and then change the size to 200px in the post image editor: your users will need to download the full HD image, then their device will shrink it down for display. This is very slow and ineffective, and search engines and speed test analyzers will warn you about it. Essentially this consumes bandwidth with no benefit to the end user: the size is set to 200px for all devices, with that option. Changing size of images inside the post editor is not ideal and must be avoided if possible.
You’ll notice in the screen shot, that you have the ability to set what happens to the image: should it point to a URL? Open the image URL path? Linking options provide flexibility. You can also provide the metadata for the image, which some social networks and tools use as description, like Pinterest. At this point, you have images that are sized reasonably for your use case, and that are sized in the CMS so it can show the larger or smaller version efficiently, depending on the device type.
If you are using a cache or a CDN, like CloudFlare, these tools offer you options to further optimize images. In that case the CDN will scan your site, make copies of images on its servers, put these copies all over the world (that’s what a CDN does and what makes your site faster by locating files geographically closer to users), and it will make these images also lighter in size while keeping equivalent quality. Pro customers of CloudFlare now benefit from automatic JEPG to WebP image conversion. CloudFlare will serve the newer WebP format to users without you having to convert any image yourself. Last, your server has an option to compress content using GZIP. Just like a zip file is smaller than its standard format, GZIP compresses content before it leaves your server. Smaller data packets travel over the internet, then the browser of your user’s devices decompresses the content and shows it to them. Enabling GZIP is another easy win, not just for images, for all content your server is sending.