I can’t seem to figure out why this is weirdly occurring. On a PC, regardless of browser, I’m able to retrieve my site fine (with the images, lazy loaded). The site is https://rossirovetti.com . However, on an IOS device (specifically my iPhone XR, latest IOS rev) on any browser (Safari, Chrome, Firefox, Opera Mini) it’s not showing the 's at all.
It appears to be something goofy with the TLS/SSL since I did some debugging on my phone and that’s what’s coming up with an error when trying to look at an image (though my development kit is limited there). What am I doing wrong? (upload://jqmI7pipf8OLQ6Y3wEpGWhmtgC.jpeg)
Like @Cyb3r-Jak3, I also can see the images loading fine on Safari for iPad and iPhone.
However, if this is an intermittent issue that happens (or stops happening) after a cache purge, you may want to check if your site has any image optimization tool that generates images in the WebP format. This format is not available on Safari for iOS (and therefore on other iOS browsers, which are just a shell for Safari).
If that’s the case, you just either turn off caching of image files via page rule, or disable WebP at the origin. You may then enable Polish (Pro plan and higher), which will convert to WebP and send it only to browsers that can handle the format.
thank you@cbrandt and @Cyb3r-Jak3 … I still haven’t (quite) ruled out anything else, but it appears that rendering WebP at the origin was suspect. What I learned from this thread is that the other browsers are shells of Safari on iOS (…so this is where I was scratching my head the most, since every browser on my iOS devices were giving me the same issue). I was assuming that Chrome is Chrome is Chrome - not realizing that it has to rely on Safari to work (thanks again for that insight, @cbrandt )
I also verified everything was working with an iOS device with saucelabs.com (helpful) but I couldn’t narrow down, even after a cache wipe, why my own iOS devices weren’t working. Instead of trying to work uphill I forced our origin to render JPEGs instead, and this seems to fix it.
What I still can’t figure out is why this would seemingly an issue limited to my devices only (again, even after a cache flush)… very weird - it should be broken on every iOS device or simulator. But when something is fixed, I won’t complain, so I’ll move onto the next step on my to-do list…
When you mix the fact that WebP is not supported on iOS (there is a note here that points to some good news on that front, but hey, that good news is from 2016 and it hasn’t materialized yet!) and the way Cloudflare handles caching at the edge, it can perhaps help you solve the puzzle.
Cloudflare will only cache an asset that’s been requested at one of its data centers, and only there for the duration of the Edge TTL (sometimes less). So you can easily imagine a situation where, if your origin has an optimization plugin that generates WebP based on the visitor’s user agent, different versions of the HTML will be cached by different CF data centers.
For instance, you visit your site with Chrome for desktop, it accepts WebP, an HTML page with links to images in that format, and the images themselves, are cached at the CF data center that proxied that visit. You go back there with iOS and bam! no images to display.
Another visitor from a different location (or simply using a different ISP) may visit your site though another CF data center, the HTML hasn’t been cached yet, and the device doesn’t support WebP, the origin generates a slightly different HTML, with JPEG instead of WebP images. This is probably why @Cyb3r-Jak3 and I were able to see the images on iOS when you couldn’t. We got to your website through different Cloudflare data centers!
So it wouldn’t be enough to wipe your own cache, you’d need to purge the cache from Cloudflare each time, which is obviously not an ideal setup. The alternatives are either to stop WebP generation at the origin or to not proxy images through Clouflare. Since Cloudflare sits between your visitors and your origin, it can distinguish between visitors UAs and serve the appropriate image format, but for that you’d need to enable Polish, available on Pro Plan or higher. Then Cloudflare will generate and cache WebP images for the use of browsers that do support it.
Thank you again, @cbrandt - that makes perfect sense!
I do a bit of a hybrid technique, too. I utilize imgix.com’s image manipulation/resizing/etc/etc api (though they also have a CDN built in too, but it sits on fastly’s CDN which isn’t as fast as CF’s at various points I’ve tested, so I don’t use them for the CDN component). It’s indeed similar in a way to CF’s Business Plan which has image optimization capabilities too (meaning I don’t have to pre-generate thumbnails or anything), but I’d already spent so much time coding against imgix’s API I just use CF’s Pro plan to optimize what imgix’s output is for each image. What I didn’t realize until your post was that part of this optimization that imgix does is straight-up next-gen picture formatting (like delivering a WebP for a JPG on the fly if it’s a Chrome browser). It does this automatically unless it’s shut off.
So what I was doing was first testing (and of course I tend to use Chrome) the website without CF. Then I’d throw the switch on CF, allowing it to cache everything. Then I’d re-test it with Chrome. Since (you were exactly correct) my edge point had - at that moment in time - configured everything to be WebP from the time it began at imgix’s on-the-fly optimization to the time it hit my network, it was breaking my iOS devices. However, as you pointed out, since it wasn’t at the edge of the network to your devices, it was fetching the image for the first time and thus obtaining a JPG result.
Talk about crazy. But after I read your post, I simply turned off the auto-optimize-format option on imgix, which allows me to still use the scaling tools and all of the other image manipulation functions but it will consistently deliver it in JPG. Then (since I’m on the Pro plan) CF’s Polish then takes over to determine if it should be a WebP or JPG depending on the User Agent header (I’m guessing). Since then it’s worked flawlessly.
