سوالات متداول

WebP چیست؟ چرا باید از آن استفاده کنم؟

WebP روشی برای فشرده‌سازی با اتلاف و بدون اتلاف است که می‌تواند برای طیف وسیعی از تصاویر عکاسی، نیمه‌شفاف و گرافیکی موجود در وب استفاده شود. درجه فشرده‌سازی با اتلاف قابل تنظیم است، بنابراین کاربر می‌تواند بین اندازه فایل و کیفیت تصویر تعادل برقرار کند. WebP معمولاً به طور متوسط ​​30٪ فشرده‌سازی بیشتری نسبت به JPEG انجام می‌دهد، بدون اینکه کیفیت تصویر از دست برود (به مطالعه WebP Lossy مراجعه کنید). تصاویر بدون اتلاف WebP در مقایسه با PNG ها 26٪ حجم کمتری دارند ( به مطالعه WebP Lossless و Alpha مراجعه کنید).

فرمت WebP اساساً با هدف ایجاد تصاویر کوچک‌تر و زیباتر طراحی شده است که می‌توانند به سریع‌تر شدن وب کمک کنند.

کدام مرورگرهای وب به طور طبیعی از WebP پشتیبانی می‌کنند؟

مدیران وب‌سایتی که علاقه‌مند به بهبود عملکرد سایت خود هستند، می‌توانند به راحتی جایگزین‌های بهینه‌شده‌ی WebP را برای تصاویر فعلی خود ایجاد کنند و آن‌ها را به صورت هدفمند به مرورگرهایی که از WebP پشتیبانی می‌کنند، ارائه دهند.

  • پشتیبانی از فرمت WebP با اتلاف داده
    • گوگل کروم (دسکتاپ) ۱۷+
    • گوگل کروم برای اندروید نسخه ۲۵+
    • مایکروسافت اج ۱۸+
    • فایرفاکس ۶۵+
    • اپرا ۱۱.۱۰+
    • مرورگر وب بومی، اندروید ۴.۰+ (ICS)
    • سافاری ۱۴+ (iOS ۱۴+، macOS Big Sur+)
  • پشتیبانی از WebP با اتلاف، بدون اتلاف و آلفا
    • گوگل کروم (دسکتاپ) ۲۳+
    • گوگل کروم برای اندروید نسخه ۲۵+
    • مایکروسافت اج ۱۸+
    • فایرفاکس ۶۵+
    • اپرا ۱۲.۱۰+
    • مرورگر وب بومی، اندروید ۴.۲+ (JB-MR1)
    • ماه رنگ‌پریده ۲۶+
    • سافاری ۱۴+ (iOS ۱۴+، macOS Big Sur+)
  • پشتیبانی از انیمیشن WebP
    • گوگل کروم (دسکتاپ و اندروید) ۳۲+
    • مایکروسافت اج ۱۸+
    • فایرفاکس ۶۵+
    • اپرا ۱۹+
    • سافاری ۱۴+ (iOS ۱۴+، macOS Big Sur+)

همچنین ببینید:

چگونه می‌توانم پشتیبانی مرورگر از WebP را تشخیص دهم؟

شما می‌خواهید تصاویر WebP را فقط به کلاینت‌هایی ارائه دهید که می‌توانند آنها را به درستی نمایش دهند و برای کلاینت‌هایی که نمی‌توانند، به فرمت‌های قدیمی‌تر برگردید. خوشبختانه تکنیک‌های مختلفی برای تشخیص پشتیبانی WebP، هم در سمت کلاینت و هم در سمت سرور، وجود دارد. برخی از ارائه‌دهندگان CDN، تشخیص پشتیبانی WebP را به عنوان بخشی از خدمات خود ارائه می‌دهند.

مذاکره محتوای سمت سرور از طریق سربرگ‌های پذیرش

