شبکه های تحویل محتوا (CDN)

بهبود عملکرد با استفاده از شبکه تحویل محتوا.

کیتی همپنیوس

شبکه های تحویل محتوا (CDN) عملکرد سایت را با استفاده از یک شبکه توزیع شده از سرورها برای ارائه منابع به کاربران بهبود می بخشد. از آنجایی که CDN ها بار سرور را کاهش می دهند، هزینه های سرور را کاهش می دهند و برای مدیریت افزایش ترافیک مناسب هستند. این مقاله نحوه عملکرد CDN ها را مورد بحث قرار می دهد و راهنمایی های مبتنی بر پلت فرم را در مورد انتخاب، پیکربندی و بهینه سازی یک راه اندازی CDN ارائه می دهد.

بررسی اجمالی

شبکه تحویل محتوا شامل شبکه ای از سرورهایی است که برای ارائه سریع محتوا به کاربران بهینه شده اند. اگرچه CDN ها مسلماً برای ارائه محتوای کش شناخته شده هستند، CDN ها همچنین می توانند تحویل محتوای غیر کش را بهبود بخشند. به طور کلی، هرچه تعداد بیشتری از سایت شما توسط CDN ارائه شود، بهتر است.

در سطح بالا، مزایای عملکرد CDN ها از اصول انگشت شماری ناشی می شود: سرورهای CDN نسبت به سرورهای مبدا نزدیکتر به کاربران قرار دارند و بنابراین تأخیر زمان رفت و برگشت (RTT) کمتری دارند. بهینه سازی شبکه به CDN ها اجازه می دهد تا محتوا را سریعتر از زمانی که محتوا "مستقیم" از سرور مبدا بارگیری شده بود، ارائه دهند. در نهایت، کش های CDN نیاز به درخواست برای سفر به سرور مبدا را برطرف می کند.

تحویل منابع

اگرچه ممکن است غیر شهودی به نظر برسد، استفاده از CDN برای ارائه منابع (حتی موارد غیر قابل ذخیره) معمولاً سریعتر از بارگذاری مستقیم منبع توسط کاربر از سرورهای شما خواهد بود.

هنگامی که یک CDN برای تحویل منابع از مبدا استفاده می شود، یک اتصال جدید بین مشتری و یک سرور CDN مجاور برقرار می شود. باقیمانده سفر (به عبارت دیگر، انتقال داده بین سرور CDN و مبدا) از طریق شبکه CDN رخ می دهد - که اغلب شامل اتصالات موجود و پایدار با مبدا است. مزایای این کار دو دسته است: پایان دادن به اتصال جدید تا حد امکان نزدیک به کاربر، هزینه های غیرضروری راه اندازی اتصال را حذف می کند (ایجاد یک اتصال جدید گران است و نیاز به چندین رفت و برگشت دارد). استفاده از یک اتصال از پیش گرم شده اجازه می دهد تا داده ها فوراً با حداکثر توان ممکن منتقل شوند.

برخی از CDN ها با هدایت ترافیک به مبدأ از طریق چندین سرور CDN که در سراسر اینترنت پخش شده اند، این امر را حتی بیشتر بهبود می بخشند. اتصالات بین سرورهای CDN به جای مسیرهایی که توسط پروتکل دروازه مرزی (BGP) تعیین می‌شوند، از طریق مسیرهای قابل اعتماد و بسیار بهینه‌سازی شده رخ می‌دهند. اگرچه BGP پروتکل مسیریابی واقعی اینترنت است، تصمیمات مسیریابی آن همیشه عملکرد محور نیستند. بنابراین، مسیرهای تعیین شده توسط BGP احتمالاً عملکرد کمتری نسبت به مسیرهای تنظیم شده بین سرورهای CDN دارند.

ذخیره سازی

ذخیره منابع روی سرورهای CDN، نیاز به درخواست را برای سفر به مبدأ به منظور ارائه خدمات از بین می برد. در نتیجه، منبع سریعتر تحویل داده می شود. این همچنین بار روی سرور مبدا را کاهش می دهد.

افزودن منابع به حافظه پنهان

