One of the easiest ways to speed up your web site’s pages is via image optimization. Images – especially large, uncompressed or unoptimized images – are often the most load-intensive assets on a web page. Many a battle has been waged between designers – who want big, beautiful, hi-resolution images, and developers – who are tasked with creating a fast-loading site, and a conversion-focused user experience.Â
Google has long placed a premium on web pages that load fast and quickly deliver content to users of all device types and connection speeds. Page speed first became a desktop ranking factor in 2010, and became an official mobile ranking signal and ads landing page measurement more than 2 years ago.Â
The process of optimizing and serving the smallest-footprint yet highest-quality images has however, as with many web technologies, been impeded by a lack of browser support for all image types. The WebP image format, introduced more than 3 years ago, is arguably the best format for serving high-quality, fast-loading images (learn all about this image format here). But support across all browsers has taken time, and WebP is still not supported in Safari (the last holdout). Though with the release this Fall (possibly in October) of iOS 14, Apple has signaled it will finally support this image format in its web browser.
The Trouble with Troubleshooting
I ran into an interesting problem a few weeks ago. A client’s website images were not showing up on Safari (desktop & iPhone) browsers. In troubleshooting the issue, I spent a good deal of time going down various rabbit holes and implementing various fixes, each of which failed. I’m hoping this post will help you avoid the same fate, and more importantly, help you approach troubleshooting differently.Â
I’m a frontend developer, so I was looking at the problem with a very specific mindset – assuming that what I was seeing was a) a frontend problem and b) a Safari-specific issue. Which brings us back to the WebP format. While I know that Safari does not support WebP, we approach web site development placing a priority on providing a fast-loading user experience. So to ensure that every user has the best experience for our clients’ sites, we use the HTML5 element <picture> – using this element, we can serve the optimal image format supported by the browser being used by each visitor. This means that Safari gets a .jpg or .png version of an image; while Chrome and other browsers that support the format get the .webp version. To further optimize the page load experience, we use a CDN to serve page assets.
Extra eyes can often see things you do not.
After several unsuccessful attempts to recreate the problem on the client’s staging server, and triple-checking all the code, that all versions of images were accessible, etc. I reached out to a coworker for an assist. Pro tip: if you’ve spent a good amount of time testing and trying to run down an error – always raise your hand and ask a coworker or colleague to have a look. Sometimes a different approach to problem-solving is the quickest way to the solution.
Even though we had valid code in place, we discovered that the image errors were in fact, contained to WebP images displaying. Traditional auditing tools (Lighthouse, etc.) did not immediately surface this by the way. My coworker suggested the problem might be related to the CDN, because the image issue was inconsistent (clearing the cache on the live site worked, until it didn’t). After some searching, we eventually found a single support forum post that sounded like the same issue we were seeing. It was very specific, and specific to the CDN we are using – Cloudflare.Â
The backend problem, that was hiding images in the frontend.
 The problem turned out to be this: Cloudflare was caching the first call of each image. So if the visit was from Chrome, the WebP image was cached – and was served to the next Safari visitor, irrespective of the <picture> element definitions. And so of course – if the first call to an image was via the Safari browser, the .jpg would be cached and served to Chrome/Firefox/Edge browsers – negating the benefit of having the WebP format images available and specified.Â
In the end, the solution was to stop using the HTML5 element to serve the browser-specific image format, and instead to use Cloudflare’s WebP option (called “Polish“). Unfortunately, the caveat here is that you have to have a paid subscription to Cloudflare to use their image optimization options, which includes Polish.Â
Also important to note: if you created WebP images on your site’s server prior to using the CDN’s WebP handling, you’ll need to delete them all and flush the CDN cache – or the problem does resurface. In the end this took care of the issue – which should only continue to be an issue until iOS14 is released.
The main takeaways:
- Serving all masters is difficult. Beautiful design, fast-loading pages, and cross-browser support do not easily align.
- Finding ways to navigate the minefields requires not just in-depth knowledge of web development technologies, but how to troubleshoot and implement them in a variety of circumstances and environments.
- Sometimes the obvious solutions are not all that obvious – and a different perspective of the problem is needed.
I hope by writing this I’ve saved you a little frustration. And to the point about raising your hand when you’ve hit a wall with a problem – don’t hesitate to reach out and give us a shout if we can help you tackle any web development travails.Â