Cover stills to JPEG: lock frame index and matte color so black intros or alpha halos never become the list or share-card hero
`gif-frame-jpeg` covers list covers, push tiles, and Open Graph: you must pin which frame represents the campaign or APIs that default to frame 0 will ship black holds. JPEG saves bandwidth but progressive vs baseline changes LCP and how scrapers feel. Safe areas need margin for rounded cards and status bars.
`gif-frame-jpeg`: from timecode through share debuggers to real list-card width—accept twice
- Lock cover frame index or timecode with a circled reference; ship multiple long-edge sizes (e.g. 1200/800/640) with consistent suffixes in the filename.
- Validate at real list-card width and in each network’s share debugger; check whether `object-fit: cover` eats subtitle baselines.
- After launch fetch fresh CDN URLs from the debugger—confirm nothing was silently transcoded to WebP then flattened; bust cache with new filenames instead of overwriting paths.
Cover-frame JPEG Q&A: crops, progressive delivery, platform recompression, cache fingerprints
Share cards look gray and dirty—is that GIF quantization or JPEG quality set too low?
At the same width as production, compare the source GIF frame and the JPEG; if the source is already dirty, raising quality will not help. If the source is clean but JPEG is not, raise quality or export slightly larger and let the platform downscale—log each network’s visible recompression threshold.
We changed only the cover JPEG URL but the app still shows the old art—disk cache on device or stale CDN edge?
Compare `ETag` / `Last-Modified` and file hashes; if the path stayed the same, both app sandboxes and CDNs may cache for days. Ship a new filename or a strong version query plus coordinated purge; packet-capture to ensure you are not still pointing at the old object key.
Marketing calls progressive JPEG “broken blur-then-sharp” while engineering wants it for LCP—how do we align?
Write the spec that progressive decode is expected and ship a placeholder background color; if brand forbids it, baseline only this lane and quantify LCP trade-offs with data instead of arguing from thumbnails.
One master must become 1200, 800, and 640 variants—tune quality per size or one high master then downscale?
Prefer one high-quality master scaled through the same toolchain so color does not drift per tier; you may nudge quality per size to hit KB caps, but keep those knobs in scripts—not hand tweaks.
We deleted the JPEG cover but deep GIF links still get crawled—what brand or compliance risk remains?
Search and social may still animate the GIF or show stale OG tags; retire robots rules, force share refreshes, or swap placeholder stills. The ticket should say “retire motion and still together,” not “delete JPEG only.”