چطور claude.ai تو دو هفته سه برابر سریعتر شد
خلاصهٔ کاملتر
تو یه پست مهندسی، تیم claude.ai نوشته که تو یه اسپرینت دوهفتهای تو آگوست، تجربهٔ اصلی سایت و اپ دسکتاپ رو حدود ۳ برابر سریع کرده. چهار مسیری که ۹۵٪ فعالیت کاربر رو میسازن هدف بودن. تو صدک ۷۵، زمان تا وقتی بشه تو صفحهٔ تازهلودشده تایپ کرد از ۳.۱ ثانیه به ۰.۵۵ ثانیه رسیده، شروع یه سشن Claude Code از ۰.۸ به ۰.۳ ثانیه و لود سشن ابری Cowork از ۲.۶ به ۰.۷۳ ثانیه.
روش کار اینه که برای هر چیزی اول یه عدد بسازن. نویسندهها میگن اندازهگیری قبلاً «مرحلهٔ صفر» بود، یعنی متریک اضافه کن و منتظر داده بمون؛ ولی با کلاد شده اولین پلهٔ بهبود، چون تا یه عدد برای شکستن باشه کلاد شروع میکنه به بهینه کردن. هر بنچمارک دو وظیفه داشت: یه معیار تو آزمایشگاه، و یه گارد تو CI به شکل «رچت»، یعنی سقفی که فقط اجازه داره پایین بیاد. بنچمارک بیثبات یا بیربط رو دور میریختن.
نمونههای کارشون جالبه. کلاد تو مسیر تایپ کامپوزر ۶۹۰۰ هوک و ۹۰۰ سابسکریپشن استور پیدا کرد که با هر بار فشردن کلید دوباره رندر میشدن. یه سلکتور :root:has() هم ۲۴ میلیثانیه به هر تغییر DOM اضافه میکرد. یه location.reload() جامونده روزی نیم میلیون ریلود پنهان میساخت که هیچ متریکی نمیدیدش. هایلایت یه بلاک کد تمومشده هم گاهی حدود یه ثانیه صفحه رو قفل میکرد.
ته ماجرای اون قفل شدن قشنگترین تیکهٔ پسته: اگه مارکداون یه جواب حتی یه کاراکتر غیر Latin-1 داشت، مثل em dash یا کوتیشن فرفری، V8 کل رشته رو UTF-16 نگه میداشت و همهٔ رجکسهای هایلایت میافتادن رو مسیر کند دوبایتی. فیکسش یه تغییر بیستخطی بود: هر بلاک کد قبل از هایلایت شدن تو یه رشتهٔ تکبایتی کپی میشه.
چیزی که این سرعت رو بیخطر نگه داشت، گاردریلها بودن. هر PR ریویو خودکار بهعلاوهٔ حداقل یه تأیید انسانی میگرفت، تست قبل از بهینهسازی نوشته میشد و هر چیزی که کاربر میدیدش پشت یه فیچرفلگ کوتاهمدت میرفت؛ نزدیک ۲۰۰ فلگ تو دو هفته که بیشتر از نصفشون تا آخر اسپرینت جمع شد. تو پست اومده که جمعاً بیش از سه هزار تغییر مرج شده، بدون حتی یه حادثهٔ کاربری یا رولبک.
نکات کلیدی:
- صدک ۷۵ زمان تا آمادهٔ تایپ شدن claude.ai: از ۳.۱ به ۰.۵۵ ثانیه؛ سشن ابری Cowork از ۲.۶ به ۰.۷۳ ثانیه
- چهار مسیر کاربری هدف بودن که ۹۵٪ فعالیت رو میسازن، با ۱۳ اندازهگیری مجزا
- بنچمارکها به شکل «رچت» تو CI قفل شدن: هر PR که عدد رو بالا ببره فیل میشه
- یه سلکتور :root:has() تنها ۲۴ میلیثانیه به هر تغییر DOM اضافه میکرد
- بیش از ۳۰۰۰ تغییر مرج شد، با حدود ۲۰۰ فیچرفلگ و بدون هیچ رولبکی




