CDN تصویر چیست؟ تبدیل، تغییر اندازه و کش روی لبه

CDN تصویر چه می‌کند

یک CDN نسخه‌هایی از فایل‌های شما را روی سرورهای نزدیک بازدیدکنندگان نگه می‌دارد و از همان‌جا برایشان می‌فرستد. برای بیشتر فایل‌ها کار همین است: بایت‌هایی که از لبه بیرون می‌روند همان بایت‌هایی هستند که سرور مبدأ شما داده است. CDN تصویر یک گام اضافه می‌کند: میان کش خود و بازدیدکننده می‌تواند خود تصویر را تغییر دهد، و این کار را به چهار دلیل انجام می‌دهد.

قالب. روی عکس‌ها، WebP و AVIF معمولاً خیلی سبک‌تر از فایل JPEG بارگذاری‌شده هستند: در اندازه‌گیری ما یک عکس خبری 262,025 بایتی در قالب WebP به 113,860 بایت و در قالب AVIF به 86,936 بایت رسید. CDN تصویر هر تصویر را به قالبی تبدیل می‌کند که مرورگر بازدیدکننده می‌پذیرد؛ مرورگری که AVIF را نمایش می‌دهد AVIF می‌گیرد و مرورگر قدیمی‌تر هم باز تصویری می‌گیرد که می‌تواند نشانش دهد.

اندازه. گوشی‌ای که عکسی را با عرض 400 پیکسل نشان می‌دهد به فایل بارگذاری‌شدهٔ 2,400 پیکسلی نیازی ندارد. وقتی URL عرض یا ارتفاعی داشته باشد، CDN تصویر تصویر را تا اندازه‌ای که صفحه واقعاً نشان می‌دهد کوچک می‌کند.

فشرده‌سازی. حتی بدون تغییر قالب، کدگذاری دوباره با کیفیتی معقول و حذف داده‌هایی که صفحه‌نمایش هرگز به کار نمی‌برد، از بیشتر فایل‌ها بایت کم می‌کند: همان عکس خبری پس از کدگذاری دوباره در قالب JPEG از 262,025 به 186,137 بایت رسید.

کش. هر نتیجه روی لبه ذخیره می‌شود. تبدیل برای هر نسخه یک بار انجام می‌شود و هر بازدیدکنندهٔ بعدی نسخهٔ ذخیره‌شده را با سرعت عادی CDN می‌گیرد.

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

یک URL، چند قالب: Accept و Vary

هر درخواست تصویری که مرورگر می‌فرستد یک هدر Accept دارد که قالب‌هایی را که می‌تواند نمایش دهد فهرست می‌کند. Chrome مقدار image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8 را می‌فرستد؛ مرورگری که از AVIF پشتیبانی نمی‌کند image/avif را نمی‌آورد. CDN تصویر این فهرست را در هر درخواست می‌خواند و به همان URL با AVIF، WebP یا قالب اصلی پاسخ می‌دهد. نام فایل تغییر نمی‌کند، پس photo.jpg ممکن است به‌صورت AVIF برسد: آنچه واقعاً فرستاده شده را هدر Content-Type می‌گوید.

چون یک URL حالا چند پاسخ درست دارد، پاسخ باید این را با Vary: Accept اعلام کند. این هدر به هر کشی میان لبه و بازدیدکننده، از پراکسی یک شرکت تا کش خود مرورگر، می‌گوید که پاسخ به Accept بستگی دارد. بدون آن، یک کش مشترک ممکن است فایل AVIFی را که یک بازدیدکننده گرفته نگه دارد و به بازدیدکنندهٔ بعدی بدهد که مرورگرش نمی‌تواند آن را رمزگشایی کند.

کش خود CDN هم از همین قاعده پیروی می‌کند و اینجا یک جزئیات مهم است. رشته‌های Accept از مرورگری به مرورگر دیگر و حتی میان نسخه‌های یک مرورگر فرق می‌کنند، پس کشی که خود هدر خام را کلید می‌گیرد برای هر نگارش یک نسخهٔ تقریباً یکسان نگه می‌دارد. یک CDN تصویر خوش‌ساخت هدر را به تصمیمی که در خود دارد (AVIF، WebP یا هیچ‌کدام) فرو می‌کاهد و برای هر کدام یک نسخه نگه می‌دارد.

