هاب برند A2

مسئله تجاری

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

آنچه تحویل دادم

• یک فایل MU به نام a2-brand-hubs-mu.php، با شورت‌کدهایی که شبکه‌ی هاب را برای دسته‌های فرزند swiss-watches و japanese-watches رندر می‌کند.
• یک جاب اسنپ‌شات روزانه روی WP-Cron که بازه‌های قیمت را با توجه به واحد پول و تعداد محصول‌ها را از نو می‌سازد؛ یک آپشن قفل جلوی هم‌پوشانی دو اجرا را می‌گیرد.
• کش دولایه: HTML رندرشده‌ی هاب ۳۰ روز می‌ماند، داده‌ی قیمت و تعداد هر ۲۴ ساعت تازه می‌شود، و ساخت، ویرایش یا حذف ترم لایه‌ی ساختاری را باطل می‌کند.
• جست‌وجوی برند، فیلتر حرف الفبا و فیلتر قیمت روی صفحه‌ی هاب، به‌علاوه‌ی یک resolver که هر برند را ـ اگر مقاله‌ی تاریخچه داشته باشد ـ به آن لینک می‌کند.
• کنترل‌های ادمین به‌شکل query string: یکی برای اسنپ‌شات، یکی برای بازسازی کامل، و یک اندپوینت JSON که متریک‌های روزانه را برمی‌گرداند.

رویکرد فنی

• داده و نمایش هرکدام ساعت انقضای خودشان را دارند. همین یک تصمیم، هم صفحه را ارزان نگه می‌دارد و هم اعداد را قابل‌اعتماد.
• افزونه‌های MU هوک فعال‌سازی ندارند، پس زمان‌بندی کرون روی init چک می‌شود و هر بار که نباشد دوباره ساخته می‌شود.
• اسنپ‌شات به‌جای یک ترنزینت برای هر ترم، در یک آپشن ذخیره می‌شود. این‌طوری رندر هر هاب فقط یک خواندن اضافه هزینه دارد.
• باطل‌سازی کش به created_term، edited_term و delete_term گوش می‌دهد تا بازچینی دسته‌ها برند شبح روی صفحه جا نگذارد.

نتیجه و شواهد

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

اهمیت برای کارفرما

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