Skip to content
PicPerf

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.” Right from the beginning, browsers & PicPerf’s CDN will be told to cache that image, even though it technically hasn’t yet been optimized. This is good. Reusing an unoptimized image you’ve already downloaded is more performant than freshly downloading an optimized one.

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. The image is transformed to modern formats like WebP and AVIF. Only the lightest version out of these formats is saved for future use.
  3. 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.
  4. 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.”

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. This is one decision that sets PicPerf apart from other services. It’s aggressively opinionated.

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-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. | . | | 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. |