راه دیگر این است که انتخاب در HTML انجام شود: یک عنصر <picture> یک <source> با AVIF و یکی با WebP فهرست می‌کند و مرورگر اولین نوعی را که پشتیبانی می‌کند برمی‌دارد. این راه به مذاکرهٔ قالب نیازی ندارد، اما هر نسخه را خودتان می‌سازید، نگه می‌دارید و در نشانه‌گذاری می‌آورید. با CDN تصویر نشانه‌گذاری یک <img> ساده باقی می‌ماند؛ <picture> همچنان ابزار جهت‌دهی هنری است، یعنی وقتی گوشی باید برش متفاوتی از تصویر بگیرد نه نسخهٔ کوچک‌تری از همان تصویر.

تغییر اندازه با URL

مذاکرهٔ قالب به هیچ تغییری در صفحه‌های شما نیاز ندارد؛ اما تغییر اندازه نیاز دارد، چون فقط صفحه می‌داند تصویر با چه عرضی نمایش داده می‌شود. CDNهای تصویر اندازه را از URL می‌گیرند، معمولاً به‌شکل پارامترهای کوئری: photo.jpg?w=640 یک نسخه با عرض 640 پیکسل می‌خواهد. یک سرویس معقول وقتی فقط یک بُعد بدهید نسبت ابعاد را حفظ می‌کند، وقتی هر دو را بدهید تصویر را درون آن کادر جا می‌دهد و هیچ تصویری را از اندازهٔ اصلی‌اش بزرگ‌تر نمی‌کند.

همراه با srcset و sizes، یک فایل منبع برای همهٔ صفحه‌نمایش‌ها کافی است. چند عرض از همان URL را فهرست می‌کنید و می‌گویید تصویر با چه عرضی نمایش داده می‌شود، و مرورگر کوچک‌ترین نسخه‌ای را دانلود می‌کند که با تراکم صفحه‌نمایش بازدیدکننده هنوز واضح دیده شود. CDN تصویر هر عرض فهرست را نخستین باری که کسی درخواستش کند می‌سازد و از آن به بعد از کش می‌دهد.

فهرست را کوتاه و ثابت نگه دارید. هر عرض متفاوت یک تبدیل جداگانه و یک شیء جداگانه در کش است، پس پنج عرض که در کل سایت به کار می‌روند خیلی بهتر از عددهایی کش می‌شوند که هر تمپلیت جداگانه حساب می‌کند. برخی سرویس‌ها پارامترهای دیگری مثل برش، کیفیت یا نقطهٔ کانونی هم می‌گیرند و هر کدام به همین شکل تعداد نسخه‌ها را چند برابر می‌کند.

یک تصویر منبع، پنج عرض: مرورگر همانی را که لازم دارد برمی‌دارد

<img
  src="https://example.com/media/photo.jpg?w=960"
  srcset="https://example.com/media/photo.jpg?w=320 320w,
          https://example.com/media/photo.jpg?w=640 640w,
          https://example.com/media/photo.jpg?w=960 960w,
          https://example.com/media/photo.jpg?w=1280 1280w,
          https://example.com/media/photo.jpg?w=1920 1920w"
  sizes="(max-width: 720px) 100vw, 720px"
  width="1920" height="1080" alt="">

هر نسخه یک شیء جداگانه در کش است

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

کلید کش باید اندازه را در بر داشته باشد. اگر قانونی برای بالا بردن نرخ اصابت رشتهٔ کوئری را نادیده بگیرد، ?w=320 و ?w=1920 یک کلید مشترک پیدا می‌کنند و اندازه‌ای که اول درخواست شده برای همه ارسال می‌شود. پارامترهای اندازه را در کلید نگه دارید، حتی اگر پارامترهای دیگر را کنار می‌گذارید.

هزینهٔ تبدیل را اولین درخواست می‌پردازد. نسخه‌ای که هنوز کسی درخواستش نکرده هنگام درخواست ساخته می‌شود: لبه فایل اصلی را می‌آورد، کدگذاری می‌کند و نتیجه را کش می‌کند. همان بازدیدکننده کمی بیشتر صبر می‌کند؛ همهٔ کسانی که بعد از او می‌آیند نسخهٔ کش‌شده را می‌گیرند. برای صفحه‌هایی که باید از همان نمایش اول سریع باشند، چند درخواست پس از deploy یا پاکسازی، کش را از پیش گرم می‌کند.

