Get a better understanding of how photos come to life and the intricacies of their wild journey to your browser, all to keep performance high.
Along with the advent of the visual web, images have become ubiquitous in and around your content. From photos that convey meaning you can’t express in words, various illustrations that complement and establish the mood of your writing, to graphics and charts that portray information related to your text, the visual canvas of an image is a central part of the toolbox you get when trying to spread your message throughout the web.
This is why I firmly believe you can benefit from a deeper understanding of how these bundles of colored pixels get created, transformed and ultimately shown in a browser of your choosing.
The first part of this story is generally applicable to any image for the web. But since we at Pixelgrade have a knack for WordPress, I will also convey what happens with images from the moment they are uploaded in WordPress until ending up on the frontend of your site.
Image formats for the Web
The first important thing to get to grips with is the concept of image formats and how do the different formats for the web help or prevent you from reaching your goals.
When captured by the image sensor of a digital device (e.g. your smartphone or a DSLR), each photo initially exists in a raw format. This file holds almost all the data being generated by the sensor – a digital negative if you fancy film photography. All this data makes for huge image files; the primary purpose is to lose as little as possible information, not to save on space.
Beyond being this sort of absolute source of truth for the reality you’ve just captured, raw files are too complex to be used further, much less so on the web. That is why you take this format and convert it into formats better suited for the medium you are going for (like the web).
Note: Often, only professional cameras allow you to save raw image files. The rest of the devices convert them automatically into more common, more usable formats.
Most of the time you can easily deduce the format of an image from the extension of its file when seeing it in your Finder or Explorer (e.g. .jpg, .png, .svg, .gif, etc.) But why the many formats?
The web is a very diverse place with lots of actors all trying to do good (hopefully) by you, the user. From all the competing solutions trying to solve a particular image problem, in a given context, at a given time in the history of the web, the formats we have today gained traction and stuck around, some longer than they should.
One thing is clear: no image format will solve all problems. Choosing a specific one for your image implies accepting the compromises baked in its algorithm. To keep things “fun,” browser incompatibilities throw you the occasional curve ball.
On the web, the most used (and safe to use) image formats are JPEG and PNG. While both are good friends with your browser, they are quite different since they were created for distinct use‐cases.
On the one side, PNG is a lossless format in that it doesn’t lose visual details from the original image (at the same resolution), while JPEG has always tried to find the best balance between file size and visual fidelity, as a self‐respecting lossy format should do.
The differences don’t stop here. For example, PNGs have an alpha channel besides the RGB trio, meaning you can have transparency, while with JPEGs this is a no‐go since its algorithm focuses on file size efficiency and adding transparency into the mix cancels out many of its tricks. PNGs are the ones that provide you with more flexibility and control, but JPEGs are your workhorse, your it‐just‐works solution.
Note: Image formats, like the web, don’t stand still and new format proposals pop up all the time aiming at improving the performance and flexibility of older ones. For example, JPEG2000 is a smarter JPEG‐like format that allows for transparency or WebP from Google that promises to be the best of both worlds combining the advantages of PNG with the ones of JPEG, and then some – it can be lossless and lossy.
Ideally, we would all use uncompressed images and everybody would be happy. Except we are humans and we always want more than we have; performance is no exception. Images have a very big impact in the loading times of a web page, averaging over 60% of the data transfer (video is close by and a similar discussion is taking place on that front also).
Easy steps toward good karma
With the risk of repeating myself, let me point out once more that we are talking about getting your photos on the web. The steps that follow would be very different if you would be targeting print or video.
#1 — Choosing the format
In general, you should employ a JPEG‐first attitude: when transparency is not a consideration, go with a JPEG file with a decent compression ratio of 7 or 8 (the scale is from 1 to 10, 1 being the highest compression and 10 the least amount).
If you need transparency, then you clearly need the trusted PNG. Even though you don’t need to worry about losing details (being lossless and all), you still have a couple of optimization tricks you can employ from time to time, such as limiting the color palette (the default is a true‐color palette – PNG‐24, but you can try a reduced one for logos and graphics with few distinct colors – PNG‐8). Your image editing software should give you these options when saving as .png.
#2 — Chosing the pixel dimensions (resolution)
A crucial factor in determining an image file’s bytes size is the number of pixels it is formed from, the resolution. Think of a digital picture as a two‐dimensional matrix consisting of cells (pixels or px for short) arranged into rows and columns. An image 1000 pixels wide and 1000 tall represents a one megapixel image (1000x1000 = one million pixels).
Often the image captured by the camera is a large, high resolution one (20–50 Megapixels). While such dimensions are very useful for large prints, for the web it doesn’t make any sense.
For the web, the general principle to follow is this: the smaller the resolution the better. But how small is enough and where do we cross the line and end up with an unusable image?
It all comes down to future‐proofing our [image] content. In all likelihood, the layout (or theme if you are into WordPress) used to display your content is very likely to change in the future. The future layouts may use larger display sizes than your current one, or screen technologies will change and demand ever increasing resolutions (see retina displays).
It is wise to size our images with a reasonable margin and aim for “safe” dimensions – somewhere between 2000px to 3000px in either width or height should suffice. Remember to always aim for the smaller number.
It is key to remember that this is the original image that you upload – think of it as the source of truth. It will very rarely be displayed or loaded at these dimensions. Also, this image represents the maximum quality (or information) available from here on out. At any step, the quality may decline but never exceed this one.
Note: After deciding on your image format and dimensions, I recommend the use of a simple local app for optimizing images, such as ImageOptim for Mac users or FileOptimizer for Windows folks – they strip out any meta‐data in your files that is not needed for the web and do any optimizations that can be made lossless. Use one of these tools before uploading it.
#3 — Uploading your image into WordPress
Now we start to look at the specifics of working with images in WordPress (or in most other CMSes).
When you upload an image through the WordPress interface (e.g. when editing a post), it goes through a series of transformations. Depending on the needs of your theme and/or active plugins, from the original image (that is saved as it is) a series of thumbnails are automatically generated. These thumbnails are just miniature versions of your image of various sizes and aspect ratios.
The default behavior of WordPress is to keep the format and compression ratio of your original image when generating thumbnails, thus you can be sure that there is no loss of quality.
An important aspect of thumbnails is that they can be resized versions of the uploaded image (keeping the aspect ratio) or cropped ones (scaling and at the same time cutting certain parts to reach a new, desired, aspect ratio – for example a square thumbnail). Mainly your current theme decides how each thumbnail will be created, leaving little to no options for you to tackle.
#4 — Inserting your image into the content
Once the image is uploaded and thumbnails have been generated, you proceed to insert your image into your content – an article, a presentation page or a product you sell.
Before you hit that sweet Insert button, you get to choose (amongst other details) whether to use the original uploaded size (Full) or one of the thumbnail sizes (e.g. Large, Medium, Small) – go with the smallest one that suits your needs, but almost never with Full.
Besides inserting it into some textual content, an image can also be attached to a post or page in various forms: as a featured image, a hero or cover photo, part of a gallery, etc. – the image is becoming part of the meta information around content. In these scenarios, most of the time, the decisions regarding whether to use the original image size or various thumbnail sizes are made programmatically by your theme or plugins.
#5 — Displaying the image to your visitors
We are almost at the end of the rainbow, and it’s about time to make all those decisions count. Lets fire up some pixels on your readers’ screen.
Who does actually display the image? It is definitely not you or me. You might say: this is WordPress’ job! Strangely, it isn’t. WordPress doesn’t display images; its responsibility lies only in assembling the page source (the HTML code) requested by the visitor via his browser.
In that HTML code, you will find your image’s URL (usually as part of a <img> tag). Here is where WordPress’ responsibility ends – what comes next is literally out of its hands.
The question still stands: who puts your image in front of those starry‐eyed readers? Well, their browser, of course! Definitely not your browser running on this year’s hardware, with the power cord safely plugged in, a decent number of opened tabs and, last but not least, a broadband Internet connection.
Once WordPress has finished its job, your content (including images) is in the wild, all grown up and ready to face the realities of the web.
All jokes aside, the staggering diversity of environments your content will be displayed in should steer you towards having a more empathic attitude towards your readers. There are countless people (even in developed countries) that access your site on 3G or flaky 4G, or have modest laptops that don’t have a quarter of a battery charge to spare just to visit a site.
Even if we put Internet speeds and hardware aside, we are still not out of the woods. The best is yet to come if you can bear with me a little longer. If not, I totally understand – all these decisions and complexity need some space to settle in.
#6 — Inside the mind of a browser
What follows is an attempt at helping you better understand the inner “thoughts” of browsers as they tirelessly work to “paint” your images on other people’s displays. It is important in properly calibrating your expectations when it comes to images on the web.
So, once it receives the HTML, the browser gets busy and begins to analyze it with the sole aim of showing as fast as possible some pixels on the screen and avoid boring the pair of eyes in front of it.
When it encounters an image, it downloads the image file locally. Next, by interpreting the stylesheet(s) received for the page, the browser decides what are the actual screen dimensions it needs to display the image at.
Maybe it has “received” a 2000px by 1000px image but it needs to show it shrunken to 1000px by 500px. The browser is not fussy and gets cranking… It uses the big image and processes it on‐the‐fly to come up with a 1000x500 version of it to light up those pixels.
Since it operates under the pressure of boredom and available processing power, the browser needs to be extremely fast in this undertaking – the advanced algorithms used in your editing software or by WordPress when generating thumbnails have no place here. So the browser, more often than not, will cut corners and chose speed over quality – as in your images to be displayed at an unpredictable quality.
The same can happen when the browser receives a 500px by 500px image and needs to display it at 600px by 600px. Now it needs to “invent” some pixels – it does a surprisingly good job.
Besides these fundamental compromises baked into modern browsers, it is worth remembering that they are complex (open‐source) projects and they have their fair share of bugs and incompatibilities (here, here, and here).
You could safely think: why not insert or generate the exact image size needed? All these “browser problems” would go away! If only it could be so simple – just imagine all the sleepless nights we could save on this planet.
Remember that WordPress (aka the server‐side of your site) is the one generating the thumbnails when you upload your image. Neither you or WordPress can know beforehand the variety of sizes needed. And in a world of literally limitless display sizes (small or large smartphones, phablets, tablets, laptops, desktop displays, TVs, etc.) it would be pointless even to try.
If all this sounds scary, you are not alone. Thankfully, where there are problems on the web, there is no shortage of solutions.
In recent years, the concept of responsive‐images has surfaced to try and alleviate part of these problems and boost performance – at the cost of increased complexity.
The main idea is that WordPress shouldn’t offer the browser just one image URL, but several (usually most of the thumbnails that we have) and based on some rules we leave it to the browser to decide the best one to use – the principle being that the browser is the most knowledgeable of the reader’s context.
Still trying to boost performance, this time the perceived performance by people, the concept of lazy‐loading has gained momentum. This means loading (or downloading if you will) the images closer to the moment they are actually needed to be displayed (often times as one scrolls).
An unwanted side‐effect of lazy‐loading is the possibility of visual glitches, like images “jumping” into view due to the time difference between the detection and actually finalizing the transfer. As the saying goes, win some, lose some.
On top of these, some try to progressively load images by first transferring a tiny thumbnail and fetching the actual image behind the scenes – this aims at showing something as quickly as possible. Google has pioneered a new image format with this in mind (WebP), while Medium has taken this technique mainstream.
In a WordPress context, you already benefit from responsive‐images, while lazy‐loading or progressive‐loading are available through various plugins – the setup is not so straight forward and may require technical assistance.
As you have seen, when it comes to images the web is a wild environment and should be accepted as such if you value your good karma. The web is not the place of picture‐perfect! It is the place of as‐perfect‐as‐possible.