متداول ترین روشی که برای پر کردن کش های CDN استفاده می شود، داشتن منابع «کشش» CDN در صورت نیاز است - این به عنوان «کشش مبدا» شناخته می شود. اولین باری که یک منبع خاص از کش درخواست می شود، CDN آن را از سرور مبدا درخواست می کند و پاسخ را در حافظه پنهان نگه می دارد. به این ترتیب، محتویات کش در طول زمان ساخته می شود و منابع غیر کش اضافی درخواست می شود.

حذف منابع از کش

CDN ها از حذف کش برای حذف دوره ای منابع نه چندان مفید از کش استفاده می کنند. علاوه بر این، صاحبان سایت می توانند از پاکسازی برای حذف صریح منابع استفاده کنند.

• تخلیه کش

  کش ها ظرفیت ذخیره سازی محدودی دارند. هنگامی که یک کش به ظرفیت خود نزدیک می شود، با حذف منابعی که اخیراً به آنها دسترسی نداشته یا فضای زیادی را اشغال می کنند، فضا را برای منابع جدید باز می کند. این فرآیند به عنوان تخلیه حافظه پنهان شناخته می شود. حذف منبع از یک کش لزوماً به این معنی نیست که از تمام کش ها در یک شبکه CDN خارج شده است.

• پاکسازی

  پاکسازی (همچنین به عنوان "بی اعتباری کش" شناخته می شود) مکانیزمی برای حذف یک منبع از حافظه نهان CDN بدون نیاز به منتظر ماندن برای منقضی شدن یا خارج شدن آن است. معمولاً از طریق یک API اجرا می شود. پاکسازی در شرایطی که محتوا نیاز به بازپس گیری دارد (به عنوان مثال، تصحیح اشتباهات تایپی، اشتباهات قیمت گذاری، یا مقالات خبری نادرست) بسیار مهم است. علاوه بر این، می‌تواند نقش مهمی در استراتژی ذخیره‌سازی سایت داشته باشد.

  اگر یک CDN از پاکسازی فوری پشتیبانی می کند، پاکسازی می تواند به عنوان مکانیزمی برای مدیریت ذخیره محتوای پویا استفاده شود: محتوای پویا را با استفاده از یک TTL طولانی ذخیره کنید، سپس هر زمان که منبع به روز شد، آن را پاک کنید. به این ترتیب، می‌توان مدت زمان ذخیره‌سازی یک منبع پویا را به حداکثر رساند، علی‌رغم اینکه از قبل نمی‌دانستیم چه زمانی منبع تغییر می‌کند. این تکنیک گاهی اوقات به عنوان "نگهداری نگهدارنده تا گفته شده" شناخته می شود.

  هنگامی که پاکسازی در مقیاس مورد استفاده قرار می‌گیرد، معمولاً همراه با مفهومی به نام «برچسب‌های کش» یا «کلیدهای کش جایگزین» استفاده می‌شود. این مکانیسم به صاحبان سایت اجازه می دهد تا یک یا چند شناسه اضافی (که گاهی اوقات به عنوان "برچسب" نامیده می شود) را با یک منبع ذخیره شده مرتبط کنند. سپس می توان از این برچسب ها برای انجام پاکسازی بسیار دانه ای استفاده کرد. به عنوان مثال، ممکن است یک تگ "footer" به همه منابع (به عنوان مثال، /about ، /blog ) که حاوی پاورقی سایت شما هستند اضافه کنید. هنگامی که پاورقی به روز می شود، به CDN خود دستور دهید تا تمام منابع مرتبط با تگ "footer" را پاک کند.

منابع قابل ذخیره سازی

اینکه آیا و چگونه یک منبع باید کش شود بستگی به عمومی یا خصوصی بودن آن دارد. استاتیک یا پویا

منابع خصوصی و عمومی

• منابع خصوصی

  منابع خصوصی حاوی داده هایی هستند که برای یک کاربر در نظر گرفته شده است و بنابراین نباید توسط CDN ذخیره شوند. منابع خصوصی با هدر Cache-Control: private نشان داده می شوند.

