مطالعه موردی مهندسی
میکروکش تمام‌صفحه A2
صفحات محصول بیشتر وقتشان را صرف این می‌کردند که Elementor و دیتابیس از نو بسازندشان، آن هم برای بازدیدکننده‌هایی که همه‌شان قرار بود دقیقاً همان HTML را بگیرند. این کش جلوی آن کار را گرفت، با مرزی چنان تنگ دور ترافیک ناشناس که کاربر واردشده اصلاً به آن نمی‌خورد؛ و بعد کنارش ابزاری ساخته شد که تیم بتواند بدون توسعه‌دهنده پاکش کند، بازسازی‌اش کند و گرمش کند.
مسئله تجاری
صفحات محصول به TTFB پایین‌تر نیاز داشتند، اما نه به قیمت کش شدن سبد، نشست کاربر واردشده یا مراحل پرداخت. در یک فروشگاه، کشی که مرز دقیق نداشته باشد به‌جای صرفه‌جویی، قیمت یا سبد اشتباه به مشتری نشان می‌دهد. مسئله‌ی دوم همان‌جا بود: کشی که فقط من بتوانم بازسازی‌اش کنم، وقتی پای به‌روزرسانی محصول، تغییر چیدمان یا ترافیک پرداخت وسط باشد، خودش منبع ریسک است.
آنچه تحویل دادم
- میکروکش HTML روی دیسک، فقط برای کاربر مهمان و فقط روی مسیرهای صفحه‌ی محصول و فروشگاه، با سقف زمانی تا اگر باطل‌سازی‌ای از قلم افتاد، خودش منقضی شود.
- قوانین باطل‌سازی که به به‌روزرسانی محصول، تغییرات Elementor و رویدادهای فروشگاه گره خورده‌اند.
- قوانین دور زدنِ صریح که سبد، پرداخت، حساب کاربری، صفحه‌ی پرداخت سفارش، AJAX، درخواست‌های POST و کاربر واردشده را به‌کلی بیرون از کش نگه می‌دارند.
- کنترل‌های سمت ادمین برای پاک کردن، بازبینی و بازسازی کش، پشت بررسی سطح دسترسی، تا نگهداری هیچ‌وقت به دسترسی شل نیاز نداشته باشد.
- بازسازی دسته‌ای و یک warm worker که در واحدهای سقف‌دار کار می‌کند، نه در یک درخواست طولانی که روی سرور انباشته شود.
رویکرد فنی
- پیش از دست زدن به کش، درخواست دسته‌بندی می‌شود: هر حالت تراکنشی یا شخصی‌سازی‌شده به مسیر عادی WooCommerce می‌رود و فقط نمای مهمانِ محصول یا آرشیو می‌تواند به کش بخورد یا آن را پر کند.
- باطل‌سازی صریح نوشته شد تا صفحه‌ی محصول کهنه قابل کنترل بماند، و سقف زمانی به‌عنوان تور ایمنی کنارش نشست.
- ابزارهای عملیاتی از مسیر سرو صفحه‌های عمومی بیرون ماندند و بازسازی به دسته‌هایی با اندازه‌ی ثابت شکسته شد؛ workerی که زیادی طول بکشد خودش می‌شود منبع فشار.
- مسیر صفحه‌ی محصول را پیش و پس از انتشار اندازه گرفتم؛ معماری منتشر شد و مسیرها، کلیدها و قواعد زنده‌ی کش خصوصی ماند.
نتیجه و شواهد
در مسیر اندازه‌گیری‌شده‌ی پروداکشن، TTFB صفحه‌ی محصول از حدود ۲٫۳ ثانیه به ۰٫۹ ثانیه رسید. اداره کردن و بازگرداندن کش هم ساده‌تر و امن‌تر شد: پاک کردن، بازسازی یا برگرداندن، یک اقدام سقف‌دار و قابل بازبینی است، بی‌آنکه جزئیات داخلی کش زنده منتشر شود.
اهمیت برای کارفرما
تجربه‌ی خریدار بهتر شد، بی‌آنکه مرزهای ایمنی‌ای که یک فروشگاه WooCommerce لازم دارد جابه‌جا شود؛ و کار کارایی تکرارپذیر شد، چون بعد از تغییر محصول یا چیدمان، تیم خودش کش را برمی‌گرداند و منتظر توسعه‌دهنده نمی‌ماند.
عمق اجرای پروژه
ارزش این میکروکش فقط در خود فیچر نیست. اول محدودیت واقعی فهمیده شد و بعد مکانیزم کارایی به سیستمی تبدیل شد که بشود کنترلش کرد، بررسی‌اش کرد و برش گرداند.
- مرز امن پیش از هر تغییر رفتار کشیده شد.
- حول قابلیت بازگشت ساخته شد، نه یک جهش سرعتِ یک‌باره.
- پیاده‌سازی برای نفر بعدی قابل دنبال کردن ماند و شواهد و قواعد پروداکشن خصوصی.
خلاصه اجرایی خوانا
خلاصه_اجرایی {
پروژه: "A2 MU Fullpage Microcache"
زمینه: "کارایی WooCommerce"
دامنه: "فقط مهمان، مسیرهای صفحه‌ی محصول و فروشگاه، با سقف زمانی"
ذخیره: "میکروکش HTML روی دیسک"
باطل‌سازی: "به‌روزرسانی محصول، تغییر Elementor، رویداد فروشگاه"
عملیات: "پاک کردن و بازسازی از ادمین، بازسازی دسته‌ای، warm worker سقف‌دار"
هرگز_کش_نمی‌شود: "سبد، پرداخت، حساب کاربری، پرداخت سفارش، AJAX، POST، کاربر واردشده"
خصوصی: "کلیدها، مسیرها، قواعد زنده، لاگ‌ها"
اندازه‌گیری: "TTFB صفحه‌ی محصول ۲٫۳ ثانیه ← ۰٫۹ ثانیه"
}ارزش حرفه‌ای این پروژه
در یک کش فروشگاهی، هر تصمیم جالبی درباره‌ی این است که چه چیزی را کش نکنیم. فقط مهمان، محدود به مسیر، باطل‌شونده روی همان رویدادهایی که واقعاً خروجی را عوض می‌کنند، و منقضی‌شونده وقتی رویدادی از قلم بیفتد.
کش اضافه کردن کار هر کسی است؛ کار اصلی ساختن کنترل‌هایی است که تیم بتواند با خیال راحت اداره‌اش کند. کشی با مرز باریک و قابل اثبات که از پنل ادمین پاک می‌شود را ترجیح می‌دهم به کشی سریع‌تر که هر بار کسی از قیمت اشتباه خبر می‌دهد مجبور باشم از نو درباره‌اش فکر کنم.