پاکسازی و انقضا شامل کل خانواده می‌شود. وقتی یک فایل اصلی با همان نام تغییر می‌کند، هر قالب و هر اندازه‌ای که از آن ساخته شده باید برود. پاکسازی با پیشوند مسیر به همهٔ آن‌ها می‌رسد؛ پاکسازی یک URL دقیق ممکن است نسخه‌های تغییراندازه‌یافته را جا بگذارد. روشن کردن تبدیل حالت ساده است: وقتی قالب بخشی از کلید کش باشد، هر نسخهٔ تبدیل‌شده یک شیء تازه است و از همان اولین درخواست ارسال می‌شود. فقط نسخه‌هایی که از قبل در مرورگر بازدیدکنندگان هستند، تا وقتی همان‌جا منقضی شوند، دست‌نخورده می‌مانند.

کیفیت و حجم: تبدیل کِی می‌بازد

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

قالب به اندازهٔ تنظیم اهمیت دارد و برنده با تصویر عوض می‌شود. در 5 اکتبر 2026 سه تصویر را با تنظیمات تولید از بهینه‌ساز تصویرِ پشت CDN.com.tr گذراندیم و بایت‌ها را شمردیم.

عکس خبری، JPEG. اصلی 262,025 بایت؛ WebP برابر 113,860؛ AVIF برابر 86,936. نمونهٔ کتابی: AVIF همان تصویر را با حدود یک‌سوم بایت‌های فایل اصلی می‌رساند.

اسکرین‌شات پنل، PNG. اصلی 105,078 بایت؛ PNG بهینه‌شده 40,379؛ WebP برابر 41,218؛ AVIF برابر 27,942. PNG پالت‌دار در رنگ‌های تخت و متن بسیار خوب است و اینجا WebP از آن بزرگ‌تر شد؛ با این حال AVIF برنده شد.

فاویکون، PNG، در ابعاد 16×16. اصلی 701 بایت؛ PNG بهینه‌شده 483؛ WebP برابر 314؛ AVIF برابر 682. در این اندازه، سربار ثابت محفظهٔ AVIF بر فشرده‌سازی بهترش می‌چربد و WebP با اختلاف روشن می‌برد.

هیچ قالبی همه‌جا نمی‌برد و یک تبدیل ممکن است فایلی سنگین‌تر از بهترین نسخهٔ فایل اصلی بسازد. یک CDN تصویر خوب کدگذاری می‌کند، بایت‌ها را مقایسه می‌کند و فایل کوچک‌تر را می‌فرستد؛ سرویسی که چشم‌بسته تبدیل می‌کند بخشی از تصاویر شما را سنگین‌تر می‌کند و باز هم آن‌ها را بهینه‌شده گزارش می‌دهد. همهٔ اندازه‌گیری‌ها و دلیل‌هایشان در راهنمای AVIF یا WebP ما آمده است.

CDN تصویر یا بهینه‌سازی در زمان build؟

همین قالب‌ها را بدون CDN تصویر هم می‌توانید به دست آورید. یک گام build، یک هوک بارگذاری یا یک افزونه می‌تواند هر تصویر را یک بار تبدیل کند، نسخه‌ها را کنار فایل‌های اصلی بنویسد و بگذارد یک CDN معمولی آن‌ها را با نشانه‌گذاری <picture> تحویل دهد. کدام راه بهتر است به این بستگی دارد که تصاویرتان از کجا می‌آیند.

بهینه‌سازی در زمان build برنده است در سایتی که تصاویرش در مخزن کد هستند: یک سایت معرفی، مستندات، یک اپلیکیشن ایستا. مجموعه از پیش معلوم است، هر فایل را می‌شود دستی تنظیم کرد، هیچ چیز در حالی که بازدیدکننده منتظر است پردازش نمی‌شود و آنچه ارسال می‌شود دقیقاً همان است که آزموده‌اید.

CDN تصویر برنده است وقتی تصاویر سریع‌تر از آن می‌رسند که کسی بتواند پردازششان کند: عکس محصولاتی که از پنل مدیریت یک فروشگاه بارگذاری می‌شوند، آرشیو یک سایت خبری، کتابخانهٔ رسانهٔ WordPress با بارگذاری‌های چندساله، تصاویری که کاربرانتان منتشر می‌کنند. همچنین وقتی تعداد اندازه‌ها با هر طراحی تازه بیشتر می‌شود، وقتی نشانه‌گذاری را یک پوسته یا یک CMS میزبانی‌شده می‌نویسد و وقتی ترجیح می‌دهید مبدلی روی سرور خودتان اجرا نکنید، برنده است.

این دو به‌خوبی با هم جمع می‌شوند: تصاویر اصلی صفحه که دستی تنظیم شده‌اند از build، و هر چه از راه CMS بارگذاری می‌شود از CDN تصویر. لوگوها و آیکون‌هایی که طراحی شده‌اند نه عکاسی، در هر دو حالت بهتر است SVG بمانند: چیزی برای تبدیل ندارند و در هر اندازه‌ای واضح می‌مانند.