• منابع عمومی

  منابع عمومی حاوی اطلاعات خاص کاربر نیستند و بنابراین توسط CDN قابل کش هستند. اگر منبعی دارای هدر Cache-Control: no-store یا Cache-Control: private نباشد توسط CDN قابل ذخیره سازی در نظر گرفته شود. مدت زمانی که می‌توان یک منبع عمومی را در حافظه پنهان نگه داشت، به تعداد دفعات تغییر دارایی بستگی دارد.

محتوای پویا و ایستا

• محتوای پویا

  محتوای پویا محتوایی است که مرتباً تغییر می کند. پاسخ API و صفحه اصلی فروشگاه نمونه هایی از این نوع محتوا هستند. با این حال، این واقعیت که این محتوا به طور مکرر تغییر می کند، لزوماً مانع از ذخیره آن نمی شود. در طول دوره‌های ترافیک سنگین، ذخیره‌سازی این پاسخ‌ها برای مدت زمان بسیار کوتاه (مثلاً 5 ثانیه) می‌تواند بار روی سرور مبدا را به میزان قابل توجهی کاهش دهد، در حالی که تأثیر کمتری بر تازگی داده‌ها خواهد داشت.

• محتوای ثابت

  محتوای ایستا به ندرت تغییر می کند، اگر هرگز. تصاویر، ویدئوها و کتابخانه های نسخه شده معمولاً نمونه هایی از این نوع محتوا هستند. از آنجایی که محتوای ثابت تغییر نمی کند، باید با مدت زمان طولانی (TTL) - به عنوان مثال، 6 ماه یا 1 سال - در حافظه پنهان ذخیره شود.

انتخاب CDN

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

کارایی

در سطح بالا، استراتژی عملکرد یک CDN را می توان بر حسب معاوضه بین به حداقل رساندن تأخیر و حداکثر کردن نسبت ضربه حافظه پنهان در نظر گرفت. CDN هایی با نقاط حضور زیاد (PoP) می توانند تأخیر کمتری ارائه دهند، اما ممکن است در نتیجه تقسیم ترافیک در کش های بیشتر، نسبت ضربه حافظه پنهان کمتری را تجربه کنند. برعکس، CDN هایی با PoP کمتر ممکن است از نظر جغرافیایی دورتر از کاربران قرار داشته باشند، اما می توانند به نسبت ضربه های کش بالاتری دست یابند.

در نتیجه این مبادله، برخی از CDN ها از یک رویکرد لایه بندی شده برای ذخیره سازی استفاده می کنند: PoP های واقع در نزدیکی کاربران (همچنین به عنوان "کش های لبه" شناخته می شوند) با PoP های مرکزی که نسبت ضربه های کش بالاتری دارند تکمیل می شوند. هنگامی که یک کش لبه نتواند منبعی را پیدا کند، به دنبال یک PoP مرکزی برای منبع می‌گردد. این رویکرد تاخیر کمی بیشتر را برای احتمال بالاتری مبادله می کند که منبع بتواند از یک حافظه پنهان CDN ارائه شود - البته نه لزوماً یک کش لبه.

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

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

اثرات روی بزرگترین رنگ محتوایی (LCP)

همانطور که قبلاً در این مقاله ذکر شد، هدف اصلی یک CDN کاهش تأخیر با توزیع منابع به سرورهایی است که از نظر جغرافیایی به کاربران نزدیک‌تر هستند. به همین دلیل، مزیت اصلی CDN این است که عملکرد بارگذاری را بهبود می بخشد. به طور خاص، زمان یک منبع برای اولین بایت (TTFB) می تواند به طور قابل توجهی در هنگام معرفی یک CDN در معماری سمت سرور وب سایت شما بهبود یابد.

در حالی که TTFB یک معیار عملکرد کاربر محور نیست، اما معیار مهمی برای تشخیص مشکلات با بزرگترین رنگ محتوایی (LCP) است که یک معیار کاربر محور است.

CDN ها به ویژه در بهبود LCP موثر هستند، زیرا می توانند هم تحویل سند (با کاهش TTFB در تنظیم اتصال و در حافظه پنهان سند) و هم در بهبود تحویل هر گونه منابع استاتیک مورد نیاز برای ارائه عنصر LCP را بهبود بخشند.