برای کلاینت‌های وب معمول است که یک هدر درخواست «پذیرش» ارسال کنند که نشان می‌دهد کدام فرمت‌های محتوا را در پاسخ می‌خواهند بپذیرند. اگر مرورگری از قبل اعلام کند که فرمت تصویر/webp را «می‌پذیرد»، وب سرور می‌داند که می‌تواند با خیال راحت تصاویر WebP را ارسال کند و مذاکره در مورد محتوا را بسیار ساده می‌کند. برای اطلاعات بیشتر به لینک‌های زیر مراجعه کنید.

مدرنیزر

Modernizr یک کتابخانه جاوا اسکریپت برای تشخیص راحت پشتیبانی از ویژگی‌های HTML5 و CSS3 در مرورگرهای وب است. به دنبال ویژگی‌های Modernizr.webp ، Modernizr.webp.lossless ، Modernizr.webp.alpha و Modernizr.webp.animation باشید.

عنصر <picture> در HTML5

HTML5 از عنصر <picture> پشتیبانی می‌کند که به شما امکان می‌دهد چندین تصویر جایگزین را به ترتیب اولویت فهرست کنید، به طوری که یک کلاینت اولین تصویر کاندیدی را که می‌تواند به درستی نمایش دهد، درخواست کند. این بحث را در HTML5 Rocks ببینید. عنصر <picture> همیشه توسط مرورگرهای بیشتری پشتیبانی می‌شود.

با جاوا اسکریپت خودتان

روش دیگر تشخیص، تلاش برای رمزگشایی یک تصویر WebP بسیار کوچک است که از یک ویژگی خاص استفاده می‌کند و بررسی موفقیت آن. مثال:

// check_webp_feature:
//   'feature' can be one of 'lossy', 'lossless', 'alpha' or 'animation'.
//   'callback(feature, result)' will be passed back the detection result (in an asynchronous way!)
function check_webp_feature(feature, callback) {
    var kTestImages = {
        lossy: "UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA",
        lossless: "UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==",
        alpha: "UklGRkoAAABXRUJQVlA4WAoAAAAQAAAAAAAAAAAAQUxQSAwAAAARBxAR/Q9ERP8DAABWUDggGAAAABQBAJ0BKgEAAQAAAP4AAA3AAP7mtQAAAA==",
        animation: "UklGRlIAAABXRUJQVlA4WAoAAAASAAAAAAAAAAAAQU5JTQYAAAD/////AABBTk1GJgAAAAAAAAAAAAAAAAAAAGQAAABWUDhMDQAAAC8AAAAQBxAREYiI/gcA"
    };
    var img = new Image();
    img.onload = function () {
        var result = (img.width > 0) && (img.height > 0);
        callback(feature, result);
    };
    img.onerror = function () {
        callback(feature, false);
    };
    img.src = "data:image/webp;base64," + kTestImages[feature];
}

توجه داشته باشید که بارگذاری تصویر غیر مسدودکننده و ناهمزمان است. این بدان معناست که هر کدی که به پشتیبانی WebP بستگی دارد، ترجیحاً باید در تابع فراخوانی قرار گیرد.

چرا گوگل WebP را به صورت متن باز منتشر کرد؟

ما عمیقاً به اهمیت مدل متن‌باز اعتقاد داریم. با متن‌باز بودن WebP، هر کسی می‌تواند با این فرمت کار کند و پیشنهادهایی برای بهبود آن ارائه دهد. با نظرات و پیشنهادات شما، ما معتقدیم که WebP به مرور زمان به عنوان یک فرمت گرافیکی مفیدتر خواهد شد.

چگونه می‌توانم فایل‌های تصاویر شخصی‌ام را به WebP تبدیل کنم؟

شما می‌توانید از ابزار خط فرمان WebP برای تبدیل فایل‌های تصویری شخصی خود به فرمت WebP استفاده کنید. برای جزئیات بیشتر به بخش «استفاده از WebP» مراجعه کنید.

اگر تصاویر زیادی برای تبدیل دارید، می‌توانید از پوسته پلتفرم خود برای ساده‌سازی عملیات استفاده کنید. برای مثال، برای تبدیل تمام فایل‌های jpeg در یک پوشه، موارد زیر را امتحان کنید:

