متاجر Next.js

التجارة هي الموضع الذي يثبت فيه نموذج العرض في Next.js جدواه، والموضع الذي يكلّف فيه الخطأ أكثر ما يكلّف. صفحة منتج تستغرق ثلاث ثوانٍ لا تُحوِّل، وكل قالب متجر ورثناه اتّخذ القرار المعماري نفسه: use client واحدة في الأعلى، لأن السلّة تحتاج حالة.

وذلك القرار يجعل الكتالوج - الجزء الذي يُفترَض أن يكون ثابتًا ومخزَّنًا على الحافة ومفهرسًا - ديناميكيًا كصفحة الدفع.

كيف نفصله

الكتالوج ثابت. صفحات المنتجات والمجموعات وصفحات هبوط البحث تُولَّد وقت البناء أو يُعاد التحقّق منها بالوسم حين يخبر النظام الخلفي أن شيئًا تغيّر. تأتي من شبكة التوزيع، وهي قابلة للفهرسة، ولا يعتمد الـ LCP فيها على أن تكون واجهة التجارة مستيقظة.

السلّة جزيرة عميل. مكوّن صغير، لا حدٌّ حول الصفحة. الكمّية والسلّة المصغّرة وزرّ الإضافة تفاعلية؛ أما وصف المنتج والصور والمراجعات والبيانات المهيكلة حولها فليست كذلك وتبقى على الخادم.

الأسعار والمخزون هي الاستثناء، ويُعالَج عمدًا. لا يجوز أن تَقدُم، ولا يجوز أن تجعل الصفحة ديناميكية. فإمّا أن تتدفّق خلف Suspense بينما يُرسَم باقي الصفحة، وإمّا أن يُعاد التحقّق منها بالوسم عبر خطّاف النظام الخلفي. وأيّهما يعتمد على كم تتحرّك أسعارك فعلًا - ونحن نسأل ولا نفترض.

صفحة الدفع تبقى حيث هي. إن كنت على Shopify، فصفحة الدفع المستضافة متوافقة مع PCI وتُحوِّل جيدًا ولا تستحقّ إعادة البناء. ندمج حتى عندها. أما صفحة دفع خاصة فمشروع قائم بذاته، وسنخبرك متى لا تكون مبرَّرة - ومتى كانت كذلك، بُنيت على توزيع ثقة لا يشمل المتصفح وصفحة عودة تصمد أمام التحويل.

ما نفعله بالأجزاء التي تقرّر الإيراد

بيانات Product مهيكلة بـOffer حقيقي وتوافر، كي تُظهر النتائج الغنيّة سعرًا. وروابط معيارية صحيحة عبر روابط المتغيّرات والمرشّحات - فالكتالوج متعدّد الأوجه يولّد آلاف العناوين شبه المكرّرة، وإن تُرِكت وشأنها استهلكت ميزانية الزحف على تركيبات معاملات لا يبحث عنها أحد.

ومؤشّرات Core Web Vitals تُعامَل بوصفها مقياسًا تجاريًا لا هندسيًا، تُقاس على القوالب التي تحمل الزيارات، بميزانية مفروضة في التكامل المستمر كي لا ينقضها تغيير القالب القادم.

أي نظام خلفي

Shopify (واجهة Storefront) أو Commerce Layer أو Medusa أو BigCommerce أو خدمتك الخاصة. معمارية واجهة المتجر واحدة في كل الحالات؛ والمختلف هو طبقة البيانات، وهي الجزء الذي نحدّد أنواعه ونخزّنه بعناية.

وإن كنت على قوالب Shopify نفسها وتفكّر في واجهة بلا رأس، فالجواب الصادق أنها تستحقّ حين يكون لديك فريق واجهة حقيقي أو نحن، ولا تستحقّ حين لا يكون. فقالب Liquid مصان جيدًا يتفوّق على واجهة بلا رأس لا يملكها أحد.

كيف يسير العمل

نبدأ من الإيرادات لا من البنية: أي القوالب يحمل الزيارات، وأين يفقد المسار الناس، وما الذي تجعله المنصة الحالية مستحيلًا.

النطاق التالي يسمّي النظام الخلفي وقائمة القوالب وخريطة العناوين مع خطة تحويلاتها وميزانية الأداء، مسعَّرًا لكل مرحلة. ويُوقَّع قبل بدء البناء. وخريطة العناوين تحديدًا يُتفق عليها سلفًا، لأن تغيير منصة يكتشف تحويلاته متأخرًا يكون قد خسر التصنيفات فعلًا.

ثم البناء، منشورًا لكل مرحلة، والميزانية مفروضة في التكامل المستمر من أولها.

ما الذي تحصلون عليه

واجهة المتجر، وطبقة البيانات محددة الأنواع مقابل نظامكم الخلفي للتجارة، وخريطة العناوين مع تحويلاتها، وميزانية الأداء تعمل في التكامل المستمر على القوالب التي تحمل الزيارات.

وكذلك الأجزاء التي لا يعرضها أحد: استراتيجية التخزين المؤقت لكل قالب مكتوبةً، وما تفعله الصفحة حين يبطؤ النظام الخلفي أو يسقط، وقواعد الأوجه التي تقرر أي تركيبات المعاملات يبلغها الزاحف.

الرقمان اللذان يحركان إيرادات التجارة موجودان في القوالب التي تحمل الزيارات. LCP، وهو في صفحة المنتج الصورةُ غالبًا. وبقية مؤشرات الويب الأساسية، مقيسةً على زوار حقيقيين لا في المختبر. أما الأوجه والترقيم وعناوين المعاملات فهي النصف الآخر، وإبقاؤها خارج الفهرس أمر بنيوي لا إعداد.