ویژگی های اضافی

CDN ها معمولاً علاوه بر ارائه CDN اصلی خود، طیف گسترده ای از ویژگی ها را ارائه می دهند. ویژگی های معمول ارائه شده عبارتند از: متعادل سازی بار، بهینه سازی تصویر، پخش ویدئو، محاسبات لبه، و محصولات امنیتی.

نحوه راه اندازی و پیکربندی CDN

در حالت ایده آل شما باید از CDN برای سرویس دهی به کل سایت خود استفاده کنید. در سطح بالا، فرآیند راه‌اندازی برای این شامل ثبت‌نام با یک ارائه‌دهنده CDN، سپس به‌روزرسانی رکورد CNAME DNS برای اشاره به ارائه‌دهنده CDN است. برای مثال، رکورد CNAME برای www.example.com ممکن است به example.my-cdn.com اشاره کند. در نتیجه این تغییر DNS، ترافیک سایت شما از طریق CDN هدایت می شود.

اگر استفاده از CDN برای سرویس دهی به همه منابع گزینه ای نیست، می توانید یک CDN را طوری پیکربندی کنید که فقط زیرمجموعه ای از منابع را ارائه دهد - به عنوان مثال، فقط منابع ایستا. شما می توانید این کار را با ایجاد یک رکورد CNAME جداگانه انجام دهید که فقط برای منابعی که باید توسط CDN ارائه شوند استفاده می شود. برای مثال، ممکن است یک رکورد CNAME static.example.com ایجاد کنید که به example.my-cdn.com اشاره می کند. همچنین باید URL منابعی که توسط CDN ارائه می شوند را بازنویسی کنید تا به زیر دامنه static.example.com که ایجاد کرده اید اشاره کنند.

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

بهبود نسبت ضربه کش

یک راه‌اندازی مؤثر CDN تا آنجا که ممکن است از حافظه پنهان استفاده می‌کند. این معمولاً با نسبت ضربه کش (CHR) اندازه گیری می شود. نسبت ضربه کش به عنوان تعداد بازدیدهای حافظه پنهان تقسیم بر تعداد کل درخواست ها در یک بازه زمانی معین تعریف می شود.

یک کش تازه اولیه دارای CHR 0 خواهد بود اما با پر شدن حافظه پنهان با منابع این مقدار افزایش می یابد. CHR 90% یک هدف خوب برای اکثر سایت ها است. ارائه دهنده CDN شما باید تجزیه و تحلیل و گزارش در مورد CHR را به شما ارائه دهد.

هنگام بهینه سازی CHR، اولین چیزی که باید تأیید شود این است که تمام منابع قابل کش برای مدت زمان درست در کش و کش ذخیره می شوند. این یک ارزیابی ساده است که باید توسط همه سایت ها انجام شود.

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

ممیزی اولیه

اکثر CDN ها تجزیه و تحلیل کش را ارائه می دهند. علاوه بر این، ابزارهایی مانند WebPageTest و Lighthouse نیز می‌توانند برای تأیید سریع اینکه تمام منابع استاتیک یک صفحه برای مدت زمان درست در حافظه پنهان ذخیره می‌شوند، استفاده شوند. این کار با بررسی هدرهای حافظه پنهان HTTP هر منبع انجام می شود. ذخیره یک منبع با استفاده از حداکثر زمان مناسب برای زندگی (TTL) از واکشی مبدا غیر ضروری در آینده جلوگیری می کند و بنابراین CHR را افزایش می دهد.

حداقل، یکی از این هدرها معمولاً باید تنظیم شود تا یک منبع توسط CDN کش شود:

• Cache-Control: max-age=
• Cache-Control: s-maxage=
• Expires

