Pregenerate images

Overview

.avif and .webp are pregenerated for optimized images.
.progressive.jpeg is pregenerated for Progressive JPEG images.
.blurhash.png and .lqip.png are pregenerated for placeholder images.
.metadata.json is pregenerated for image metadata.

Performance optimization strategies always depend on the environment. Choose technologies based on observed user environments and characteristics. We recommend using .avif and .webp for optimized images, and .blurhash.png and .lqip.png for placeholder images in modern browsers.

Why pregenerate image files?

When a user uploads an image to Snapkit, optimized image formats, placeholders, and metadata are generated within 10 minutes. The reasons for this are as follows:

Image conversion is not cheap. If the conversion time is long, it can cause long loading times and degrade user experience. Especially since format conversion is expensive, generating and storing frequently used formats in advance can solve these issues.
By placeholder images, you can display them before the original image is loaded. If placeholders are not pregenerated, the time to generate the placeholder may exceed the time to load the original image, making the placeholder meaningless.
To obtain image metadata, you would normally need to install additional image processing libraries. By storing metadata, it can be used whenever needed.

AVIF and WebP

These image URLs look like this: https://cdn.snapkit.studio/<your-organization>/image/gen/<image-id>/<width>x<height>/<image-name>.avif|.webp

*.avif: AVIF is recommended for web performance. It has a smaller file size than WebP, but browser support is more limited.
*.webp: WebP is recommended for web performance.

Progressive JPEG

A Progressive JPEG is a type of JPEG image that loads in multiple passes of increasing detail, rather than loading from top to bottom in a single pass. This means that when a user first loads a Progressive JPEG, they will see a low-quality, blurry version of the entire image almost immediately, which then gradually becomes clearer as more data is downloaded. This improves perceived loading speed and user experience, especially on slower connections.

You can access Progressive JPEG images with URLs like:
https://cdn.snapkit.studio/<your-organization>/image/gen/<image-id>/<width>x<height>/<image-name>.progressive.jpeg

*.progressive.jpeg: A JPEG image encoded in progressive mode, allowing for faster initial display and smoother visual loading compared to standard (baseline) JPEGs.

For more information, see What is a Progressive JPEG?

What image format is better?

Choosing Between AVIF, WebP, and Progressive JPEG for the Web

When optimizing images for the web, the choice between AVIF, WebP, and Progressive JPEG is crucial. Each format offers distinct advantages and trade-offs in terms of file size, quality, compatibility, and loading experience. Below is a practical comparison to help guide your decision.

AVIF: Pros and Cons

File Size: Up to 50% smaller than JPEG, resulting in significant bandwidth savings and faster load times.
Image Quality: Superior quality at lower sizes, supports transparency (alpha channel), HDR, and other modern features.
Browser Support: Supported by most modern browsers (Chrome, Edge, Firefox, Safari), but not available in some older browsers or special environments.
Decoding Performance: Can be slower to decode than JPEG/WebP, and may increase CPU usage on low-end devices.

WebP: Pros and Cons

File Size: 25–35% smaller than JPEG, though typically larger than AVIF.
Image Quality: Better than JPEG, supports transparency.
Browser Support: Widely supported in all major browsers except some legacy ones (e.g., Internet Explorer).
Decoding Performance: Similar to or slightly slower than JPEG, but faster than AVIF.
Implementation: Requires conversion tools, but tooling is mature and easy to integrate.

Progressive JPEG: Real-World Limitations

Progressive JPEGs are easy to generate and can improve perceived loading speed by displaying a blurry, full-image preview that sharpens as more data loads. However, they are not widely used on the modern web due to several key drawbacks:

🚫 1. Browser & Program Compatibility Issues

Not supported in some older browsers (e.g., IE8 and below) or certain image viewers.
Ensuring compatibility may require fallback logic for all user environments, increasing implementation complexity.

🖥️ 2. Increased CPU & Memory Usage

Decoding a Progressive JPEG involves multiple passes, resulting in 2–3x higher CPU and memory usage compared to Baseline JPEG.
On low-end or mobile devices, this can actually slow down initial loading and degrade performance.

📉 3. Limited File Size Savings

Typically only 1–3% smaller than Baseline JPEG.
For small images or thumbnails, progressive encoding may not be applied or have any noticeable effect.

🔬 4. Uncertain User Experience Benefits

The “gradually sharpening” loading effect does not always improve UX; some users find the blurry preview distracting or uncomfortable.

Summary Table

Feature	AVIF	WebP	Progressive JPEG	Baseline JPEG
File Size	Very small (up to 50%↓)	Small (25–35%↓)	Slightly smaller (1–3%↓)	Standard
Image Quality	Excellent, modern features	Excellent, transparency	Standard	Standard
Initial Load UX	Fast, supports alpha	Fast, supports alpha	Blurry full image, UX unclear	Top-down rendering
Compatibility	Modern browsers	Modern browsers	Some legacy tools/browsers unsupported	Nearly universal
Decoding Speed	Can be slow, CPU ↑	Good, faster than AVIF	CPU/memory ↑	Fast, simple
Implementation	Needs conversion tools	Needs conversion tools	Simple, no extra tools	Simple

✅ Conclusion & Recommendations

AVIF: Offers the best compression and quality for modern browsers. Use as the primary format where supported.
WebP: Ideal fallback for environments where AVIF is not supported; easy to implement and widely compatible.
Progressive JPEG: Consider only for large banner images or slow network scenarios, and always test for your audience. For most use cases, the benefits are marginal and may not justify the CPU cost or compatibility issues.
Baseline JPEG: Remains the safest fallback for universal compatibility.
For most web services, a combination of AVIF + WebP + Baseline JPEG (as fallback) is recommended, based on your users’ browser and device statistics.

Placeholder Image

These image URLs look like this: https://cdn.snapkit.studio/<your-organization>/image/gen/<image-id>/<width>x<height>/<image-name>.blurhash.png|.lqip.png

*.blurhash.png: BlurHash is a placeholder image that is displayed while the image is loading. (Snapkit uses BlurHash )
*.lqip.png: LQIP (Low Quality Image Placeholder) is a placeholder image that is displayed while the image is loading.

Metadata

*.metadata.json: Metadata for the image.

For example, the metadata for a jpeg image looks like this:


{
  "placeholder": {
    "lqip": "data:image/png;base64,iVBOR...",
    "blurhash": "data:image/png;base64,iVBORw0K..."
  },
  "format": "png",
  "size": 960860,
  "width": 1024,
  "height": 1024,
  "space": "srgb",
  "channels": 3,
  "depth": "uchar",
  "density": 72,
  "isProgressive": false,
  "isPalette": false,
  "bitsPerSample": 8,
  "hasProfile": false,
  "hasAlpha": false,
  "autoOrient": {
    "width": 1024,
    "height": 1024
  }
}

To obtain image metadata, you would normally need to install additional image processing libraries. By pregenerating and storing metadata, it can be used whenever needed. Below is an example of metadata for a jpeg image. For more information, see sharp .