WordPress أم Next.js: متى يكف القالب عن الكفاية

معظم الصفحات التي تجيب عن هذا السؤال تكتبها شركة تبيع أحد الخيارين. فلنبدأ بالإفصاح إذن: نحن نبني تطبيقات Next.js، ولنصيب كبير من المواقع التي تصل إلى هنا جوابنا أن تبقوا على WordPress.

نقطة البداية الصادقة

موقع تعريفي، أو مدونة، أو موقع شركة صغيرة، أو منصة نشر بمحررين. يؤدي WordPress هذا العمل جيدًا وبكلفة منخفضة وبمسار صيانة لا يحتاج فريق واجهات. ونقله إلى Next.js يشتري صفحة أسرع نظريًا ويكلّفكم تجربة تحرير ومنظومة إضافات وفاتورة استضافة كانت تافهة.

وإن لم يكن لديكم من يتولّى قاعدة شيفرة جافاسكربت بعد رحيلنا، فتلك ليست تفصيلة تُلتَف حولها. هي الجواب كله.

ما الذي تتخلّون عنه فعلًا

هذا هو الجزء الذي تتخطاه صفحات المقارنة، فإليكم إياه في قائمة.

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

النماذج. نموذج التواصل إضافةٌ في WordPress. وفي Next.js هو أربعة قرارات: إلى أين يُرسل، وما الذي يوقف الرسائل المزعجة، وأين يُحفظ الإرسال، ومن يُبلَّغ به.

إضافة السيو. تضع Yoast وأخواتها البيانات الوصفية وخرائط الموقع والتحويلات والترميز خلف واجهة يشغّلها شخص من التسويق. وفي Next.js هذه شيفرة. وهذا أفضل في النهاية، لأن الوسم الخاطئ يصير مستحيلًا لا مجرد غير محبَّذ، لكنه في اليوم الأول عملٌ على أحدهم أن يؤديه.

التحويلات. تُدار من شاشة إدارة، أو تُدار في الشيفرة. وواحدة فقط منهما يستطيع فريق التسويق لديكم تنفيذها عصر الجمعة.

أين يكف القالب عن كونه الوعاء الصحيح

ثمة حدٌّ حقيقي، وليس هو الزيارات ولا عدد الصفحات.

هو حيث تبدأ الواجهة في امتلاك سلوك تطبيق: حالة دخول تغيّر ما تعرضه الصفحة، وتصفية عبر آلاف العناصر يجب أن تكون سريعة وقابلة للربط، ونظام تصميم مشترك مع منتج ليس هو الموقع، وتخصيص، وصفحة دفع تتحكمون فيها حقًا.

يمكن دفع القالب إلى كل ذلك. رأيناه. والنتيجة قوالب PHP فوقها آلاف الأسطر من jQuery، وطبقة تخزين مؤقت يجب تجاوزها في نصف المسارات، ولا أحد يجرؤ على لمس الترويسة.

مؤشرات الويب الأساسية، وليست الحجة التي تظنونها

قالب WordPress مبني جيدًا على استضافة محترمة يتفوق على تطبيق Next.js مبني رديئًا. قسنا الاثنين مرات تكفي لقول ذلك بصراحة.

إطار العمل ليس المتغيّر. ما يقرر LCP هو متى يبدأ طلب أكبر عنصر، وموقع Next.js يخطئ في ذلك بالسهولة نفسها التي يخطئ بها قالب. ما يمنحه Next.js سقفٌ أعلى وأدوات للدفاع عنه في التكامل المستمر. أما الأرضية فلا تُمنح لكم.

وإن كان أحدهم يبيعكم إعادة بناء بوعد درجة خضراء، فاسألوا عن الدرجة الآن وعمّا يسبب الرقم. وغالبًا ما يكون ثلاث صور وخطًا واحدًا.

WordPress بلا رأس، الطريق الوسط

يبقى WordPress سطح التحرير، والعرض يتم بـ Next.js. يحتفظ المحررون بأداتهم، وتبقى العناوين لكم، وتنال الواجهة الحدّ الذي كان ينقصها.

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

كيف تقررون دون إعادة كتابة

خذوا القالبين أو الثلاثة التي تحمل زياراتكم وتحويلاتكم. لا الموقع كله.

إن كان ما يفسدها صورًا وخطوطًا وإضافة تفعل شيئًا سخيفًا، فتلك مشكلة WordPress بحلّ من WordPress، وبجزء يسير من كلفة إعادة البناء. وإن كان ما يفسدها أن الصفحة يجب أن تكون تطبيقًا وهي قالب، فلديكم جوابكم: انقلوا تلك المسارات أولًا واتركوا بقية الموقع مكانه.

وحيث يتعين على الواجهة أن تصير تطبيقًا حقًا، فذلك هو البناء. وحيث لا يتعين، ويكون الجواب الصادق أن Next.js أداة خاطئة للموقع الذي لديكم، فهناك صفحة عن ذلك أيضًا.

أما متجرٌ على Shopify فحديث آخر، وأقصر. فـ Shopify يبقى هناك في الحالتين، وما يُقرَّر فعلًا هو من يعرض واجهة المتجر.