تحویل فرانت‌اند در عصر انتشار با فرکانس بالا نیاز به طراحی مجدد در حافظه پنهان و همکاری فشرده‌سازی دارد.

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

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

تا زمانی که هش منبع پایدار نباشد، مزایای فشرده سازی به سادگی غیرقابل دفاع است.

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

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

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

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

تنها زمانی که هویت منبع تثبیت شود، می‌توان حافظه پنهان را به‌طور مداوم مورد استفاده مجدد قرار داد و نتایج فشرده‌سازی دارای ارزش تجمعی هستند.

کنفرانس مطبوعاتی با فرکانس بالا مشکل فشرده سازی را در یک مشکل نسخه فرهنگ لغت بازنویسی می کند

همانطور که منابع بیشتر و بیشتر پراکنده می شوند، Brotli یا gzip تک فایلی هنوز مهم است، اما دیگر همه چیز نیست. هزینه واقعی به سمت قطعات تکراری تغییر می‌کند: کد زمان اجرا چارچوب، قالب‌های سبک، اعلان‌های نوع رابط، لایه‌های بسته‌بندی تولید شده توسط بسته‌کننده‌ها، اغلب بین دسته‌ای از نسخه‌ها بسیار مشابه هستند. با سرعت انتشار سریع، این ریف ها بارها و بارها منتقل می شوند.

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

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

یک رویکرد سلسله مراتبی مانند زیر معمولا پایدارتر از “فشرده سازی قوی یکپارچه برای کل سایت” است:

const policy = {
  immutableAssets: 'public, max-age=31536000, immutable',
  releaseManifest: 'public, max-age=60, stale-while-revalidate=30',
  sharedDictionary: 'versioned-by-release-train'
}

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

فشار بازگشت به منبع اغلب به این دلیل نیست که فایل بیش از حد بزرگ است، بلکه این است که روش شکست بیش از حد خشن است.

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

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

در این نوع سناریو، با ارزش ترین چیز شعاع خرابی قابل کنترل است:

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

چیزی که واقعاً در مورد هزینه انتقال حساس است نه تنها اندازه فایل، بلکه نحوه تصمیم گیری سیستم در مورد اینکه کدام محتوا باید دوباره واکشی شود، است.

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

این مجموعه از طراحی مشترک برای همه سایت ها لازم نیست. برای پروژه‌هایی با تعداد صفحات ثابت، بسته منابع کوچک و تعداد دفعات انتشار هفتگی یا حتی ماهانه، استفاده از نام‌های فایل هش سنتی به‌علاوه پیش فشرده‌سازی Brotli معمولاً به اندازه کافی پایدار است.

ذخیره سازی و فشرده سازی با هم به سرعت به یک زیرساخت تحویل تبدیل می شوند که این ویژگی ها در محل قرار گیرند:

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

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