دام‌هایی که پیش از روشن کردن باید بررسی کرد

بیشتر دردسرهای CDNهای تصویر از چند جای مشخص می‌آید و هر کدام را می‌شود پیش از آنکه بازدیدکننده‌ای متوجه شود بررسی کرد.

نبود Vary. پاسخی که با Accept تغییر می‌کند ولی Vary: Accept ندارد، در این فهرست همان خطایی است که می‌تواند به بازدیدکننده تصویر خراب نشان دهد. بررسی کنید CDN شما چه می‌فرستد و هر پراکسی جلوی آن چه چیزی را عبور می‌دهد.

پارامترهای اندازه بیرون از کلید کش. یک اندازه برای همه: دو عرض از یک تصویر را درخواست کنید و آنچه برمی‌گردد را مقایسه کنید.

پارامترهای بی‌حد. اگر هر عرضی پذیرفته شود، هر کسی می‌تواند هزاران اندازه درخواست کند و هزینهٔ هر تبدیل را به گردن شما بیندازد. یک فهرست ثابت از عرض‌ها در تمپلیت‌های صفحه‌تان صفحه‌های خودتان را به چند نسخه محدود می‌کند؛ اما درخواست‌هایی را که از بیرون می‌آیند فقط محدودیتی در سمت سرویس متوقف می‌کند، مثل فهرستی از عرض‌های مجاز یا محدودیت نرخ درخواست.

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

قالب‌هایی که دست‌نخورده عبور می‌کنند. GIFهای متحرک، فایل‌های SVG و تصاویری که از قبل WebP هستند اغلب بی‌تغییر ارسال می‌شوند؛ بررسی کنید سرویس شما کدام قالب‌ها را تبدیل می‌کند.

هزینهٔ پردازش و سهمیه‌ها. کدگذاری، به‌ویژه به AVIF، خیلی بیشتر از فرستادن یک فایل کش‌شده CPU مصرف می‌کند و سرویس‌ها آن را می‌سنجند: به ازای هر تبدیل، به ازای هر بایت پردازش‌شده یا از سهمیهٔ یک پلن. پیش از اینکه همهٔ تصاویر را یک‌جا روشن کنید، بخوانید سرویس شما چطور حساب می‌کند.

نسخه‌های کهنه. تصاویری که مرورگرها پیش از روشن کردن تبدیل بارگذاری کرده‌اند تا زمان انقضا در کش خودشان می‌مانند و هیچ پاکسازی CDN به آن‌ها نمی‌رسد. نتیجه را با یک درخواست تازه، مثل درخواست بررسی‌کنندهٔ زیر، بسنجید، نه با بارگذاری دوبارهٔ صفحه.

بررسی کنید سایت شما چه سرو می‌کند

