ممکن است قبلاً با مفهوم اصلی شبکه تحویل محتوا (CDN) آشنا باشید: شبکه ای از سرورهای توزیع شده اما به هم پیوسته که دارایی ها را به سرعت و کارآمد به کاربران تحویل می دهد. هنگامی که یک فایل در یک ارائه دهنده CDN آپلود می شود، یک نسخه تکراری در سایر گره های شبکه CDN در سراسر جهان ایجاد می شود. زمانی که کاربر فایلی را درخواست می کند، داده ها توسط گره ای که از نظر جغرافیایی نزدیک به آن کاربر است ارسال می شود و تاخیر را کاهش می دهد. ماهیت توزیع شده CDN ها همچنین در صورت قطع شدن شبکه یا خرابی سخت افزار، افزونگی را فراهم می کند و تعادل بار را برای کاهش جهش در ترافیک فراهم می کند.
یک CDN تصویر میتواند همه این مزایا را با یک تفاوت کلیدی ارائه دهد: توانایی تبدیل و بهینهسازی محتوای یک تصویر بر اساس رشتههایی از URL استفاده شده برای دسترسی به آن.
کاربر یک تصویر متعارف و با وضوح بالا را در ارائه دهنده آپلود می کند که URL مورد استفاده برای دسترسی به آن ایجاد می کند:
https://res.cloudinary.com/demo/image/upload/sample.jpg
اگرچه نحو دقیق استفاده شده از ارائه دهنده ای به ارائه دهنده دیگر متفاوت است، حداقل همه CDN های تصویر به شما امکان می دهند ابعاد، کدگذاری و تنظیمات فشرده سازی تصویر منبع را تغییر دهید. برای مثال، کلودیناری تغییر اندازه پویا یک تصویر آپلود شده را از طریق نحوهای زیر انجام می دهد: h_
به دنبال آن ارتفاع عددی بر حسب پیکسل، w_
به دنبال عرض، و یک مقدار c_
که به شما امکان می دهد اطلاعات دقیقی را در مورد نحوه مقیاس بندی تصویر مشخص کنید. یا بریده شده .
هر تعداد تبدیل را می توان با افزودن مقادیر جدا شده با کاما به URL، قبل از نام فایل و پسوند اعمال کرد، به این معنی که تصویر آپلود شده را می توان در صورت نیاز از طریق src
عنصر img
که آن را درخواست می کند، دستکاری کرد.
<img src="https://res.cloudinary.com/demo/image/upload/w_400/sample.jpg" alt="…">
اولین باری که کاربر از URL حاوی این تبدیلها بازدید میکند، نسخه جدیدی از تصویر به نسبت عرض 400 پیکسل ( w_400
) تولید و ارسال میشود. آن فایل تازه ایجاد شده سپس در سراسر CDN ذخیره میشود تا بتوان آن را به هر کاربری که همان URL را درخواست میکند ارسال کرد، نه اینکه بنا به درخواست دوباره ایجاد شود.
اگرچه برای ارائه دهندگان CDN تصویر غیر معمول نیست که کیت های توسعه نرم افزار را برای تسهیل استفاده پیشرفته و ادغام با پشته های فناوری مختلف ارائه دهند، این الگوی URL قابل پیش بینی به تنهایی به ما اجازه می دهد تا به راحتی یک فایل آپلود شده را به یک ویژگی srcset
قابل دوام تبدیل کنیم بدون اینکه نیازی به ابزار توسعه دیگری داشته باشیم. :
<img
src="https://res.cloudinary.com/demo/image/upload/w_1000/sample.jpg 1000w"
srcset="https://res.cloudinary.com/demo/image/upload/w_1000/sample.jpg 1000w,
https://res.cloudinary.com/demo/image/upload/w_800/sample.jpg 800w,
https://res.cloudinary.com/demo/image/upload/w_600/sample.jpg 600w"
alt="…">
ما میتوانیم به صورت دستی سطح فشردهسازی مورد نظر خود را با استفاده از نحوی که اکنون باید یک نحو آشنا باشد، مشخص کنیم: q_
، مخفف «کیفیت»، و سپس مخفف عددی برای سطح فشردهسازی:
<img src="https://res.cloudinary.com/demo/image/upload/w_400,q_60/sample.jpg" alt="…">
به ندرت پیش میآید که به لطف مجموعهای از ویژگیهای فوقالعاده قدرتمند ارائهشده توسط اکثر CDNهای تصویر: فشردهسازی، کدگذاری، و مذاکره محتوا بهطور کامل خودکار، نیاز داشته باشید این اطلاعات را به صورت دستی درج کنید.
فشرده سازی خودکار
توان محاسباتی CDN های تصویر به این معنی است که آنها می توانند یک ویژگی فوق العاده قدرتمند را ارائه دهند: تجزیه و تحلیل محتوای یک تصویر برای تعیین الگوریتمی سطح فشرده سازی ایده آل و تنظیمات رمزگذاری آن، درست همانطور که شما یا من فشرده سازی را به صورت دستی تنظیم می کنیم. هر یک از تصاویر ما
این الگوریتمها تصمیماتی را که ممکن است اتخاذ کنید برای متعادل کردن اندازه فایل و کیفیت ادراکی خودکار میکنند، محتوای تصویر را برای نشانههای قابل اندازهگیری تجزیه و تحلیل میکنند و تنظیمات فشردهسازی را بر این اساس تنظیم میکنند. این اغلب به معنای کاهش بسیار زیاد در اندازه فایل در مقایسه با رویکرد دستی یکاندازه برای تنظیمات فشردهسازی است.
هر چقدر هم که این فرآیند پیچیده به نظر برسد، پیاده سازی نمی تواند خیلی ساده تر باشد: برای Cloudinary، افزودن q_auto
در URL تصویر این ویژگی را فعال می کند:
<img src="https://res.cloudinary.com/demo/image/upload/w_1400/sample.jpg" alt="…">
<!-- 250 KB-->
<img src="https://res.cloudinary.com/demo/image/upload/w_1400,q_auto/sample.jpg" alt="…">
<!-- 134 KB-->
رمزگذاری خودکار و مذاکره محتوا
پس از دریافت درخواست برای یک تصویر، CDN های تصویر، مدرن ترین رمزگذاری را که مرورگر از طریق سرصفحه های HTTP ارسال شده توسط مرورگر در کنار درخواست دارایی ها – به ویژه هدر Accept
– پشتیبانی می کند، تعیین می کنند. این هدر رمزگذاری هایی را نشان می دهد که مرورگر قادر به درک آنها است، با استفاده از همان انواع رسانه ای که ما برای پر کردن ویژگی type
عنصر <picture>
عنصر <source>
استفاده می کنیم.
به عنوان مثال، افزودن پارامتر f_auto
به لیست تبدیلهای تصویر در URL دارایی به صراحت به Cloudinary میگوید که کارآمدترین رمزگذاری را که مرورگر قادر به درک آن است ارائه دهد:
<img src="https://res.cloudinary.com/demo/image/upload/w_1200,q_auto,f_auto/sample.jpg" alt="…">
سپس سرور نسخه ای از تصویر را با آن کدگذاری تولید می کند و نتیجه را برای همه کاربران بعدی با همان سطح پشتیبانی مرورگر در حافظه پنهان ذخیره می کند. این پاسخ شامل یک هدر Content-Type
برای اطلاع صریح مرورگر از رمزگذاری فایل، صرف نظر از پسوند فایل است. حتی اگر یک کاربر با یک مرورگر مدرن درخواستی برای فایلی با .jpg
ارائه کند، این درخواست با یک هدر همراه می شود که به سرور اطلاع می دهد AVIF پشتیبانی می شود و سرور یک فایل رمزگذاری شده AVIF را همراه با یک دستورالعمل صریح ارسال می کند. آن را به عنوان AVIF در نظر بگیرید.
نتیجه خالص فرآیندی است که نه تنها شما را از ایجاد فایلهای کدگذاری شده متناوب و تنظیم دستی تنظیمات فشردهسازی خود (یا حفظ سیستمی که این کارها را برای شما انجام میدهد) معاف میکند، بلکه نیاز به استفاده از <picture>
و را نیز از بین میبرد. ویژگی type
برای تحویل موثر آن فایل ها به کاربران. بنابراین، استفاده از syntaxes srcset
و sizes
به تنهایی میتواند همچنان تصاویری را به کاربران شما ارائه دهد که به عنوان مثال AVIF کدگذاری شدهاند، به WebP (یا JPEG-2000، برای Safari به تنهایی)، بازگشت به معقولترین رمزگذاری قدیمی.
معایب استفاده از CDN تصویر بیشتر لجستیکی است تا فنی، که مهمترین آنها هزینه است. در حالی که برای CDN های تصویر معمول است که برنامه های رایگان با ویژگی های قوی برای استفاده شخصی ارائه دهند، تولید دارایی های تصویر به پهنای باند و فضای ذخیره سازی برای آپلودها، پردازش روی سرور برای تبدیل تصاویر، و فضای اضافی برای نتایج تبدیل حافظه پنهان نیاز دارد—بنابراین استفاده پیشرفته و برنامه های پرترافیک ممکن است به یک طرح پولی نیاز داشته باشند.