رویکرد محلیمحور برای رندر سریعتر
گیتهاب معماری ناوبری بخش Issues را بازطراحی کرد تا با انتقال بخش عمدهای از پردازشها به سمت کاربر، تأخیر درکشده برای توسعهدهندگان را به حداقل برساند. تیم مهندسی این پلتفرم با بهرهگیری از کشینگ سمت کاربر، پیشواکشی پیشبینیکننده و مدیریت درخواستهای مبتنی بر سرویسورکر، سهم ناوبریهای فوری را از 4 درصد به 22 درصد ارتقا داد. این تغییرات به حل یکی از چالشهای اساسی برنامههای وب در مقیاس بزرگ میپردازد: کاهش تأخیرهای ناشی از درخواستهای شبکهای مکرر و مقداردهی اولیه در گردشکارهای تکرارشونده.
این پروژه عمدتاً روی کاربران GitHub Issues متمرکز بود؛ کاربرانی که دائماً بین مسائل، فهرستها و نماهای مرتبط جابجا میشوند و میتوانند از اطلاعات پیشتر دریافتشده به جای ارسال درخواست جدید به بکاند استفاده کنند. گیتهاب برای قطع این وابستگیهای شبکهای، رویکرد محلیمحور (Local-first) را پیادهسازی کرد. در این معماری، دادههای موجود بلافاصله از مرورگر رندر میشوند و پردازشهای پسزمینه در صورت نیاز، اطلاعات جدیدتر را واکشی میکنند. این ساختار از چندین لایه ذخیرهسازی سمت کاربر بهره میبرد؛ از جمله IndexedDB برای ذخیرهسازی دائمی و کش درونحافظهای برای دسترسی سریع به دادههای پرکاربرد در طول نشستهای فعال.
تمایز پیشواکشی و کیفیت توزیع
کارشناسان صنعت توسعه نرمافزار درباره این تغییرات نظرات دقیقی ارائه دادند. BareStack به نکتهای مهم درباره پیشواکشی اشاره میکند:
پیشواکشی زمانی ارزشمند است که نمودار دادهها کوچک و با بار خواندن سنگین (مانند Issues) باشد. بیشتر برنامهها نمودار بزرگتری با تداخل خواندن و نوشتن دارند و نماهای پیشواکشیشده ممکن است پس از بارگذاری مجدداً واکشی شوند. الگوی قابلاستفادهی مجدد در اینجا، رندر ابتدا پوسته (shell-first render) به همراه هیدراتاسیون بر اساس کش است، نه خودِ پیشواکشی.
اوگوز گوین (Oguz Guven) نیز درس مهمی در زمینه عملکرد بیان میکند و میگوید:
عبور از دمِ توزیع p99 به سمت کیفیت توزیع، بلوغ واقعی مهندسی را نشان میدهد.
مدل stale-while-revalidate و پیشگرمسازی
مدل کشینگ گیتهاب از رویکرد stale-while-revalidate پیروی میکند. هنگامی که کاربران به محتوایی که قبلاً مشاهده کردهاند بازمیگردند، برنامه دادههای محلی را بدون انتظار برای پاسخ سرور نمایش میدهد. سپس سیستم همگامسازی پسزمینه را اجرا میکند تا اطلاعات کششده را بهروزرسانی و سازگاری با دادههای بکاند را حفظ کند.
علاوه بر این، گیتهاب مفهوم پیشگرمسازی (Preheating) را برای بهبود اثربخشی کش معرفی کرد. این مکانیسم با تحلیل الگوهای ناوبری کاربر، دادههای مورد نیاز احتمالی را پیش از درخواست رسمی آماده و ورودیهای کش مرتبط را پر میکند. تیم توسعه این رویکرد را با استفاده از سرویسورکرهایی گسترش داد که درخواستهای مرورگر را رهگیری کرده و منابع محلی موجود را بررسی میکنند. در این حالت، دادههای کششده بلافاصله رندر میشوند و بهروزرسانیهای پسزمینه اطلاعات جدیدتر را همگامسازی میکنند. درخواستهای مربوط به دادههای در دسترسنیافته یا قدیمی همچنان از مسیر معمول بکاند پردازش میشوند.
تعادل میان پاسخگویی و تازگی دادهها
این معماری نیازمند ایجاد تعادل میان پاسخگویی و تازگی دادهها بود. گیتهاب به جای انتظار برای دریافت جدیدترین وضعیت سرور پیش از رندر کردن در هر تعامل، اجازه داد برخی محتواها بلافاصله نمایش داده شده و بهطور ناهمزمان بهروزرسانی شوند. این استراتژی زمان انتظار کاربر را کاهش میدهد و همگامسازی با سیستمهای بکاند را حفظ میکند.
الکساندر لریدیس (Alexander Lelidis)، مهندس ارشد نرمافزار در گیتهاب، معتقد است که تأخیر فراتر از یک عدد ساده است:
تأخیر فقط یک معیار نیست. تأخیر یک تغییر زمینه (context switch) است.
اندازهگیری تأخیر و ارقام دستاوردها
گیتهاب بهبودهای حاصل از این معماری را در توزیعهای تأخیر ناوبری بهدقت اندازهگیری کرد. تأخیر P10 از حدود 600 میلیثانیه به 70 میلیثانیه کاهش یافت. تأخیر P25 از 800 به 120 میلیثانیه سقوط کرد و تأخیر میانه نیز از 1200 میلیثانیه به 700 میلیثانیه رسید. شاخصهای P75 و P90 نیز بهبود چشمگیری داشتند و به ترتیب از 1800 به 1400 میلیثانیه و از 2400 به 2100 میلیثانیه تنزل یافتند.
انتقال پردازشها به سمت کاربر نشان میدهد که پلتفرمهای توسعهدهنده با پذیرش الگوهای نوین فرانتاند، میتوانند تجربه کاربری روانتری را حتی با وجود زیرساختهای پیچیده بکاند ارائه دهند. این موفقیت میتواند مسیر پروژههای متنباز و تجاری را برای تمرکز بر رویکردهای محلیمحور و مدیریت هوشمند دادهها در مرورگر هموار کند.
