307 Fallback Strategy | WordPress.org

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.

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?
• How does optimization of image work? Is ShortPixel processing image for every device with even 1-px difference or is it using breakpoints?
• 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?
• 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.

  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”?

  What am I missing here?