ویندوز:

> for /R . %I in (*.jpg) do ( cwebp.exe %I -o %~fnI.webp )

لینوکس / macOS:

$ for F in *.jpg; do cwebp $F -o `basename ${F%.jpg}`.webp; done

چگونه می‌توانم کیفیت تصویر WebP را خودم ارزیابی کنم؟

در حال حاضر، می‌توانید فایل‌های WebP را با تبدیل آنها به یک فرمت رایج که از فشرده‌سازی بدون اتلاف استفاده می‌کند، مانند PNG، مشاهده کنید و سپس فایل‌های PNG را در هر مرورگر یا نمایشگر تصویری مشاهده کنید. برای درک سریع کیفیت WebP، برای مقایسه عکس‌ها در کنار هم، به گالری این سایت مراجعه کنید.

چطور کد منبع را دریافت کنم؟

کد مبدل در بخش دانلودهای صفحه پروژه متن‌باز WebP موجود است. کد مربوط به رمزگشای سبک و مشخصات VP8 در سایت WebM قرار دارد. برای مشخصات کانتینر به صفحه کانتینر RIFF مراجعه کنید.

حداکثر اندازه یک تصویر WebP چقدر می‌تواند باشد؟

WebP با VP8 از نظر بیت‌استریم سازگار است و از ۱۴ بیت برای عرض و ارتفاع استفاده می‌کند. حداکثر ابعاد پیکسلی یک تصویر WebP، ۱۶۳۸۳ در ۱۶۳۸۳ است.

فرمت WebP از چه فضاهای رنگی پشتیبانی می‌کند؟

مطابق با جریان بیتی VP8، فرمت WebP با اتلاف منحصراً با فرمت تصویر 8 بیتی Y'CbCr 4:2:0 (که اغلب YUV420 نامیده می‌شود) کار می‌کند. لطفاً برای جزئیات بیشتر به بخش 2، " مروری بر فرمت " از RFC 6386، راهنمای فرمت داده و رمزگشایی VP8 مراجعه کنید.

WebP بدون اتلاف منحصراً با فرمت RGBA کار می‌کند. به مشخصات جریان بیتی بدون اتلاف WebP مراجعه کنید.

چرا فایل WebP بدون افت کیفیت من با فایل اصلی متفاوت است؟

توابع API کدگذاری ساده ( WebPEncodeLosslessRGB() ، WebPEncodeLosslessBGR() ، WebPEncodeLosslessRGBA() ، WebPEncodeLosslessBGRA() )، از تنظیمات پیش‌فرض کتابخانه استفاده می‌کنند. برای حالت بدون اتلاف، این به معنای غیرفعال بودن گزینه «دقیق» است. مقادیر RGB در نواحی کاملاً شفاف (یعنی نواحی با مقادیر آلفای برابر با 0 ) برای بهبود فشرده‌سازی اصلاح می‌شوند. برای جلوگیری از این امر، از WebPEncode() استفاده کنید و WebPConfig::exact را روی 1 تنظیم کنید. به مستندات API کدگذاری پیشرفته مراجعه کنید.

آیا یک تصویر WebP می‌تواند از تصویر منبع خود بزرگتر شود؟

بله، معمولاً هنگام تبدیل از یک قالب با اتلاف به WebP بدون اتلاف یا برعکس. این عمدتاً به دلیل تفاوت فضای رنگی (YUV420 در مقابل ARGB) و تبدیل بین این دو است.

