307 Fallback Strategy

Hello @featuremonkey and thanks for all these questions!

When ShortPixel CDN loads an image for the first time, it uses a redirect to the origin web server image to account for image processing (resize, compress) of device size: https://shortpixel.com/knowledge-base/article/148-why-are-my-images-redirected-from-cdn-shortpixel-ai.

ShortPixel CDN does not store images until a device accesses them. So there is no guarantee that origin web server image won’t be loaded for a user. This behavior is problematic if the origin server image is large and uncompressed and because of the latency cost to request from the origin server.

Yes, this is correct for the first load of each image, or in other words, until the CDN is “warmed up”.

I have a few questions based on the above context.

Why does optimization of image take so long on first load? WP Compress claims to load as fast as 7 ms, so how is ShortPixel running compression slower than them on first load?

I sense there’s some confusion between two separate concepts: image optimization and image delivery.

ShortPixel excels in image optimization. It doesn’t merely set a standard JPEG quality across all images, dubbing it “optimization.” Instead, each image undergoes more than 10 unique optimization techniques to reduce its size while retaining a visual quality that’s usually indistinguishable for the human eye. This process demands both CPU resources and time. However, we consistently monitor our system, and on average, an image gets optimized in approximately 2.4 seconds. For a hands-on experience, you can test this by appending “ret_wait” to the URL parameters on a medium-sized JPEG image.

On the other hand, we have image delivery. After our servers optimize an image, the CDN fetches it for global distribution. The final delivery to the end-user is typically swift, especially when the CDN already has a cached version of the image. The load time can vary, ranging from 10ms to 200ms, contingent on the user’s proximity to the CDN’s Point of Presence (PoP) and a reliable internet connection. Additionally, other factors, such as browser caching behavior and various CDN configurations, play a role.

The 7ms claim likely pertains solely to image delivery speed. In my perspective, this seems a bit optimistic, given the median HTTP request query time (excluding payload) observed among leading CDN providers. More details can be found at https://www.cdnperf.com/

How does optimization of image work? Is ShortPixel processing image for every device with even 1-px difference or is it using breakpoints?

It can work both ways, the plugin also has a breakpoint option in the settings, which isn’t active by default. When that option isn’t active, the plugin will calculate the appropriate image size based on the device screen size. In theory this process can reach 1px differences, but that would happen very rarely (it also depends on the CSS settings of the theme used and obviously, on the device screen size).

Why not srcset? What is the benefit of ShortPixel CDN when the user can put srcset in the HTML, then have a CDN store all srcset images and load that way?

SRCSET works great when it is configured correctly. However, most of the times that doesn’t happen and this is actually why our Adaptive Images plugin came to life! Themes that were not adding the correct SRCSET definitions, resulting in a worse experience for the site visitors than without (such as pixelated images in some cases, or huge images in others). Our plugin can actually correct such cases and it has options to use the existing SRCSET definitions when doing the replacements. There are other downsides of the SRCSET, such as an increased HTML size, lack of support for images that come through JS or JSON files and rather limited support for background images (where only recently image-set can be used to achieve a similar effect to SRCSET).

What is optimal 307 Fallback Strategy? When the image is requested from origin web server, it must be optimized (resized, compressed) still. But then doing that will make ShortPixel attempt to resize and compress an already resized and compressed image.

I’m not sure I understand this one. Why would the image already be resized and compressed? Of course, over-compression could occur if another image optimization solution would be used directly at the file level (storing optimized images in the Media Library), but that would not be necessary with our Adaptive Images plugin. And even if that’s the case, you can set the compression level to Lossless and then the images should not become over-compressed.

So, alternative to above is to use srcset with breakpoints, so when user requests image, it requests correct size?

This strategy still requires origin web server to resize and compress all of those breakpoints for first load. So, wen the origin server is doing that, why not use a CDN that stores those images and loads them from client via srcset instead of calculating “on-the-fly”?

Your suggestion points to another direction, where our plugin will change the way the web server would act and/or cache the content of the website. And this is pretty much what we have done with another plugin of ours, called FastPixel, hopefully available soon on the WordPress Plugin Repository. I encourage you to test it and let us know if it meets your expectations. It has many other features besides the image-related optimizations and hopefully, it clarifies the missing points.

Let us know if there are other questions, we’d be happy to answer them!

• This reply was modified 1 year ago by Pedro. Reason: Added a missing link

Thanks for the detailed response.

Why would the image already be resized and compressed?

pedro

The image would be resized and compressed on the origin server so when ShortPixel returns 307 on first load, the image isn’t large for that user. You stated that using the “lossless compression” with ShortPixel ensures that compressed images are detected, so no compression-on-compression issues occur.

And this is pretty much what we have done with another plugin of ours, called FastPixel,

pedro

Can I use “automatic cache warm-up” for solely images with FastPixel?

Does it store the warmed-up (“optimized”) images on the CDN before image is accessed by a visitor?

I encourage you to test it and let us know if it meets your expectations.

pedro

I ran the test on a website and using ShortPixel CDN with its configuration has a higher score ( 584 ms speed) than the FastPixel test website ( 1.0 second ) due to TTFB (683 ms on FastPixel vs. 38 ms on original) . However, cached page size of FastPixel is only 51.1KB on load, while the original website is 468KB on load.

Hello again

The image would be resized and compressed on the origin server so when ShortPixel returns 307 on first load, the image isn’t large for that user. You stated that using the “lossless compression” with ShortPixel ensures that compressed images are detected, so no compression-on-compression issues occur.

@featuremonkey

Ok, understood. Yes, this can be done indeed. While the original image won’t be resized or converted to next-generation formats, at least it will be smaller.

Can I use “automatic cache warm-up” for solely images with FastPixel?

Does it store the warmed-up (“optimized”) images on the CDN before image is accessed by a visitor?

I ran the test on a website and using ShortPixel CDN with its configuration has a higher score ( 584 ms speed) than the FastPixel test website ( 1.0 second ) due to TTFB (683 ms on FastPixel vs. 38 ms on original) . However, cached page size of FastPixel is only 51.1KB on load, while the original website is 468KB on load.

@featuremonkey

Please run the test 1-2 more times to ensure that all images/CSS/JS files used by FastPixel are not only processed but also cached in the PoP accessed by GTMetrix/GPSI.
We are aware that this is not ideal and we are thinking about finding a better way to warm up the cache.

If the results are still not as expected after retesting, please contact FastPixel support directly on the website you used for the test and we will be happy to help you.