Half the Bytes, the Same Wait: What AVIF Actually Cost My Wallpaper Apps

Device support sets the ceiling on what you can choose

"Supports AVIF" and "decodes AVIF fast enough to ship" are different statements. Here is what I settled on after measuring on hardware.

The Android 12 row is the interesting one. ImageDecoder accepts AVIF there, so a capability check passes cleanly — and then you ship it and inherit the frame drops. A support matrix built on yes/no hides that step. I now draw the line on measured decode time instead of capability.

I looked at HEIC too. It decodes quickly on iOS, but the Android decoder story and the patent situation are both murky. Since the same asset pack goes to both the App Store and Google Play builds, an asset that only one platform can open would fork my encoding pipeline in two. At the scale one person can maintain, that is a cost I would rather not carry.

Negotiate on one URL, or list every URL in the manifest?

There are two ways to serve the right format: content-negotiate on a single URL via the Accept header, or publish per-format URLs in a manifest and let the client choose.

The Accept header can say "I can decode AVIF." It has no way to say "I can decode AVIF, badly." That single gap is what decided it — the Android 12 problem is invisible to a server doing pure Accept negotiation.

I ended up running both. The manifest makes the real decision; the Worker stays as a safety net for devices holding a stale manifest.

// worker/image-negotiate.js — the net under a stale manifest.
// The manifest decides; this exists so nothing ever serves a format the device cannot open.
const FALLBACK_CHAIN = ["avif", "webp", "jpeg"];
 
function pickFormat(accept, clientHint) {
  // clientHint: X-Decode-Tier sent by the app (fast / slow / legacy)
  if (clientHint === "legacy") return "jpeg";
  if (clientHint === "slow") return accept.includes("image/webp") ? "webp" : "jpeg";
  for (const fmt of FALLBACK_CHAIN) {
    if (accept.includes(`image/${fmt}`)) return fmt;
  }
  return "jpeg";
}
 
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const accept = request.headers.get("Accept") || "";
    const tier = request.headers.get("X-Decode-Tier") || "fast";
    const fmt = pickFormat(accept, tier);
 
    const key = url.pathname.replace(/\.\w+$/, "") + "." + fmt;
    const object = await env.WALLPAPERS.get(key.slice(1));
    if (!object) return new Response("Not found", { status: 404 });
 
    return new Response(object.body, {
      headers: {
        "Content-Type": `image/${fmt}`,
        // Keep Vary narrow or the edge cache fragments without bound
        Vary: "Accept, X-Decode-Tier",
        "Cache-Control": "public, max-age=31536000, immutable",
      },
    });
  },
};

Be careful with Vary. Put anything device-specific in there and your edge cache splits once per device variant. My first week shipped with User-Agent in Vary and the hit rate fell from 94% to 61%. Swapping it for a three-value X-Decode-Tier brought it back to 96%.

Detect "decodes fast," not "decodes at all"

The app classifies itself into a tier exactly once. Running a benchmark on every launch would trade startup time for image speed, which defeats the point.

// src/media/decodeTier.ts
import * as Device from "expo-device";
import { Platform } from "react-native";
import AsyncStorage from "@react-native-async-storage/async-storage";
 
export type DecodeTier = "fast" | "slow" | "legacy";
const CACHE_KEY = "media:decodeTier:v2";
 
async function probe(): Promise<DecodeTier> {
  const major = parseInt(String(Device.osVersion ?? "0").split(".")[0], 10);
 
  if (Platform.OS === "ios") {
    if (major >= 17) return "fast";      // A15+ is the floor here; HW decode assumed
    if (major >= 16) return "slow";      // decodes, but on the CPU
    return "legacy";
  }
  // On Android, API level alone does not separate budget from flagship
  if (major >= 13 && (Device.totalMemory ?? 0) > 5.5e9) return "fast";
  if (major >= 12) return "slow";
  return "legacy";
}
 
export async function getDecodeTier(): Promise<DecodeTier> {
  const cached = await AsyncStorage.getItem(CACHE_KEY);
  if (cached) return cached as DecodeTier;
  const tier = await probe();
  await AsyncStorage.setItem(CACHE_KEY, tier);
  return tier;
}
 
export function formatFor(tier: DecodeTier): "avif" | "webp" | "jpeg" {
  return tier === "fast" ? "avif" : tier === "slow" ? "webp" : "jpeg";
}

Device.totalMemory is in there because API level alone failed me. Two Android 13 phones, one with 4 GB of RAM, and the smaller one decoded AVIF 2.4× slower. It is a crude proxy, but across six apps it disagrees with measured decode time only about 5% of the time.

The v2 in the cache key earned its place too. When I corrected the thresholds, the old verdict sat in storage and would not budge. Bumping the version forces every device to re-evaluate.

Keep the manifest boring

{
  "packId": "aurora-2026-07",
  "items": [
    {
      "id": "aurora-014",
      "w": 2796, "h": 1290,
      "src": {
        "avif": "https://cdn.example.com/aurora-014.avif",
        "webp": "https://cdn.example.com/aurora-014.webp",
        "jpeg": "https://cdn.example.com/aurora-014.jpg"
      },
      "bytes": { "avif": 1782341, "webp": 2461902, "jpeg": 3612884 }
    }
  ]
}

bytes is there so a data-saver setting can decide before fetching anything. This is the same manifest I described in shipping wallpaper packs without an app review, with src and bytes added. Widening a structure I already operate beat inventing a second one.

Do not convert all 400 images at once

Converting everything and shipping it leaves you nothing to bisect when something breaks. The order I use now:

1. Thumbnails only. They dominate the gallery's first paint, and a failure there cannot corrupt the save-to-photos path. This alone moves 34% of transfer.
2. One app, two weeks. Compare crash rate and frame drops against the equivalent window before the change. No regression, no reason to stop.
3. Full-size images, new packs only. Leave the existing 400 alone. If something surfaces, rolling the manifest back one generation is the entire fix.
4. Roll out to the other five apps. Only now does the conversion step go into CI.
5. Re-encode legacy assets when — and if — it pays. It did not.

Step five was supposed to be step one in my original plan. Then I looked at the breakdown: 81% of the last 90 days of transfer went to packs added in the previous 30 days. Re-encoding old assets is effort with almost no invoice attached. Billing broken out per pack is what let me skip it.

There was a faint revenue echo as well. Gallery first paint got shorter, sessions started marginally sooner, and AdMob app-open impressions on Day 1 rose about 4%. The causal link is weak and I would not build a plan on it, but it is a reminder that asset delivery sits upstream of the funnel.

Where the six apps sit today

Monthly transfer is down 38% — short of the 52% I originally modelled, because the legacy assets are untouched. In exchange, frame drops on the Pixel 4a are still 3.1%, unchanged, and no tier of reader got a worse experience.

Given 38% or 52%, I took 38%. The invoice is something only I ever see. A stuttering scroll is something every reader sees.

The next thing I want to fix is the tier probe itself. Guessing from OS version and RAM works, but decoding one small AVIF at first launch and timing it would be honest. I have not decided which part of the startup budget pays for that, so it is sitting on the shelf for now.

If you are looking at your own asset delivery costs, measure transfer and decode separately before you change anything. The version of me reading that first invoice believed every byte saved was a millisecond earned. It is not, and finding out cost me two weeks.