What to Expect

PicPerf handles your images in a way that prioritizes a thorough optimization, while also balancing a visitor’s experience while new images are optimized for the first time. Here’s some more detail on how that process works.

Optimizing a Fresh Image

When an image is first requsted through PicPerf, you’ll immediately get your original, unoptimized image back. There won’t be any annoying delay you have to deal with as an optimization occurs in the background.

You can verify first request using the browser’s network tab. For that fresh image, you’ll see the X-Picperf-Source response header be set to “origin,” and the Cache-Control header contain a value of “no-cache, no-store, must-revalidate.” This particular caching strategy ensures that the next time a visitor comes to the page, they’ll get the lighter, optimized version.

In the background, however, here’s what’s happening.

1. Basic lossless optimizations are performed on the image. As a part of that, all unecessary metadata is removed, leaving just the data required to render it to the page.
2. A copy of the optimized image is stored with a best-in-class cloud storage provider for later retrieval if all other caches have gone stale.
3. The image is placed in a CDN network cache for incredibly fast access.

Subsequent Requests to an Image

After that initial optimization has been performed, the visitor will always get back the lighter, faster, cached version of the image. Again, you can verify this is by the response headers, which will indicate that it was served from either “storage” or “cache,” and also show the size ratio of the returned image compared to the original version. For example, the following headers confirm that the image came from the CDN cache, and is only about 14% the size of the unoptimized version.

When these images are retrieved, it’s given Cache-Control header set to public, max-age=31560000, immutable. This is an intentionally aggressive value that will all the image to be cached for up to a year on a user’s device, without any revalidation requests. What all this means: for the average user, revisiting a page with the same image will be extremely fast, and result in less data being sent over the wire.

Keep in Mind

• These optimizations will not impact the filename — only the mime type of the image itself. So, while you see .jpeg at the end of your image, a different format is being served. You can verify the actual image format being served by checking the Content-Type response header.
• The browser will not recieve a different image format if the original is the most optimal. Sometimes, converting an image to .webp actually increases the file size. PicPerf only returns the lightest version, no matter what the format. It usually means .webp or avif is returned, but not always.
• Due to the aggressive caching strategy, if you need to update an image on a page, it’s best to use a different file name.

Notable Response Headers

You can determine important information about how your images were served by inspecting the response headers in your browser’s developer tools. Here are the headers worth your attention.

Header	Values	Description
X-Picperf-Optimization	full	The level of optimization that took place. Currently, this is only full, but I’m exploring offering a less aggressive, light version as well.
X-Picperf-Source	cache, storage, or origin	From where the image was served. The fastest is cache, and then storage. New images will be served from origin while the optimization takes place in the background.
X-Picperf-Ratio	number between 0 and 1	The size ratio of the optimized image in comparison to the original. For example, a value of 0.191 would mean that the new image is approximately 80% smaller.
Cache-Control	public, max-age=31560000, immutable	Indicates the image can be cached on a user’s device for up to a year, and that there’s no need to check in for a newer version until that time as passed.