سه موقعیت معمول وجود دارد:

  1. اگر تصویر منبع در قالب ARGB بدون اتلاف باشد، نمونه‌برداری مکانی به YUV420 رنگ‌های جدیدی را معرفی می‌کند که فشرده‌سازی آنها نسبت به رنگ‌های اصلی دشوارتر است. این وضعیت معمولاً زمانی اتفاق می‌افتد که منبع در قالب PNG با رنگ‌های کم باشد: تبدیل به WebP با اتلاف (یا مشابه JPEG با اتلاف) به طور بالقوه منجر به حجم فایل بزرگتری خواهد شد.
  2. اگر منبع در قالب فشرده‌سازی با اتلاف باشد، استفاده از فشرده‌سازی WebP بدون اتلاف برای ثبت ماهیت اتلافی منبع معمولاً منجر به فایل بزرگ‌تری می‌شود. این موضوع مختص WebP نیست و می‌تواند هنگام تبدیل یک منبع JPEG به قالب‌های WebP یا PNG بدون اتلاف نیز رخ دهد.
  3. اگر منبع در قالب فشرده‌سازی با اتلاف باشد و شما سعی دارید آن را به عنوان یک WebP با اتلاف و با تنظیمات کیفیت بالاتر فشرده کنید. به عنوان مثال، تلاش برای تبدیل یک فایل JPEG ذخیره شده با کیفیت ۸۰ به یک فایل WebP با کیفیت ۹۵ معمولاً منجر به یک فایل بزرگتر می‌شود، حتی اگر هر دو فرمت با اتلاف باشند. ارزیابی کیفیت منبع اغلب غیرممکن است، بنابراین توصیه می‌شود اگر اندازه فایل به طور مداوم بزرگتر است، کیفیت WebP هدف را کاهش دهید. یک راه دیگر این است که از استفاده از تنظیمات کیفیت خودداری کنید و در عوض با استفاده از گزینه -size در ابزار cwebp یا API معادل آن، اندازه فایل مشخصی را هدف قرار دهید. به عنوان مثال، هدف قرار دادن ۸۰٪ از اندازه فایل اصلی ممکن است قوی‌تر باشد.

توجه داشته باشید که تبدیل یک منبع JPEG به WebP با اتلاف یا یک منبع PNG به WebP بدون اتلاف، مستعد چنین تغییرات غیرمنتظره‌ای در اندازه فایل نیست.

آیا WebP از نمایش مترقی یا درهم تنیده پشتیبانی می‌کند؟

WebP به‌روزرسانی رمزگشایی پیش‌رونده یا درهم‌تنیده را به معنای JPEG یا PNG ارائه نمی‌دهد. این احتمالاً فشار زیادی را بر CPU و حافظه کلاینت رمزگشایی وارد می‌کند زیرا هر رویداد به‌روزرسانی شامل یک گذر کامل از سیستم رفع فشار است.

به طور متوسط، رمزگشایی یک تصویر JPEG پیشرونده معادل ۳ بار رمزگشایی تصویر پایه است.

از طرف دیگر، WebP رمزگشایی افزایشی را ارائه می‌دهد، که در آن از تمام بایت‌های ورودی موجود از جریان بیت برای تلاش و تولید یک ردیف نمونه قابل نمایش در اسرع وقت استفاده می‌شود. این کار هم در حافظه، CPU و هم در تلاش برای رنگ‌آمیزی مجدد در کلاینت صرفه‌جویی می‌کند و در عین حال نشانه‌های بصری در مورد وضعیت دانلود ارائه می‌دهد. ویژگی رمزگشایی افزایشی از طریق API رمزگشایی پیشرفته در دسترس است.

چگونه می‌توانم از اتصالات جاوای libwebp در پروژه اندروید خود استفاده کنم؟

WebP از اتصال JNI به رابط‌های ساده‌ی رمزگذار و رمزگشا در دایرکتوری swig/ پشتیبانی می‌کند.