علاوه بر این، اگرچه تأثیری بر اینکه یا چگونه یک منبع توسط CDN ذخیره می شود یا نه، تأثیری ندارد، تمرین خوبی است که دستورالعمل Cache-Control: immutable نیز تنظیم کنید. Cache-Control: immutable نشان می دهد که یک منبع "در طول عمر تازه اش به روز نمی شود". در نتیجه، مرورگر هنگام ارائه منبع از حافظه پنهان مرورگر، آن را مجدداً تأیید نمی کند و در نتیجه درخواست غیر ضروری سرور را حذف می کند. متأسفانه، این دستورالعمل فقط توسط فایرفاکس و سافاری پشتیبانی می شود - توسط مرورگرهای مبتنی بر Chromium پشتیبانی نمی شود. این مشکل پشتیبانی Chromium را برای Cache-Control: immutable ردیابی می‌کند. ستاره دار کردن این موضوع می تواند به تشویق پشتیبانی از این ویژگی کمک کند.

برای توضیح بیشتر در مورد حافظه پنهان HTTP، به جلوگیری از درخواست‌های غیر ضروری شبکه با حافظه پنهان HTTP مراجعه کنید.

تنظیم دقیق

توضیح کمی ساده شده در مورد نحوه کار کش های CDN این است که URL یک منبع به عنوان کلید برای کش کردن و بازیابی منبع از حافظه پنهان استفاده می شود. در عمل، این هنوز هم کاملاً درست است، اما با تأثیر چیزهایی مانند سرصفحه‌های درخواست و پارامترهای پرس و جو کمی پیچیده است. در نتیجه، بازنویسی URL های درخواست یک تکنیک مهم برای به حداکثر رساندن CHR و اطمینان از ارائه محتوای صحیح به کاربران است. یک نمونه CDN که به درستی پیکربندی شده باشد، تعادل درستی بین ذخیره سازی بیش از حد دانه ای (که به CHR آسیب می زند) و ذخیره سازی دانه ای ناکافی (که منجر به ارائه پاسخ های نادرست به کاربران می شود) برقرار می کند.

پارامترهای پرس و جو

به طور پیش فرض، CDN ها پارامترهای پرس و جو را هنگام ذخیره یک منبع در نظر می گیرند. با این حال، تنظیمات کوچک در رسیدگی به پارامترهای پرس و جو می تواند تأثیر قابل توجهی بر CHR داشته باشد. مثلا:

• پارامترهای پرس و جو غیر ضروری

  به‌طور پیش‌فرض، یک CDN example.com/blog و example.com/blog?referral_id=2zjk را به‌طور جداگانه ذخیره می‌کند، حتی اگر احتمالاً منبع اصلی یکسانی باشند. این با تنظیم پیکربندی CDN برای نادیده گرفتن پارامتر query referral\_id برطرف می‌شود.

• دستور پارامتر را پرس و جو کنید

  یک CDN example.com/blog?id=123&query=dogs جداگانه از example.com/blog?query=dogs&id=123 ذخیره می‌کند. برای اکثر سایت ها، ترتیب پارامترهای پرس و جو مهم نیست، بنابراین پیکربندی CDN برای مرتب کردن پارامترهای پرس و جو (در نتیجه عادی سازی URL مورد استفاده برای ذخیره پاسخ سرور) باعث افزایش CHR می شود.

متفاوت

هدر پاسخ Vary به حافظه پنهان اطلاع می دهد که پاسخ سرور مربوط به یک URL خاص می تواند بسته به هدرهای تنظیم شده روی درخواست متفاوت باشد (به عنوان مثال، هدرهای درخواست Accept-Language یا Accept-Encoding ). در نتیجه، به یک CDN دستور می‌دهد که این پاسخ‌ها را جداگانه ذخیره کند. هدر Vary به طور گسترده توسط CDN ها پشتیبانی نمی شود و ممکن است منجر به عدم ارائه منبع قابل ذخیره کشی از یک کش شود.

اگرچه هدر Vary می تواند ابزار مفیدی باشد، استفاده نامناسب به CHR آسیب می رساند. علاوه بر این، اگر Vary استفاده می کنید، عادی سازی هدرهای درخواست به بهبود CHR کمک می کند. به عنوان مثال، بدون عادی سازی سرفصل های درخواست Accept-Language: en-US و Accept-Language: en-US,en;q=0.9 منجر به دو ورودی کش جداگانه می شود، حتی اگر محتویات آنها احتمالاً یکسان باشد.

بیسکویت ها

