Формат animated WebP используется для хранения анимаций, каждый кадр которых хранится в одном из вышеописанных форматов, то есть либо в формате lossy WebP, либо в формате lossless WebP, причём форматы разных кадров могут быть разными.
Анимированный lossless WebP является конкурентом для прежних форматов сжатия анимированных изображений, совершаемого без потерь: конкурентом и для анимированных GIF, и для анимированных PNG — и анимированный lossless WebP одерживает побѣду над ними благодаря болѣе высокой степени сжатия.
Так, напримѣръ, около шести лѣтъ тому назад, когда анимированные изображения снова начали входить в моду (но на новом техническом уровне начала десятых лѣтъ: не как небольшие и простенькие GIFки девяностых годов, а как отрывки видео многосотпиксельной ширины и болѣе чѣмъ мегабайтового объёма), во блоге Cloudinary появилась рекомендация выкладывать такие анимации в формате animated WebP (в качестве альтернативы для браузеров, понимающих WebP), причём не только для сокращения объёма файлов (то есть во избежание чрезмѣрныхъ расходов траффика), но и для преодоления ограничений 256-цвѣтной палитры, почти неизбѣжныхъ для GIF. (Я пишу «почти», так как gifski позволяет создавать болѣе цвѣтные кадры GIFов наложением нѣсколькихъ менѣе цвѣтныхъ кадров, хотя это и приводит к дальнейшему росту объёма.) То и другое достоинство остаётся злободневным до сих пор, обуславливая пользу от перехода на анимированные lossless WebP с прежних гифок или с APNG.
Тут надо сразу же сказать, однако же, что Cloudinary предпочитает (для ещё большей экономии объёма файлов) рекомендовать использование анимированных lossy WebP. Но сейчас, через ≈шесть лѣтъ после этой рекомендации, я могу отнестись к этому мнению Cloudinary скептически и указать вот на какое обстоятельство: так как формат анимированных изображений lossy WebP основан на формате ключевых кадров видеопотока VP8, то этот формат (в качестве средства для хранения анимаций со сжатием, сопровождающимся внесением потерь) с неизбѣжностью уступает (по соотношению объёма и качества) даже видеозаписям VP8, потому что во всякой видеозаписи, кроме ключевых кадров, также используются промежуточные, сжатые ещё сильнѣе ключевых. Слѣдовательно, если на мѣстѣ анимированного lossy WebP поставить видеофайл WebM (с видеопотоком VP8 или, тѣмъ болѣе, VP9) или видеофайл MP4 (с видеопотоком HEVC или, тѣмъ болѣе, AV1), то можно при том же объёме получить большѣе качество, а также важную дополнительную возможность использования звуковой дорожки. Придётся побеспокоиться разве что о том, что изо всѣхъ этих четырёх видеопотоков в системе iOS (то есть на айфонах и на айпэдах) браузером Safari поддерживается только HEVC, зато HEVC не поддерживается в большинстве других браузеров (и на то есть причина — угрожающая неясностью ситуация в сфере патентных отчислений за использование HEVC). Но об этом-то приходится побеспокоиться и насчёт формата WebP, тоже не поддерживаемого в Safari.
Появление видеозаписей, однако, не вполнѣ покончило с причинами использовать анимированные lossy WebP. В гугловском FAQ достоинством анимированных WebP зовут продолжение их недостатка: анимация, не содержащая промежуточных кадров, тѣмъ самым требует меньше оперативной памяти и меньше усилий процессора, так что появление нѣсколькихъ таких анимаций на одной интернетовской странице не создаст больших проблем даже для такого маломощного пользовательского устройства, которое стало бы бѣшено греться и подлагивать, если б столкнулось съ нѣсколькими полноцѣнными видеозаписями на одной странице. Но так как возможности устройств растут, то значимость этого достоинства отходит в прошлое. Ещё можно замѣтить, что пока анимация остаётся иллюстрацией (а не видеозаписью), её проще подмѣнить (для браузеров, не поддерживающих WebP) на иллюстрацию другого формата (на APNG, на анимированный GIF, а для Safari — и на видео MP4 в теге img) — подмѣнить на стороне сервера (как это дѣлаетъ Cloudinary), или на странице тегом picture (если есть, скажем, готовый APNG-аналог WebP-файла), или подпереть джаваскриптовым костылём (наподобие WebPJS или libwebpjs).
Анимированный lossless WebP является конкурентом для прежних форматов сжатия анимированных изображений, совершаемого без потерь: конкурентом и для анимированных GIF, и для анимированных PNG — и анимированный lossless WebP одерживает побѣду над ними благодаря болѣе высокой степени сжатия.
Так, напримѣръ, около шести лѣтъ тому назад, когда анимированные изображения снова начали входить в моду (но на новом техническом уровне начала десятых лѣтъ: не как небольшие и простенькие GIFки девяностых годов, а как отрывки видео многосотпиксельной ширины и болѣе чѣмъ мегабайтового объёма), во блоге Cloudinary появилась рекомендация выкладывать такие анимации в формате animated WebP (в качестве альтернативы для браузеров, понимающих WebP), причём не только для сокращения объёма файлов (то есть во избежание чрезмѣрныхъ расходов траффика), но и для преодоления ограничений 256-цвѣтной палитры, почти неизбѣжныхъ для GIF. (Я пишу «почти», так как gifski позволяет создавать болѣе цвѣтные кадры GIFов наложением нѣсколькихъ менѣе цвѣтныхъ кадров, хотя это и приводит к дальнейшему росту объёма.) То и другое достоинство остаётся злободневным до сих пор, обуславливая пользу от перехода на анимированные lossless WebP с прежних гифок или с APNG.
Тут надо сразу же сказать, однако же, что Cloudinary предпочитает (для ещё большей экономии объёма файлов) рекомендовать использование анимированных lossy WebP. Но сейчас, через ≈шесть лѣтъ после этой рекомендации, я могу отнестись к этому мнению Cloudinary скептически и указать вот на какое обстоятельство: так как формат анимированных изображений lossy WebP основан на формате ключевых кадров видеопотока VP8, то этот формат (в качестве средства для хранения анимаций со сжатием, сопровождающимся внесением потерь) с неизбѣжностью уступает (по соотношению объёма и качества) даже видеозаписям VP8, потому что во всякой видеозаписи, кроме ключевых кадров, также используются промежуточные, сжатые ещё сильнѣе ключевых. Слѣдовательно, если на мѣстѣ анимированного lossy WebP поставить видеофайл WebM (с видеопотоком VP8 или, тѣмъ болѣе, VP9) или видеофайл MP4 (с видеопотоком HEVC или, тѣмъ болѣе, AV1), то можно при том же объёме получить большѣе качество, а также важную дополнительную возможность использования звуковой дорожки. Придётся побеспокоиться разве что о том, что изо всѣхъ этих четырёх видеопотоков в системе iOS (то есть на айфонах и на айпэдах) браузером Safari поддерживается только HEVC, зато HEVC не поддерживается в большинстве других браузеров (и на то есть причина — угрожающая неясностью ситуация в сфере патентных отчислений за использование HEVC). Но об этом-то приходится побеспокоиться и насчёт формата WebP, тоже не поддерживаемого в Safari.
Появление видеозаписей, однако, не вполнѣ покончило с причинами использовать анимированные lossy WebP. В гугловском FAQ достоинством анимированных WebP зовут продолжение их недостатка: анимация, не содержащая промежуточных кадров, тѣмъ самым требует меньше оперативной памяти и меньше усилий процессора, так что появление нѣсколькихъ таких анимаций на одной интернетовской странице не создаст больших проблем даже для такого маломощного пользовательского устройства, которое стало бы бѣшено греться и подлагивать, если б столкнулось съ нѣсколькими полноцѣнными видеозаписями на одной странице. Но так как возможности устройств растут, то значимость этого достоинства отходит в прошлое. Ещё можно замѣтить, что пока анимация остаётся иллюстрацией (а не видеозаписью), её проще подмѣнить (для браузеров, не поддерживающих WebP) на иллюстрацию другого формата (на APNG, на анимированный GIF, а для Safari — и на видео MP4 в теге img) — подмѣнить на стороне сервера (как это дѣлаетъ Cloudinary), или на странице тегом picture (если есть, скажем, готовый APNG-аналог WebP-файла), или подпереть джаваскриптовым костылём (наподобие WebPJS или libwebpjs).