التحدي: واجهة متجر جميلة لا يستطيع أحد تحميلها
كانت لدى مجموعة بيع بالتجزئة فاخرة مقرها لندن واجهة متجر مصممة جيداً فعلياً، مبنية على منصة تجارة قائمة على قوالب، ودرجة أداء Lighthouse قدرها 34. على اتصالات الجوال، التي شكّلت معظم زياراتهم، استغرقت الصفحة الرئيسية نحو أربع ثوانٍ لتصبح تفاعلية، وصفحات المنتجات بصور المنصة الافتراضية عالية الدقة استغرقت غالباً وقتاً أطول. بالنسبة لعلامة فاخرة، البطء مشكلة علامة تجارية بقدر ما هو مشكلة تقنية: واجهة متجر تتلعثم أثناء التحميل تقوّض التموضع الفاخر الذي تحاول تصوير المنتجات بناءه، وأظهرت تحليلات المُجزّئ نفسها علاقة واضحة بين زمن تحميل الصفحة والتخلي عن السلة على أعلى صفحات المنتجات قيمةً بالضبط.
المنصة نفسها لم تكن معطلة. كانت منصة تجارة تفعل ما تفعله هذه المنصات عادة: شحن حزمة عميل عامة كبيرة مصممة لدعم احتياجات تخصيص قالب كل تاجر، سواء استخدمتها واجهة متجر معينة أم لا. كل إضافة ثبّتها المُجزّئ عبر عدة سنوات، مراجعات، أدوات بيع إضافي، أداة دليل مقاسات، أضافت سكريبتها الخاص إلى صفحة كانت تعاني أصلاً، ولم يتحمل أحد مسؤولية الوزن المتراكم لأن كل إضافة كانت معقولة على حدة في حينها.
النهج: Next.js بدون رأس، لا نسخة أسرع من نفس المنصة
بدلاً من التحسين ضمن قيود المنصة القائمة على القوالب الحالية، أعدنا بناء واجهة المتجر بدون رأس: Next.js 15 في الواجهة الأمامية، منفصلة عن نظام إدارة محتوى بدون رأس يخدم الآن فقط المحتوى وبيانات المنتج التي تحتاجها واجهة المتجر فعلياً، مع الاحتفاظ بمنطق الدفع والمخزون الخاص بالمنصة القديمة خلف الكواليس عبر OmniCommerce بدلاً من إزالته وإعادة بنائه من الصفر، إذ اعتمد فريق عمليات المُجزّئ على سير عمل مبني بالفعل حوله. سمح هذا لإعادة البناء بتركيز الجهد الهندسي على الجزء الفعلي من المكدس المسؤول عن مشكلة الأداء، طبقة عرض واجهة المتجر، دون إعادة تدريب فريق العمليات على خلفية جديدة تماماً في منتصف المشروع.
تُعرض صفحات المنتج والفئات من الخادم افتراضياً بدلاً من ترطيبها من جانب العميل، إذ أن المساحة التفاعلية الفعلية في صفحة منتج (إضافة للسلة، اختيار المقاس، تكبير الصورة) صغيرة نسبياً مقارنة بالمحتوى شبه الثابت المحيط بها. تُقدَّم الصور عبر Edge CDN بأحجام خاصة بكل جهاز بدلاً من التصديرات عالية الدقة أحادية المقاس الأصلية للمنصة، وخضعت حزمة جافاسكريبت لواجهة المتجر لمراجعة مسار بمسار بدلاً من تحسينها كحزمة عامة واحدة، إذ لا تشترك الصفحة الرئيسية وصفحة الدفع في أي شيء تقريباً من حيث التفاعلية التي تحتاجانها فعلياً عند التحميل الأول.
التنفيذ: إعادة البناء حول مخزون حقيقي لا كتالوج تجريبي
بنى الفريق الواجهة الأمامية الجديدة مقابل لقطة من كتالوج منتجات المُجزّئ الحقيقي (غير المباشر) بدلاً من بيانات أولية، تحديداً لأن كتالوجات التجزئة الفاخرة لها بنية غير منتظمة، منتجات بعشرات خيارات المتغيرات بجانب منتجات بدون أي خيار، لا يُظهرها أبداً مجموعة بيانات تجريبية نظيفة. كشف هذا عدة حالات استثنائية في تصميم المكونات الأصلي مبكراً، قبل أن تصبح أخطاء إنتاج أثناء الانتقال الفعلي.
أحد القرارات المتخذة في منتصف المشروع كان إبقاء مسار الدفع الخاص بالمنصة القديمة دون تغيير تماماً خلال الإطلاق الأولي، بدلاً من إعادة بناء الدفع في نفس وقت واجهة المتجر. يحمل الدفع أكبر مخاطرة تجارية في أي صفحة تجارة إلكترونية، وفصل 'جعل تجربة التصفح سريعة' عن 'لمس تدفق الدفع' سمح لإعادة بناء الأداء بالإطلاق وإثبات نفسها دون إدخال مخاطرة متعلقة بالدفع في نفس الإصدار. تبع عمل أداء خاص بالدفع كمرحلة ثانية بمجرد أن عملت إعادة بناء واجهة المتجر بسلاسة في الإنتاج.
النتائج: Lighthouse من 34 إلى 100، أربع ثوانٍ إلى 0.4
تُحقق واجهة المتجر المُعاد بناؤها 100/100 على أداء Lighthouse، ارتفاعاً من 34 للمنصة الأصلية، مقاسة على نفس المجموعة التمثيلية من الصفحات (الرئيسية، قائمة الفئة، تفاصيل المنتج) تحت ظروف شبكة جوال مكافئة. انخفض زمن التفاعل من نحو أربع ثوانٍ إلى 0.4 ثانية على الصفحة الرئيسية، تحسن بعشرة أضعاف يُعزى مباشرة إلى مزيج العرض من الخادم، وانضباط الحزمة على مستوى المسار، والصور المُقدَّمة عبر Edge بأحجام مناسبة بدلاً من أي تغيير واحد بمفرده.
بالنسبة لبائع تجزئة فاخر، كانت الإشارة الأكثر دلالة في اتجاه مجرى العمل سلوكية لا تقنية: بإزالة حاجز زمن التحميل، تحسنت مقاييس تفاعل صفحة المنتج وإتمام السلة الخاصة بالمُجزّئ في الأسابيع التالية للإطلاق، بما يتسق مع العلاقة التي أظهرتها تحليلاتهم الأصلية بالفعل بين السرعة والتخلي، هذه المرة في الاتجاه الآخر.