کوکی ها بر اساس درخواست ها از طریق هدر Cookie تنظیم می شوند. آنها بر روی پاسخ ها از طریق هدر Set-Cookie تنظیم می شوند. با توجه به اینکه کش ها معمولاً پاسخ های سرور حاوی این هدر را ذخیره نمی کنند، باید از استفاده غیرضروری از هدر Set-Cookie اجتناب شود.

ویژگی های عملکردی

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

فشرده سازی

تمام پاسخ های متنی باید با gzip یا Brotli فشرده شوند. اگر حق انتخاب دارید، Brotli را از gzip انتخاب کنید. بروتلی یک الگوریتم فشرده سازی جدیدتر است و در مقایسه با gzip، می تواند به نسبت فشرده سازی بالاتری دست یابد.

دو نوع پشتیبانی CDN برای فشرده سازی Brotli وجود دارد: «بروتلی از مبدا» و «فشرده سازی خودکار بروتلی».

بروتلی از مبدأ

Brotli از مبدا زمانی است که یک CDN منابعی را ارائه می دهد که توسط مبدا فشرده شده اند. اگرچه ممکن است این ویژگی به نظر برسد که همه CDN ها باید خارج از جعبه آن را پشتیبانی کنند، اما مستلزم آن است که یک CDN بتواند چندین نسخه (به عبارت دیگر، نسخه های فشرده شده با gzip و نسخه های فشرده شده با Brotli) از منبع مربوط به حافظه پنهان را ذخیره کند. یک URL داده شده

فشرده سازی خودکار بروتلی

فشرده سازی خودکار Brotli زمانی است که منابع Brotli توسط CDN فشرده می شوند. CDN ها می توانند منابع کش و غیر قابل ذخیره سازی را فشرده کنند.

اولین باری که یک منبع درخواست می شود با استفاده از فشرده سازی "به اندازه کافی خوب" ارائه می شود - به عنوان مثال، Brotli-5. این نوع فشرده‌سازی برای منابع ذخیره‌سازی و غیرقابل ذخیره‌سازی قابل اعمال است.

در همین حال، اگر منبعی قابل ذخیره باشد، CDN از پردازش آفلاین برای فشرده سازی منبع در سطح فشرده سازی قدرتمندتر اما بسیار کندتر استفاده می کند - به عنوان مثال، Brotli-11. پس از تکمیل این فشرده سازی، نسخه فشرده تر ذخیره می شود و برای درخواست های بعدی استفاده می شود.

بهترین روش های فشرده سازی

سایت هایی که می خواهند عملکرد را به حداکثر برسانند باید فشرده سازی Brotli را هم در سرور مبدا و هم در CDN خود اعمال کنند. فشرده سازی Brotli در مبدا، حجم انتقال منابعی را که نمی توان از حافظه پنهان ارائه کرد، به حداقل می رساند. برای جلوگیری از تاخیر در ارائه درخواست ها، منبع باید منابع پویا را با استفاده از یک سطح فشرده سازی نسبتا محافظه کار فشرده کند - به عنوان مثال، Brotli-4. منابع استاتیک را می توان با استفاده از Brotli-11 فشرده کرد. اگر منبعی از Brotli پشتیبانی نمی کند، gzip-6 می تواند برای فشرده سازی منابع پویا استفاده شود. gzip-9 می تواند برای فشرده سازی منابع استاتیک استفاده شود.

TLS 1.3

TLS 1.3 جدیدترین نسخه امنیت لایه حمل و نقل (TLS) ، پروتکل رمزنگاری مورد استفاده توسط HTTPS است. TLS 1.3 در مقایسه با TLS 1.2 حریم خصوصی و عملکرد بهتری را ارائه می دهد.

TLS 1.3 دست دادن TLS را از دو رفت و برگشت به یک سفر کوتاه می کند. برای اتصالات با استفاده از HTTP/1 یا HTTP/2، کوتاه کردن دست دادن TLS به یک رفت و برگشت، زمان راه اندازی اتصال را تا 33 درصد کاهش می دهد.

HTTP/2 و HTTP/3

