چرا حذف کد از بازچینی و زمانبندی مجددش بهتره؟
خلاصهٔ کاملتر
نویسنده که همکار Marko Ilić هست، به یه پست قبلی از اون دربارهی زمانبندی بارگذاری منابع تو مسیر بحرانی صفحه واکنش نشون میده. اون میگه با حذف کد کاملاً موافقه، ولی معتقده تو تیمهای بزرگ اولویت باید با حذف کد باشه نه فقط جابهجا کردن ترتیب بارگذاری، چون پیامدهای بازچینی خیلی سختتر از حذف قابل پیشبینیه.
به گفتهی نویسنده، بایتهایی که فقط به تعویق افتادن، بازم رو ترد اصلی (main thread) اجرا میشن و میتونن باعث توقفهای ناگهانی بشن که تو معیار INP (یعنی سرعت واکنش صفحه به تعامل کاربر) دیده میشه. این توقفها چون رابطهی تصادفی با بقیهی منابع دارن، پیدا کردن ریشهشون سخته و نگهداشتن ترتیب بهینهشده هم نیاز به هماهنگی دقیق بین تیمها داره.
نویسنده میگه تو سازمانهای بزرگ، هر تیم برای زودتر لود شدن کد خودش تلاش میکنه و کد تیمهای دیگه رو به تعویق میندازه؛ این رقابت یواشیواش باندلهای مشترکی مثل common.js و vendor.js رو بزرگتر میکنه بدون اینکه کسی جلوش رو بگیره. راهحل پیشنهادیش اینه که سیستمهای preloading کلاً حذف بشن، سایز باندل دوباره اندازهگیری بشه و بعد حجم کد کم بشه تا مسئولیتپذیری برگرده.
طبق گفتهی نویسنده، زمانبندی مجدد فقط تو تیمهایی جواب میده که از قبل محدودیت سایز کد، جلوگیری از رگرسیون و دروازهی انتشار سختگیرانه دارن؛ یعنی حداقل تو سطح ۴ بلوغ مدیریت پرفورمنس باشن. برای بقیهی تیمها، سرمایهگذاری رو زمانبندی یه اشتباه مدیریتیه و باید تمرکز اول رو کاهش پیچیدگی و حجم کد بذارن.
نکات کلیدی:
- حذف کد از بازچینی/زمانبندی پایدارتره چون پیامدهاش قابل پیشبینیتره
- توقفهای ترد اصلی از منابع بهتعویقافتاده تو معیار INP دیده میشن
- رقابت بین تیمها برای preloading باعث بزرگ شدن باندلهای common/vendor میشه
- زمانبندی مجدد فقط برای تیمهای سطح ۴ بلوغ مدیریت پرفورمنس توصیه میشه
- توصیهی کلی نویسنده: اول حذف کد، بعد انتقال کار به سرور، در آخر بازچینی