ساخت کتابخانه در Eclipse :

  1. مطمئن شوید که افزونه‌ی ADT را به همراه ابزارهای NDK نصب کرده‌اید و مسیر NDK شما به درستی تنظیم شده است ( Preferences > Android > NDK ).
  2. یک پروژه جدید ایجاد کنید: فایل > جدید > پروژه > پروژه برنامه اندروید .
  3. libwebp را در پوشه‌ای به نام jni در پروژه جدید کلون یا از حالت فشرده خارج کنید.
  4. swig/libwebp_java_wrap.c را به لیست LOCAL_SRC_FILES اضافه کنید.
  5. روی پروژه جدید کلیک راست کنید و Android Tools > Add Native Support ... را انتخاب کنید تا کتابخانه در پروژه شما گنجانده شود.

  6. ویژگی‌های پروژه را باز کنید و به C/C++ Build > Behaviour بروید. برای ساخت libwebp به عنوان یک کتابخانه مشترک ENABLE_SHARED=1 را به بخش Build (Incremental build) اضافه کنید.

    توجه داشته باشید که تنظیم NDK_TOOLCHAIN_VERSION=4.8 به طور کلی عملکرد ساخت ۳۲ بیتی را بهبود می‌بخشد.

  7. swig/libwebp.jar را به پوشه libs/ project اضافه کنید.

  8. پروژه خود را بسازید. این کار libs/<target-arch>/libwebp.so را ایجاد خواهد کرد.

  9. برای بارگذاری کتابخانه در زمان اجرا System.loadLibrary("webp") استفاده کنید.

توجه داشته باشید که این کتابخانه را می‌توان به صورت دستی با ndk-build و Android.mk موجود ساخت. برخی از مراحل شرح داده شده در بالا را می‌توان در این مورد دوباره استفاده کرد.

چگونه می‌توانم از libwebp با سی شارپ استفاده کنم؟