HTTP/2 و HTTP/3 هر دو مزایای عملکردی نسبت به HTTP/1 دارند. از بین این دو، HTTP/3 مزایای عملکرد بالقوه بیشتری را ارائه می دهد. HTTP/3 هنوز به طور کامل استاندارد نشده است، اما پس از این اتفاق به طور گسترده پشتیبانی می شود.

HTTP/2

اگر CDN شما قبلاً HTTP/2 را به طور پیش فرض فعال نکرده است، باید آن را روشن کنید. HTTP/2 مزایای عملکردی متعددی را نسبت به HTTP/1 ارائه می‌کند و توسط همه مرورگرهای اصلی پشتیبانی می‌شود. ویژگی های عملکرد HTTP/2 عبارتند از: چندگانه سازی ، اولویت بندی جریان ، و فشرده سازی هدر .

• مالتی پلکس کردن

  Multiplexing مسلما مهمترین ویژگی HTTP/2 است. Multiplexing یک اتصال TCP را قادر می سازد تا چندین جفت درخواست-پاسخ را همزمان ارائه دهد. این امر هزینه های سربار تنظیمات اتصال غیر ضروری را حذف می کند. با توجه به اینکه تعداد اتصالاتی که یک مرورگر می‌تواند در یک زمان معین باز کند محدود است، این نیز به این معنی است که مرورگر اکنون می‌تواند منابع بیشتری از یک صفحه را به صورت موازی درخواست کند. Multiplexing از لحاظ نظری نیاز به بهینه سازی HTTP/1 مانند الحاق و صفحات sprite را از بین می برد - با این حال، در عمل، با توجه به اینکه فایل های بزرگتر بهتر فشرده می شوند، این تکنیک ها مرتبط باقی خواهند ماند.

• اولویت بندی جریان

  Multiplexing چندین جریان همزمان را فعال می کند. اولویت بندی جریان یک رابط برای ارتباط اولویت نسبی هر یک از این جریان ها فراهم می کند. این به سرور کمک می کند تا مهم ترین منابع را ابتدا ارسال کند - حتی اگر آنها ابتدا درخواست نشده باشند.

اولویت‌بندی جریان توسط مرورگر از طریق درخت وابستگی بیان می‌شود و صرفاً یک بیانیه ترجیحی است: به عبارت دیگر، سرور موظف به رعایت (یا حتی در نظر گرفتن) اولویت‌های ارائه شده توسط مرورگر نیست. اولویت بندی جریان زمانی موثرتر می شود که تعداد بیشتری از یک سایت از طریق CDN ارائه شود.

پیاده سازی CDN اولویت بندی منابع HTTP/2 بسیار متفاوت است. برای شناسایی اینکه آیا CDN شما به‌طور کامل و درست از اولویت‌بندی منابع HTTP/2 پشتیبانی می‌کند، بررسی کنید آیا HTTP/2 هنوز سریع است؟ .

اگرچه تغییر نمونه CDN خود به HTTP/2 عمدتاً مربوط به چرخاندن سوئیچ است، مهم است که این تغییر را قبل از فعال کردن آن در تولید کاملاً آزمایش کنید. HTTP/1 و HTTP/2 از قراردادهای یکسانی برای سرصفحه‌های درخواست و پاسخ استفاده می‌کنند - اما HTTP/2 زمانی که این قراردادها رعایت نمی‌شوند بسیار کمتر بخشنده است. در نتیجه، روش‌های غیرمشخص مانند شامل نویسه‌های غیرASCII یا بزرگ در سرصفحه‌ها ممکن است پس از فعال شدن HTTP/2 باعث ایجاد خطا شوند. اگر این اتفاق بیفتد، تلاش مرورگر برای دانلود منبع با شکست مواجه خواهد شد. تلاش دانلود ناموفق در برگه "شبکه" DevTools قابل مشاهده خواهد بود. علاوه بر این، پیام خطای "ERR_HTTP2_PROTOCOL_ERROR" در کنسول نمایش داده می شود.

HTTP/3

HTTP/3 جانشین HTTP/2 است. از سپتامبر 2020، همه مرورگرهای اصلی از HTTP/3 پشتیبانی آزمایشی دارند و برخی CDN ها از آن پشتیبانی می کنند. عملکرد مزیت اصلی HTTP/3 نسبت به HTTP/2 است. به طور خاص، HTTP/3 مسدود کردن سر خط در سطح اتصال را حذف می کند و زمان راه اندازی اتصال را کاهش می دهد.