بررسی‌کنندهٔ زیر نشان می‌دهد یک CDN تصویر، یا نبودنش، با یک صفحهٔ واقعی چه می‌کند. HTML صفحه را می‌خواند، تا 20 تصویر را از <img>، srcset، <picture> و og:image برمی‌دارد و هر کدام را دو بار درخواست می‌کند: یک بار مثل یک مرورگر امروزی (Accept: image/avif,image/webp,…) و یک بار مثل کلاینتی که همه‌چیز را می‌پذیرد (Accept: */*). بایت‌های اول هر پاسخ را می‌خواند تا قالب واقعی را تشخیص دهد، هر چه نام فایل بگوید، بایت‌ها را می‌شمارد و Vary و وضعیت کش را گزارش می‌کند. نشانی یک تصویر تنها را هم می‌توانید وارد کنید.

اگر هر دو درخواست برای همهٔ تصاویر قالب اصلی را بگیرند، چیزی در مسیر تصاویر شما را تبدیل نمی‌کند. اگر درخواست مدرن AVIF یا WebP بگیرد ولی پاسخ Vary: Accept نداشته باشد، اول همان را درست کنید. صفحهٔ خود بررسی‌کننده هر نتیجه و محدودیت‌هایش را توضیح می‌دهد.

بهینه‌سازی تصویر در CDN.com.tr

بهینه‌سازی تصویر یک کلید برای کل حساب یا برای یک قانون تحویل است. edge تصاویر JPEG و PNG را به WebP تبدیل می‌کند، یا اگر برای حساب WebP + AVIF را انتخاب کنید به AVIF و WebP، و هر مرورگر قالبی را می‌گیرد که می‌پذیرد؛ مرورگرهایی که هیچ‌کدام را نمی‌پذیرند تصویر را در قالب اصلی‌اش می‌گیرند. با WebP + AVIF پاسخ از همان URL و با Vary: Accept می‌آید؛ با WebP به‌تنهایی، مرورگرهایی که WebP را می‌پذیرند به یک نسخهٔ .webp هدایت می‌شوند. در هر دو حالت URL تصاویر در HTML شما همان می‌ماند. در اندازه کامل، تصویری که تازه تبدیل شده فقط وقتی ارسال می‌شود که از نسخه اصلی کوچک‌تر باشد. اگر تبدیل شکست بخورد، edge به‌جای آن تصویر اصلی را ارائه می‌دهد. پردازش از سهمیه ماهانه شما کسر می‌شود.

اندازه‌گیری‌های بالا از همین بهینه‌ساز است. با WebP + AVIF عکس خبری 262,025 بایتی به‌صورت 86,936 بایت AVIF ارسال می‌شود و اسکرین‌شات 105,078 بایتی پنل با 27,942 بایت. تصاویر PNG کوچک یا با رنگ‌های تخت تا یک مگاپیکسل (آیکون‌ها، اسکرین‌شات‌ها، تصویرسازی‌ها) باید از PNG بهینه‌شدهٔ خود ما هم کوچک‌تر باشند؛ برای همین مرورگری که WebP را می‌پذیرد ولی AVIF را نه، آن اسکرین‌شات را به‌صورت همان PNG با 40,379 بایت می‌گیرد و فاویکون به‌جای AVIF با 682 بایت، به‌صورت WebP با 314 بایت ارسال می‌شود.

تغییر اندازه با URL انجام می‌شود: ?w=، ?h= یا هر دو را به نشانی تصویر اضافه کنید. یک مقدار نسبت ابعاد را حفظ می‌کند، دو مقدار تصویر را درون آن کادر جا می‌دهند و هیچ تصویری از اندازهٔ اصلی‌اش بزرگ‌تر نمی‌شود. تصاویر تغییراندازه‌یافته هم تبدیل می‌شوند ولی با فایل اصلی مقایسه نمی‌شوند. یک قانون تا وقتی رشتهٔ کوئری را در کلید کش نگه دارد، که حالت پیش‌فرض همین است، w و h را هم در کلید نگه می‌دارد؛ قانونی که همهٔ پارامترهای کوئری را نادیده بگیرد برای همهٔ آن‌ها یک اندازه را کش می‌کند.

نسخه‌هایی که لبه پیش از آمدن مقایسهٔ اندازهٔ کامل تبدیل کرده، همان‌طور که هستند می‌مانند تا منقضی یا پاکسازی شوند، و مرورگرهایی که تصویری را از قبل بارگذاری کرده‌اند نسخهٔ خود را تا زمان انقضا در مرورگر نگه می‌دارند. با WebP به‌تنهایی، هدایت به نسخهٔ .webp هدر Vary: Accept ندارد و همین است که بررسی‌کنندهٔ بالا گزارش می‌کند؛ WebP + AVIF به همهٔ مرورگرها از همان یک URL و با Vary: Accept پاسخ می‌دهد. AVIF با نرخی بالاتر از WebP از سهمیه کسر می‌شود، چون کدگذاری‌اش پردازش بیشتری می‌خواهد؛ پنل نرخ فعلی را زیر کلید نشان می‌دهد. موضوع راهنمای بهینه‌سازی تصویر کلیدها، انتخاب قالب و پاکسازی را گام‌به‌گام توضیح می‌دهد.

WordPress. در یک سایت WordPress پشت CDN.com.tr تبدیل را لبه انجام می‌دهد: تصاویر کتابخانهٔ رسانهٔ شما هنگام عبور از CDN تبدیل می‌شوند، پس سرور شما هیچ CPUای برای کدگذاری صرف نمی‌کند، هیچ فایل WebP یا AVIF اضافه‌ای در کتابخانه نوشته نمی‌شود و پوسته‌ها و صفحه‌سازها به کارشان ادامه می‌دهند، چون URL تصاویر تغییر نمی‌کند. اگر سایتی روی CDN ما نباشد، افزونه رایگان CDNTR می‌تواند تصاویر را روی سرور خود سایت به WebP، و جایی که سرور پشتیبانی کند به AVIF، تبدیل کند. فقط یکی را به کار ببرید: وقتی تبدیل روی لبه روشن است، تبدیل محلی افزونه را خاموش نگه دارید تا لبه از فایل‌های اصلی شما کار کند.