WebP می‌تواند به عنوان یک DLL ساخته شود که API مربوط به libwebp را صادر می‌کند. سپس می‌توان این توابع را در C# وارد کرد.

  1. فایل libwebp.dll را بسازید. این کار WEBP_EXTERN را به درستی برای خروجی گرفتن از توابع API تنظیم می‌کند.

    libwebp> nmake /f Makefile.vc CFG=release-dynamic

  2. libwebp.dll را به پروژه خود اضافه کنید و توابع مورد نظر را وارد کنید. توجه داشته باشید که اگر از API ساده استفاده می‌کنید، باید WebPFree() را برای آزاد کردن هرگونه بافر برگشتی فراخوانی کنید.

    [DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPEncodeBGRA(IntPtr rgba, int width, int height, int stride,
                                 float quality_factor, out IntPtr output);
[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPFree(IntPtr p);

void Encode() {
  Bitmap source = new Bitmap("input.png");
  BitmapData data = source.LockBits(
      new Rectangle(0, 0, source.Width, source.Height),
      ImageLockMode.ReadOnly,
      PixelFormat.Format32bppArgb);
  IntPtr webp_data;
  const int size = WebPEncodeBGRA(data.Scan0,
                                  source.Width, source.Height, data.Stride,
                                  80, out webp_data);
  // ...
  WebPFree(webp_data);
}

چرا باید از WebP متحرک استفاده کنم؟

مزایای WebP متحرک در مقایسه با GIF متحرک

  1. WebP از رنگ RGB 24 بیتی با کانال آلفای 8 بیتی پشتیبانی می‌کند، در حالی که GIF از رنگ 8 بیتی و آلفای 1 بیتی پشتیبانی می‌کند.

  2. WebP از هر دو فشرده‌سازی با اتلاف و بدون اتلاف پشتیبانی می‌کند؛ در واقع، یک انیمیشن واحد می‌تواند فریم‌های با اتلاف و بدون اتلاف را با هم ترکیب کند. GIF فقط از فشرده‌سازی بدون اتلاف پشتیبانی می‌کند. تکنیک‌های فشرده‌سازی با اتلاف WebP برای تصاویر متحرک ایجاد شده از ویدیوهای دنیای واقعی، که منبعی رو به رشد از تصاویر متحرک است، بسیار مناسب هستند.

  3. WebP به بایت‌های کمتری نسبت به GIF نیاز دارد. GIFهای متحرک تبدیل شده به WebPهای با اتلاف ۶۴٪ کوچکتر هستند، در حالی که WebPهای بدون اتلاف ۱۹٪ کوچکتر هستند. این امر به ویژه در شبکه‌های تلفن همراه اهمیت دارد.

  4. WebP در صورت وجود جستجو، زمان کمتری برای رمزگشایی نیاز دارد. در Blink ، پیمایش یا تغییر تب‌ها می‌تواند تصاویر را پنهان و نمایش دهد، در نتیجه انیمیشن‌ها متوقف شده و سپس به نقطه دیگری منتقل می‌شوند. استفاده بیش از حد از CPU که منجر به افت فریم در انیمیشن‌ها می‌شود، می‌تواند رمزگشا را نیز مجبور به جستجوی رو به جلو در انیمیشن کند. در این سناریوها، WebP متحرک 0.57 برابر زمان رمزگشایی کل 2 برابر GIF طول می‌کشد، که منجر به لرزش کمتر در هنگام پیمایش و بازیابی سریع‌تر از افزایش ناگهانی استفاده از CPU می‌شود. این به دلیل دو مزیت WebP نسبت به GIF است:

    • تصاویر WebP متادیتاهایی در مورد اینکه آیا هر فریم حاوی آلفا است یا خیر، ذخیره می‌کنند و نیاز به رمزگشایی فریم برای تصمیم‌گیری در این مورد را از بین می‌برند. این امر منجر به استنتاج دقیق‌تر در مورد اینکه یک فریم مشخص به کدام فریم‌های قبلی وابسته است، می‌شود و در نتیجه رمزگشایی غیرضروری فریم‌های قبلی را کاهش می‌دهد.

    • بسیار شبیه به یک رمزگذار ویدیوی مدرن، رمزگذار WebP به صورت اکتشافی فریم‌های کلیدی را در فواصل منظم اضافه می‌کند (که اکثر رمزگذارهای GIF این کار را انجام نمی‌دهند). این امر به طور چشمگیری جستجو در انیمیشن‌های طولانی را بهبود می‌بخشد. برای تسهیل درج چنین فریم‌هایی بدون افزایش قابل توجه اندازه تصویر، WebP علاوه بر روش حذف فریم که GIF از آن استفاده می‌کند، یک پرچم «روش ترکیب» برای هر فریم اضافه می‌کند. این به یک فریم کلیدی اجازه می‌دهد تا طوری ترسیم شود که گویی کل تصویر به رنگ پس‌زمینه پاک شده است، بدون اینکه فریم قبلی مجبور به اندازه کامل شود.

معایب WebP متحرک در مقایسه با GIF متحرک

  1. در غیاب جستجو، رمزگشایی مستقیم WebP نسبت به GIF به CPU بیشتری نیاز دارد. WebP با اتلاف ۲.۲ برابر GIF زمان رمزگشایی می‌برد، در حالی که WebP بدون اتلاف ۱.۵ برابر GIF زمان می‌برد.

  2. پشتیبانی از WebP به اندازه پشتیبانی از GIF که عملاً جهانی است، گسترده نیست.

  3. افزودن پشتیبانی WebP به مرورگرها، ردپای کد و سطح حمله را افزایش می‌دهد. در Blink، این تقریباً ۱۵۰۰ خط کد اضافی است (شامل کتابخانه demux WebP و رمزگشای تصویر WebP در Blink). توجه داشته باشید که اگر WebP و WebM کد رمزگشایی مشترک‌تری داشته باشند، یا اگر قابلیت‌های WebP در WebM گنجانده شود، این مشکل می‌تواند در آینده کاهش یابد.

چرا به سادگی از WebM در <img> پشتیبانی نکنیم؟

ممکن است در درازمدت پشتیبانی از فرمت‌های ویدیویی درون تگ <img> منطقی باشد. با این حال، انجام این کار در حال حاضر، با این هدف که WebM در <img> بتواند نقش پیشنهادی WebP متحرک را پر کند، مشکل‌ساز است:

  1. هنگام رمزگشایی یک فریم که به فریم‌های قبلی متکی است، WebM برای نگهداری حداقل تعداد فریم‌های قبلی (۳) به ۵۰٪ حافظه بیشتر از WebP متحرک نیاز دارد.

  2. پشتیبانی از کدک‌های ویدیویی و کانتینرها در مرورگرها و دستگاه‌های مختلف بسیار متفاوت است. برای تسهیل تبدیل خودکار کد محتوا (مثلاً برای پروکسی‌های صرفه‌جویی در پهنای باند)، مرورگرها باید هدرهای پذیرش را اضافه کنند که نشان می‌دهد تگ‌های تصویر آنها از چه فرمت‌هایی پشتیبانی می‌کنند. حتی این ممکن است کافی نباشد، زیرا انواع MIME مانند "video/webm" یا "video/mpeg" هنوز پشتیبانی از کدک را نشان نمی‌دهند (مثلاً VP8 در مقابل VP9). از سوی دیگر، فرمت WebP عملاً ثابت مانده است و اگر فروشندگانی که آن را ارائه می‌دهند موافقت کنند که WebP متحرک را ارائه دهند، رفتار WebP در تمام UAها باید ثابت باشد. و از آنجایی که هدر پذیرش "image/webp" قبلاً برای نشان دادن پشتیبانی از WebP استفاده شده است، هیچ تغییر جدیدی در هدر پذیرش لازم نیست.

  3. پشته ویدیوی Chromium برای پخش روان بهینه شده است و فرض می‌کند که فقط یک یا دو ویدیو به طور همزمان پخش می‌شوند. در نتیجه، پیاده‌سازی آن در مصرف منابع سیستم (رشته‌ها، حافظه و غیره) برای به حداکثر رساندن کیفیت پخش، بسیار تهاجمی است. چنین پیاده‌سازی برای بسیاری از ویدیوهای همزمان به خوبی مقیاس‌پذیر نیست و نیاز به طراحی مجدد دارد تا برای استفاده با صفحات وب با تصاویر سنگین مناسب باشد.

  4. WebM در حال حاضر تمام تکنیک‌های فشرده‌سازی WebP را در خود جای نمی‌دهد. در نتیجه، این تصویر با WebP به طور قابل توجهی بهتر از گزینه‌های دیگر فشرده می‌شود:

۱ برای تمام مقایسه‌های بین GIF متحرک و WebP متحرک، ما از مجموعه‌ای شامل حدود ۷۰۰۰ تصویر GIF متحرک که به صورت تصادفی از وب گرفته شده بودند، استفاده کردیم. این تصاویر با استفاده از ابزار 'gif2webp' و با تنظیمات پیش‌فرض (ساخته شده از آخرین درخت منبع libwebp از تاریخ ۱۰/۰۸/۲۰۱۳) به WebP متحرک تبدیل شدند. اعداد مقایسه‌ای، میانگین مقادیر این تصاویر هستند.

۲ زمان رمزگشایی با استفاده از آخرین نسخه libwebp + ToT Blink از تاریخ ۱۰/۰۸/۲۰۱۳ و با استفاده از یک ابزار بنچمارک محاسبه شد. «زمان رمزگشایی با جستجو» به صورت «رمزگشایی پنج فریم اول، پاک کردن حافظه نهان بافر فریم، رمزگشایی پنج فریم بعدی و غیره» محاسبه می‌شود.

۳- وب‌ام (WebM) چهار فریم مرجع YUV را در حافظه نگه می‌دارد که هر فریم (عرض + ۹۶)*(ارتفاع + ۹۶) پیکسل را ذخیره می‌کند. برای YUV 4:2:0، به ۴ بایت برای هر ۶ پیکسل (یا ۳/۲ بایت برای هر پیکسل) نیاز داریم. بنابراین، این فریم‌های مرجع 4*3/2*(width+96)*(height+96) بایت حافظه استفاده می‌کنند. از سوی دیگر، وب‌پی (WebP) فقط به فریم قبلی (در RGBA) نیاز دارد که 4*width*height بایت حافظه است.

رندر کردن WebP متحرک به نسخه ۳۲+ گوگل کروم نیاز دارد.