• رفع انسداد سر خط

  HTTP/2 مالتی پلکسی را معرفی کرد، قابلیتی که اجازه می دهد از یک اتصال واحد برای انتقال جریان های متعدد داده به طور همزمان استفاده شود. با این حال، با HTTP/2، یک بسته رها شده، همه جریان‌های یک اتصال را مسدود می‌کند (پدیده‌ای که به عنوان مسدود کردن سر خط شناخته می‌شود). با HTTP/3، یک بسته حذف شده تنها یک جریان واحد را مسدود می کند. این بهبود عمدتاً نتیجه استفاده از HTTP/3 از UDP (HTTP/3 از UDP از طریق QUIC استفاده می‌کند) به جای TCP است. این امر باعث می شود که HTTP/3 برای انتقال داده از طریق شبکه های شلوغ یا پرتلفات مفید باشد.

• کاهش زمان راه اندازی اتصال

  HTTP/3 از TLS 1.3 استفاده می کند و بنابراین مزایای عملکردی خود را به اشتراک می گذارد: ایجاد یک اتصال جدید فقط به یک رفت و برگشت نیاز دارد و از سرگیری اتصال موجود نیازی به رفت و برگشت ندارد.

HTTP/3 بیشترین تأثیر را بر روی کاربران در اتصالات ضعیف شبکه خواهد داشت: نه تنها به این دلیل که HTTP/3 بهتر از نسخه های قبلی خود از دست دادن بسته ها را مدیریت می کند، بلکه همچنین به این دلیل که صرفه جویی مطلق در زمان حاصل از راه اندازی اتصال 0-RTT یا 1-RTT خواهد بود. در شبکه هایی با تاخیر بالا بیشتر است.

بهینه سازی تصویر

سرویس‌های بهینه‌سازی تصویر CDN معمولاً بر روی بهینه‌سازی تصویر تمرکز می‌کنند که می‌تواند به‌طور خودکار به منظور کاهش اندازه انتقال تصویر اعمال شود. به عنوان مثال: حذف داده های EXIF ، اعمال فشرده سازی بدون تلفات، و تبدیل تصاویر به فرمت های فایل جدیدتر (مثلا WebP). تصاویر 50 درصد از بایت های انتقال را در صفحه وب متوسط ​​تشکیل می دهند، بنابراین بهینه سازی تصاویر می تواند اندازه صفحه را به میزان قابل توجهی کاهش دهد.

کوچک سازی

Minification کاراکترهای غیر ضروری را از جاوا اسکریپت، CSS و HTML حذف می کند. انجام Minification در سرور مبدا ترجیح داده می شود تا CDN. صاحبان سایت زمینه بیشتری در مورد کدهایی دارند که باید کوچک شوند و بنابراین اغلب می‌توانند از تکنیک‌های کوچک‌سازی تهاجمی‌تر نسبت به روش‌هایی که توسط CDN استفاده می‌شود، استفاده کنند. با این حال، اگر کوچک کردن کد در مبدا یک گزینه نیست، کوچک سازی توسط CDN جایگزین خوبی است.

نتیجه

• از CDN استفاده کنید: CDN ها منابع را به سرعت تحویل می دهند، بار روی سرور مبدا را کاهش می دهند و برای مقابله با افزایش ترافیک مفید هستند.
• تا جایی که ممکن است محتوای کش را به صورت تهاجمی ذخیره کنید: هم محتوای ایستا و هم محتوای پویا می توانند و باید در حافظه پنهان ذخیره شوند - البته برای مدت زمان های مختلف. به طور دوره‌ای سایت خود را بررسی کنید تا مطمئن شوید که محتوا را به‌طور بهینه ذخیره می‌کنید.
• ویژگی‌های عملکرد CDN را فعال کنید: ویژگی‌هایی مانند Brotli، TLS 1.3، HTTP/2 و HTTP/3 عملکرد را بیشتر بهبود می‌بخشند.