نحوه عملکرد فشردهسازی تصویر مبتنی بر مرورگر
هر پاس فشردهسازی کاملاً در JavaScript اجرا میشود. هیچ کتابخانه codec دانلود نمیشود و هیچ سروری درگیر نیست. Canvas API خود مرورگر تصویر را رمزگشایی میکند، آن را با کیفیت پایینتر رمزگذاری مجدد میکند، و یک Blob به شما تحویل میدهد که صفحه میتواند آن را پیشنمایش، دانلود یا zip کند. چون هر مرحله داخل sandbox تب میماند، فایلهای اصلی هرگز به شبکه نمیرسند.
- هر فایل آپلودشده را بهعنوان Blob بخوانید و یک object URL ایجاد کنید تا مرورگر بتواند آن را بدون کپی کردن بایتها به سرور یا نوشتن روی دیسک، بهصورت محلی رمزگشایی کند.
- تصویر رمزگشاییشده را روی یک عنصر Canvas offscreen با ابعاد پیکسلی اصلیاش رسم کنید، آماده برای رمزگذاری مجدد.
canvas.toBlob(callback, mimeType, quality)را فراخوانی کنید تا پیکسلها رمزگذاری مجدد شوند. در حالت کیفیت، مقدار نوار لغزنده مستقیماً به تنظیم کوانتیزاسیون encoder نگاشت میشود؛ در حالت اندازه هدف، صفحه مقدار کیفیت را دوتایی میکند تا Blob خروجی زیر بودجه بایت شما جا بگیرد.- یک خواندن قبل/بعد با اندازه اصلی، اندازه فشردهشده و درصد صرفهجویی نشان میدهد، سپس یک دانلود به ازای هر تصویر یا یک ZIP واحد برای کل دسته ارائه میدهد. ZIP با استفاده از fflate، کتابخانه ۸ کیلوبایتی که در اولین استفاده بارگذاری میشود، در حافظه ساخته میشود.
چرا تصاویر را فشرده کنیم؟
- تصاویر کوچکتر سریعتر بارگذاری میشوند. کاهش یک تصویر hero از ۴ مگابایت به ۶۰۰ کیلوبایت مستقیماً Largest Contentful Paint را بهبود میبخشد که یکی از Core Web Vitals است که Google برای رتبهبندی استفاده میکند. در صفحهای با چند عکس این صرفهجویی در یک رنگآمیزی اول سریعتر ترکیب میشود.
- محدودیتهای آپلود و پیوست همه جا هستند. بسیاری از پلتفرمهای CMS، ابزارهای ticketing و سیستمهای ایمیل فایلهای بیش از ۱ یا ۲ مگابایت را رد میکنند. یک پاس فشردهسازی سریع یک عکس را بدون باز کردن ویرایشگر کامل زیر حد میآورد.
- پهنای باند و ذخیرهسازی در مقیاس هزینه دارند. ارسال WebP با کیفیت ۰.۸ به جای PNG با اندازه کامل میتواند payload تصویر را یکسوم یا بیشتر کاهش دهد، که صورتحساب egress CDN و مصرف داده موبایل بازدیدکنندگان شما را کاهش میدهد.
- برخی تصاویر اصلاً نباید آپلود شوند. چون همه چیز در مرورگر شما اجرا میشود، اسکن شناسنامه، تصاویر پزشکی و اسکرینشاتهای داخلی روی دستگاه شما میمانند — هیچ سرور شخص ثالثی مانند TinyPNG در حلقه نیست که نگران آن باشید.
کاربردهای رایج
فشردهسازی هر بار که تصویر از جایی که باید برود بزرگتر است مطرح میشود. سه الگویی که بارها میبینیم.
- آمادهسازی عکسهای محصول برای یک فروشگاه آنلاین. اصلهای JPEG به کیفیت ۰.۸ (یا هدف ۲۰۰ کیلوبایت) فشرده میشوند تا ویترین سریع بماند و Core Web Vitals موبایل را پاس کند.
- کوچک کردن اسکرینشاتها قبل از پیوست کردن به bug tracker یا wiki. یک دسته از کپچرهای PNG تبدیلشده به JPEG با کیفیت ۰.۸۵ اغلب از دهها مگابایت به چند مگابایت میافتد.
- رساندن عکس زیر سقف آپلود — یک پورتال درخواست شغلی که فایلهای بیش از ۱ مگابایت را رد میکند، یک سیستم ایمیل با محدودیت پیوست تنگ، یا یک آواتار انجمن که باید در یک بودجه بایت جا بگیرد.
یک مثال عملی: ۴ مگابایت JPEG به ۴۰۰ کیلوبایت
یک JPEG با ۴ مگابایت مستقیم از دوربین گوشی یک payload رایج است که سقفهای آپلود را کند میکند و صفحات را کُند میکند. این یک معیار منصفانه برای آنچه فشردهسازی صرفهجویی میکند است.
JPEG را در ناحیه آپلود بکشید، فرمت را روی JPEG بگذارید، و یا نوار لغزنده کیفیت را به 0.7 بکشید یا به حالت اندازه هدف بروید و 400 KB تایپ کنید. در حالت کیفیت، pipeline Canvas یک بار رمزگذاری مجدد میکند و نتیجه را نشان میدهد، معمولاً حدود ۵۰۰ تا ۷۰۰ کیلوبایت بسته به عکس. در حالت اندازه هدف، صفحه چند مقدار کیفیت را امتحان میکند، روی بالاترینی که همچنان زیر ۴۰۰ کیلوبایت جا میشود مستقر میشود، و درصد صرفهجویی را گزارش میدهد. روی دانلود در کارت کلیک کنید تا فایل تکی را بگیرید، یا روی دانلود .zip کلیک کنید اگر چند تصویر را همزمان فشرده کردید. کل رفتوبرگشت برای تصویری با این اندازه در کمتر از یک ثانیه اجرا میشود و پس از اتمام بارگذاری خود صفحه هیچ پهنای باندی مصرف نمیکند.
تفاوت بین حالت کیفیت و حالت اندازه هدف چیست؟
حالت کیفیت یک نوار لغزنده از ۰.۱ تا ۱.۰ به شما میدهد که به تنظیم کوانتیزاسیون encoder JPEG یا WebP نگاشت میشود — اعداد پایینتر یعنی فایلهای کوچکتر و آرتیفکتهای بیشتر. حالت اندازه هدف مسئله را برعکس میکند: شما یک اندازه به کیلوبایت نام میبرید و صفحه مقدار کیفیت را دوتایی میکند، چند بار رمزگذاری میکند تا بالاترین کیفیتی که همچنان زیر بودجه شما جا میشود را پیدا کند. حالت اندازه هدف وقتی یک سقف سخت اهمیت دارد مفید است (مثلاً محدودیت آپلود ۱ مگابایتی)؛ حالت کیفیت وقتی فقط میخواهید یک نتیجه بصری قابل پیشبینی داشته باشید سریعتر و بهتر است. PNG بیاتلاف است، پس هیچکدام از حالتها برای آن اعمال نمیشود.
آیا این روی دستگاه من انجام میشود؟
بله، کاملاً. صفحه از Canvas API بومی مرورگر و Web File API برای رمزگشایی و رمزگذاری مجدد هر تصویر در حافظه استفاده میکند. هیچ داده تصویری به سرور ارسال نمیشود، هیچ آپلود موقتی، هیچ تور رفتوبرگشت به ابر. میتوانید خودتان تأیید کنید: DevTools را باز کنید، به پنل Network بروید و یک فشردهسازی اجرا کنید. تنها درخواستهای خروجی که میبینید بارگذاری صفحه اولیه و فراخوانیهای تبلیغاتی هستند. هیچ چیز شبیه تصویر از تب خارج نمیشود.
چرا فشرده کردن PNG گاهی اندازه آن را به سختی کاهش میدهد؟
PNG یک فرمت بیاتلاف است، بنابراین Canvas API نمیتواند جزئیات را برای کوچکتر کردن آن دور بیندازد — فقط میتواند همان پیکسلها را دوباره بستهبندی کند. برای عکسها، PNG از همان ابتدا بزرگ است و رمزگذاری مجدد بیاتلاف چیز کمی صرفهجویی میکند. برد واقعی از تغییر فرمت خروجی به JPEG یا WebP میآید که از فشردهسازی lossy مناسب برای عکسها استفاده میکنند و معمولاً ۴ تا ۱۰ برابر کوچکتر میشوند. PNG را فقط وقتی نیاز به کیفیت بیاتلاف یا شفافیت دارید نگه دارید؛ در غیر این صورت برای عکسها JPEG یا برای بهترین تعادل اندازه-کیفیت WebP را انتخاب کنید.
کدام فرمت را باید انتخاب کنم؟
برای عکسها، WebP با کیفیت ۰.۸ بهترین تعادل اندازه-کیفیت را میدهد و توسط هر مرورگر ارسالشده از ۲۰۲۱ به بعد پشتیبانی میشود؛ JPEG جایگزین جهانی امن است وقتی مقصد قدیمیتر یا سختگیرتر است. PNG را فقط وقتی نیاز به کیفیت بیاتلاف یا کانال آلفا دارید انتخاب کنید — نقشههای خطی، اسکرینشاتهای UI، لوگوهای با شفافیت. اگر برای سرعت صفحه بهینه میکنید و مخاطبان شما از مرورگرهای مدرن استفاده میکنند، WebP تقریباً همیشه انتخاب درست است؛ اگر CMS قدیمی یا pipeline چاپی دارید که WebP را رد میکند، JPEG بمانید.
تصاویرتان را بکشید، یک سطح کیفیت یا اندازه هدف انتخاب کنید، فشرده کنید. همه چیز در تب شما اجرا میشود. بدون آپلود، بدون حساب کاربری، بدون انتظار در صف سرور.