لقد قمت بتدقيق مئات مواقع WordPress على مر السنين، والحوار عادة ما يبدأ بنفس الطريقة: "قمنا بتثبيت مكون إضافي للتخزين المؤقت لكن نقاطنا لا تزال سيئة للغاية." الحقيقة التي لا يريد أحد في نظام WordPress البيئي الاعتراف بها هي أن معظم مشاكل الأداء ليست قابلة للإصلاح باستخدام المكونات الإضافية. فهي معمارية. تم بناء WordPress في عام 2003 لتصيير مشاركات المدونات باستخدام PHP. نحن الآن في عام 2025، ونطلب منها تشغيل مواقع تسويقية معقدة ومنصات التجارة الإلكترونية وتطبيقات الويب — كل ذلك بينما يحدد مقياس Core Web Vitals من Google بشكل متزايد ما إذا كان أي شخص سيجد محتواك بالفعل.

تقسم هذه المقالة بالضبط السبب وراء بطء مواقع WordPress، وتربط كل مشكلة بمقاييس Core Web Vitals التي تتأثر، وتوضح لك كيف تحل معمارية Next.js التي لا رأس لها هذه المشاكل من جذورها. ليس بضمادات. من جذورها.

جدول المحتويات

لماذا موقع WordPress الخاص بك بطيء وكيف يحل Next.js المشكلة

فهم Core Web Vitals في عام 2025

قام Google بتحديث مقاييس Core Web Vitals الخاصة به في مارس 2024، واستبدل First Input Delay (FID) بـ Interaction to Next Paint (INP). هذا التغيير مهم أكثر مما يدركه معظم الناس. فيما يلي المقاييس الأربعة التي تحدد درجة أداء موقعك:

المقياس ما يقيسه جيد يحتاج إلى تحسين سيء
LCP (Largest Contentful Paint) مدى سرعة تحميل المحتوى الرئيسي الخاص بك ≤ 2.5s 2.5s – 4.0s > 4.0s
INP (Interaction to Next Paint) الاستجابة لإدخال المستخدم ≤ 200ms 200ms – 500ms > 500ms
CLS (Cumulative Layout Shift) الاستقرار البصري أثناء التحميل ≤ 0.1 0.1 – 0.25 > 0.25
TTFB (Time to First Byte) وقت استجابة الخادم ≤ 800ms 800ms – 1800ms > 1800ms

وفقًا لتقرير Chrome UX من أوائل عام 2025، فقط 42٪ من أصول WordPress تجتاز جميع عتبات Core Web Vitals الثلاثة. قارن ذلك بـ 67٪ لأصول تعمل بـ Next.js. إنها ليست فرقًا هامشيًا — إنها دوري مختلف تماما.

لماذا تهم هذه المقاييس بالفعل

كانت Google واضحة: Core Web Vitals هي إشارة ترتيب. لكن بعيدًا عن تحسين محركات البحث، تترابط هذه المقاييس بشكل مباشر مع معدلات التحويل. وجدت Vodafone أن تحسينًا بنسبة 31٪ في LCP أدى إلى زيادة بنسبة 8٪ في المبيعات. تظهر البيانات الداخلية لـ Shopify أن كل تقليل بمقدار 100 ميلي ثانية في وقت تحميل الصفحة يزيد التحويل بنسبة 1.3٪.

موقع WordPress الخاص بك ليس بطيئًا فقط. إنه يخسرك أموالاً.

لماذا WordPress بطيء معماريًا

دعني أسير معك خلال ما يحدث عندما يزور شخص ما صفحة WordPress نموذجية:

  1. بحث DNS → يحل اسم النطاق الخاص بك
  2. مصافحة TCP/TLS → تؤسس اتصالاً آمنًا
  3. الطلب يضرب الخادم → يستقبل Apache/Nginx الطلب
  4. PHP يقوم ببوت WordPress → يحمل wp-config.php، يهيئ نواة WordPress
  5. تهيئة المكون الإضافي → كل مكون إضافي نشط يتعلق بـ init, wp_loaded، إلخ
  6. الموضوع يحمل → functions.php تعمل، يحل تسلسل النموذج الهرمي
  7. تنفيذ استعلامات قاعدة البيانات → تعمل WP_Query، عادةً 30-100+ استعلام لكل صفحة
  8. PHP يصيير HTML → ملفات القالب تولد الصفحة بالكامل
  9. يتم إرسال HTML إلى المتصفح → أخيرًا، تبدأ الاستجابة
  10. المتصفح يحلل HTML → يكتشف CSS و JS والخطوط والصور
  11. تحميل الموارد التي تحجب التصيير → أوراق الأنماط من 15 مكون إضافي مختلف
  12. الصفحة أخيرًا تصيير → يرى المستخدم المحتوى

تحدث الخطوات 4 إلى 9 في كل طلب غير مخزن مؤقتًا. هذا تحليل PHP لأكثر من 200 ملف، تنفيذ العشرات من استعلامات قاعدة البيانات، وإنشاء HTML — كل ذلك قبل أن يحصل المتصفح على بايت واحد.

مشكلة PHP

PHP 8.3 أسرع بكثير من PHP 7.x، والآن تدعمه معظم مضيفي WordPress. لكن حتى مع PHP 8.3 و OPcache مفعل، فأنت لا تزال تقوم بتشغيل عملية متزامنة حجز. يحمل نواة WordPress وحدها حوالي 100,000 سطر من كود PHP في كل طلب. أضف WooCommerce وأنت تتجاوز 400,000 سطر.

إليك الشيء: مكونات التخزين المؤقت مثل WP Super Cache أو W3 Total Cache تعمل بواسطة جعل هذه العملية أقصر — فهي تخدم ملف HTML معاد إنشاؤه بدلاً من ذلك. لكنها تقدم تعقيدًا خاصًا بها، تكسر المحتوى الشخصي، ولا تزال لا تستطيع إصلاح ما يحدث في المتصفح.

مشكلة الموضوع

تم بناء معظم مواضيع WordPress للمرونة، وليس للأداء. الموضوع مثل Avada أو Divi أو Elementor يحمل إطار عمل CSS و JavaScript الكامل الخاص به في كل صفحة، سواء استخدمت تلك الميزات أم لا. رأيت مواقع Elementor تحمل 2.5 ميجابايت من CSS و 1.8 ميجابايت من JavaScript على مشاركة مدونة بسيطة.

<!-- رأس WordPress نموذجي على موقع منشئ صفحة -->
<link rel="stylesheet" href="/wp-content/plugins/elementor/assets/css/frontend.min.css">
<link rel="stylesheet" href="/wp-content/plugins/elementor-pro/assets/css/frontend.min.css">
<link rel="stylesheet" href="/wp-content/themes/hello-elementor/style.css">
<link rel="stylesheet" href="/wp-content/themes/hello-elementor/theme.min.css">
<link rel="stylesheet" href="/wp-content/plugins/contact-form-7/includes/css/styles.css">
<link rel="stylesheet" href="/wp-content/plugins/woocommerce/assets/css/woocommerce.css">
<!-- ... 12 ورقة أنماط إضافية -->

كل واحدة منها مورد يحجب التصيير. لا يمكن أن يحدث LCP الخاص بك حتى يتم تنزيل وتحليل جميعها.

انتفاخ المكونات الإضافية: قاتل الأداء الصامت

يشغل موقع WordPress العادي 20-30 مكون إضافي. رأيت مواقع بها أكثر من 70. كل مكون إضافي قد:

  • يضيف ملفات CSS و JS الخاصة به (غالبًا في كل صفحة، حتى حيث لا تُستخدم)
  • يسجل خطافات WordPress التي تنفذ في كل طلب
  • يقوم بتشغيل استعلامات قاعدة البيانات الخاصة به
  • يحمل ملفات PHP الخاصة به أثناء مرحلة البوت
  • يضيف النصوص والأنماط المضمنة إلى <head>

مثال حقيقي

قمت مؤخرًا بتدقيق موقع تسويقي يشغل WordPress مع 34 مكون إضافي نشط. إليك ما بدا عليه سقوط الشبكة:

  • 47 ملف CSS محمّل على الصفحة الرئيسية
  • 38 ملف JavaScript محمّل على الصفحة الرئيسية
  • إجمالي وزن الصفحة: 4.7 ميجابايت
  • إجمالي الطلبات: 127
  • LCP: 6.8 ثانية على شبكة 4G
  • TTFB: 2.1 ثانية

كان العميل قد قام بالفعل بتثبيت مكون إضافي للتحسين (Autoptimize) ومكون إضافي للتخزين المؤقت (LiteSpeed Cache). حتى مع تفعيل كليهما، كان LCP 4.2 ثانية. لا يزال فاشلاً.

المشكلة الأساسية؟ لا يمكنك تحسين بعيدًا عن المشكلة الأساسية المتمثلة في تحميل الكود الذي لا تحتاج إليه. تصغير وتجميع 47 ملف CSS يترك لك بحمولة CSS ضخمة تحجب التصيير.

فخ اعتماد المكون الإضافي

هنا ما يجعل هذا أسوأ: المكونات الإضافية تعتمد على مكونات إضافية أخرى. قم بتثبيت WooCommerce، ثم تحتاج إلى مكون إضافي بوابة دفع، ثم مكون إضافي حاسبة الشحن، ثم مكون إضافي لمرشح المنتج. يضيف كل واحد وزنًا. لا يمكنك إزالة أي منها بدون كسر الوظيفة.

هذا فخ WordPress. تشجع المعمارية على إضافة مكونات لكل شيء، ولا توجد آلية لتقليم الكود غير المستخدم.

لماذا موقع WordPress الخاص بك بطيء وكيف يحل Next.js المشكلة - المعمارية

مشاكل استعلامات قاعدة البيانات التي لا يمكن للمكونات الإضافية إصلاحها

يستخدم WordPress قاعدة بيانات MySQL واحدة بمخطط سيء الشهرة. جدول wp_options محمّل بمدخلات autoload='yes' في كل طلب واحد. رأيت جداول wp_options بها أكثر من 3,000 صف محمّل بالتلقائي يبلغ إجمالي حجمها 8 ميجابايت من البيانات.

-- تحقق من حجم خيارات التحميل التلقائي
SELECT SUM(LENGTH(option_value)) as autoload_size 
FROM wp_options 
WHERE autoload = 'yes';

-- إذا أرجع هذا > 1MB، فلديك مشكلة

جدول wp_postmeta هو كابوس آخر. يخزن كل شيء كأزواج مفتاح-قيمة، مما يعني أن WordPress لا يمكنها القيام باستعلامات فعالة. هل تريد البحث عن جميع المنتجات أقل من 50 دولارًا؟ هذا JOIN على wp_postmeta مع مقارنة سلسلة نصية على حقل نصي يخزن رقمًا. لا يمكن لأي فهرس أن ينقذك.

فحص عدد الاستعلام بالواقع

ثبّت مكون Query Monitor على موقع WordPress الخاص بك وانظر إلى عدد الاستعلامات. صفحة منتج WooCommerce "البسيطة" عادةً ما تشغل 150-300 استعلام قاعدة بيانات. مشاركة مدونة مع مشاركات ذات صلة وشريط الرسائل الشهيرة وفتات الخبز؟ عادةً 80-120 استعلام.

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

استضافة WordPress: ربما تدفع أكثر من اللازم مقابل متوسط

دعنا نتحدث عن الاستضافة، لأن هذا هو المكان الذي يتم فيه إهدار الكثير من المال.

نوع الاستضافة التكلفة الشهرية TTFB النموذجي هل يمكنها إصلاح المعمارية؟
مشترك (GoDaddy، Bluehost) 3-15 دولار 1.5-4.0s لا
WordPress المُدار (WP Engine، Flywheel) 25-300 دولار 400ms-1.2s لا
مُدار مميز (Kinsta، Pagely) 35-600 دولار 200ms-600ms لا
VPS/المخصص (DigitalOcean، AWS) 20-500 دولار 200ms-800ms لا
Next.js على Vercel/Edge 0-20 دولار 50-150ms نعم

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

تفرض Kinsta رسومًا بقيمة 35 دولارًا/شهر لخطتهم الأساسية بـ 25,000 زيارة. الطبقة المجانية من Vercel تتعامل مع 100 جيجابايت من نطاق الترددات. حتى خطة Vercel Pro بـ 20 دولارًا/شهر تمنحك النشر الحافي عبر CDN عام Vercel. الرياضيات لا تكذب.

كيف يحل Next.js كل Core Web Vital

دعنا نكون محددين. إليك كيفية معالجة Next.js (خاصة مع App Router في Next.js 14/15) لكل مقياس:

إصلاح TTFB

يعطيك Next.js استراتيجيات عرض متعددة:

// التوليد الثابت - TTFB فعليًا صفر (يتم تقديمه من CDN)
export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug);
  return <Article post={post} />;
}

// هذا يُعيد إنتاج وقت البناء
export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

مع التوليد الثابت، يتم بناء صفحاتك مسبقًا كملفات HTML يتم تقديمها من عقد CDN الحافة في جميع أنحاء العالم. ينخفض TTFB إلى 50-100 ميلي ثانية بغض النظر عن مكان وجود مستخدميك. لا تنفيذ PHP، لا استعلامات قاعدة بيانات، لا معالجة من جانب الخادم وقت الطلب.

للمحتوى الديناميكي، يدعم Next.js ISR (Incremental Static Regeneration)، الذي يخدم صفحات ثابتة مخزنة مؤقتًا أثناء إعادة التحقق في الخلفية:

// إعادة التحقق كل 60 ثانية
export const revalidate = 60;

إصلاح LCP

يتضمن Next.js مكون <Image> يعالج كل شيء تحاول المكونات الإضافية (وتفشل) القيام به:

import Image from 'next/image';

export default function HeroBanner() {
  return (
    <Image
      src="/hero.jpg"
      alt="بافتة البطل"
      width={1200}
      height={600}
      priority // يقوم بتحميل صورة LCP مسبقًا
      sizes="100vw"
      // يولد تلقائيًا srcset، يستخدم WebP/AVIF،
      // التحميل البطيء بشكل افتراضي، يمنع CLS
    />
  );
}

تخبر دعامة priority Next.js بتحميل الصورة مسبقًا، مما يحسن مباشرة LCP. يخدم المفاوضة التلقائية للصيغة WebP أو AVIF للمتصفحات المدعومة، مما يقلل حجم الصورة بنسبة 30-50٪ مقارنة بـ JPEG. لا مكون إضافي مطلوب.

يعيد Next.js أيضًا إنتاج CSS خالي من الحجب من خلال CSS Modules واستخراج CSS حرج تلقائي. فقط CSS المستخدم في صفحة معينة يتم تحميله.

إصلاح INP

يقيس INP مدى سرعة استجابة موقعك لتفاعلات المستخدم. تفشل مواقع WordPress في INP لأن:

  • JavaScript ثقيل من المكونات الإضافية يحجب الخيط الرئيسي
  • jQuery والمكونات الإضافية الخاصة بها تتنافس على وقت التنفيذ
  • لا يوجد تقسيم الكود — كل شيء يحمل مقدمًا

يعالج Next.js هذا من خلال تقسيم الكود التلقائي. تحمل كل صفحة فقط JavaScript الذي تحتاجه:

// هذا المكون يحمل فقط عندما يقوم المستخدم بالتمرير إليه
import dynamic from 'next/dynamic';

const HeavyChart = dynamic(() => import('@/components/HeavyChart'), {
  loading: () => <ChartSkeleton />,
  ssr: false, // لا تصيير على الخادم
});

مكونات خادم React (الافتراضي في App Router) تذهب حتى أبعد: المكونات التي لا تحتاج إلى تفاعل ترسل صفر كيلوبايت من JavaScript المكون إلى المتصفح. مشاركة مدونة بدون عناصر تفاعلية؟ صفر كيلوبايت من JavaScript المكون.

إصلاح CLS

CLS في WordPress عادةً ما يأتي من:

  • صور بدون أبعاد صريحة
  • الإعلانات تحمل بعد الوقت وتدفع المحتوى إلى الأسفل
  • خطوط الويب التي تسبب FOUT/FOIT
  • اللافتات المرسومة بواسطة المكون الإضافي التي تظهر بعد التحميل

يمنع Next.js CLS بشكل افتراضي. يتطلب مكون <Image> الأبعاد (أو يستخدم fill مع حاوية بحجم معين). يستخدم وحدة next/font تصريحات خط مضمنة و font-display: swap بدون تحول تخطيط:

import { Inter } from 'next/font/google';

const inter = Inter({ subsets: ['latin'] });

export default function RootLayout({ children }) {
  return (
    <html lang="ar" className={inter.className}>
      <body>{children}</body>
    </html>
  );
}

لا FOUT. لا تحول تخطيط من الخطوط. إنها تعمل فقط.

المعمارية بلا رأس: WordPress كمنصة إدارة محتوى و Next.js كواجهة أمامية

إليك الجزء الذي يفتقده الكثير من الناس: الذهاب بدون رأس لا يعني التخلي عن WordPress. هذا يعني استخدام WordPress لما هو بالفعل جيد به — إدارة المحتوى — بينما دع Next.js يتعامل مع الواجهة الأمامية.

تبدو المعمارية كما يلي:

[لوحة التحكم WordPress] → [REST API / WPGraphQL] → [واجهة Next.js الأمامية] → [Vercel Edge CDN]
     ↑                                              ↑
  محررو المحتوى                                  المستخدمون الخاصون بك
  استخدم الوحدة المألوفة                        احصل على صفحات سريعة
  لوحة تحكم WP                                  من الحافة

يحتفظ فريق المحتوى الخاص بك بسير العمل الخاص به. يحصل المستخدمون على موقع سريع. تحصل على كود نظيف وقابل للصيانة.

نقوم بالكثير من هذا النوع من العمل في ممارسة تطوير Next.js و تطوير Headless CMS. النمط راسخ وتم اختباره بشكل جيد.

ماذا عن خيارات Headless CMS الأخرى؟

WordPress ليس الخيار الوحيد للطبقة المحتوى. إذا كنت تبدأ من الصفر، فإن منصات CMS المبنية بدون رأس مثل Sanity و Contentful أو Storyblok غالبًا ما تكون خيارات أفضل. تم بناؤها API-first، لذا لا توجد حقائب إرث.

لكن إذا كان لديك سنوات من المحتوى في WordPress وفريق مدرب عليه، فإن WordPress بدون رأس مع WPGraphQL هو نهج صحيح تماماً.

معايير الأداء الفعلية: WordPress مقابل Next.js

فيما يلي أرقام حقيقية من الهجرات التي قمنا بها ودراسات الحالات المتاحة للجمهور:

المقياس WordPress (محسّن) Next.js (ثابت) التحسن
TTFB 650ms 80ms أسرع 87٪
LCP 3.8s 1.2s أسرع 68٪
INP 380ms 90ms أسرع 76٪
CLS 0.18 0.01 أفضل 94٪
وزن الصفحة 3.2MB 450KB أخف 86٪
الطلبات 85 12 86٪ أقل
درجة Lighthouse 45-65 95-100 ليل ونهار

"المحسّن" يعني WordPress: PHP 8.3، Redis object cache، CDN، مكون إضافي لتحسين الصور، مكون إضافي للتخزين المؤقت، تحسين قاعدة البيانات. كل الأشياء المفترض أن تفعلها. وهي لا تزال ليست قريبة.

مسار الهجرة: من WordPress أحادي الهيكل إلى Next.js بلا رأس

الهجرة لا تحتاج إلى أن تكون كل أو لا شيء. إليك النهج المرحلي الذي نوصي به عادةً:

المرحلة الأولى: التقييم (1-2 أسبوع)

  • تدقيق أداء موقع WordPress الحالي باستخدام PageSpeed Insights و CrUX data
  • جرد جميع المكونات الإضافية وربطها بالوظائف الأمامية مقابل الخلفية
  • تحديد نماذج المحتوى والحقول المخصصة
  • تقييم ما إذا كان يجب الاحتفاظ بـ WordPress كـ headless CMS أو هجرة المحتوى بالكامل

المرحلة الثانية: بناء الواجهة الأمامية (4-8 أسابيع)

  • إعداد مشروع Next.js مع App Router
  • تثبيت وتكوين WPGraphQL على WordPress
  • بناء مكتبة مكونات تطابق التصميم الحالي (أو إعادة التصميم — وقت جيد لها)
  • تنفيذ التوليد الثابت لصفحات المحتوى
  • ضبط وضع المعاينة لمحررين المحتوى

المرحلة الثالثة: الإطلاق والتحويل (1-2 أسبوع)

  • نشر الواجهة الأمامية Next.js إلى Vercel (أو Netlify أو Cloudflare Pages)
  • تكوين DNS والتحويلات
  • تحقق من أن جميع عناوين URL يتم تحويلها بشكل صحيح (الحفاظ على تحسين محركات البحث أمر حاسم)
  • قفل لوحة تحكم WordPress (إزالة الوصول المتاح للجمهور)

المرحلة الرابعة: التحسين (جاري)

  • مراقبة Core Web Vitals في Google Search Console
  • ضبط فترات إعادة التحقق ISR
  • إضافة عامل تصفية حافة للتخصيص
  • فكر في الهجرة إلى CMS بدون رأس مخصص إذا أصبح WordPress عنق زجاجة

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

للمواقع المبنية بـ Astro بدلاً من Next.js (خاصة المدونات والمواقع التسويقية الثقيلة بالمحتوى)، لدينا أيضًا ممارسة تطوير Astro التي توفر أداء أكثر عدوانية للمواقع التي تضع المحتوى الثابت في الأولوية.

الأسئلة الشائعة

هل يمكنني تسريع WordPress بدون الانتقال إلى Next.js؟ نعم، إلى حد ما. ابدأ بمضيف عالي الجودة (Kinsta أو Cloudways)، مكّن تخزين كائنات Redis مؤقتًا، استخدم موضوعًا خفيفًا مثل GeneratePress، قلل المكونات الإضافية إلى أقل من 15، وقم بتكوين CDN. يمكنك الحصول على موقع WordPress في نطاق "يحتاج إلى تحسين" لـ Core Web Vitals بهذه الطريقة. لكن الدخول في نطاق "جيد" بشكل متسق عبر جميع المقاييس — خاصة INP — أمر صعب للغاية مع معمارية WordPress التقليدية.

كم تكلفة الهجرة من WordPress إلى headless Next.js؟ هذا يعتمد على تعقيد الموقع. موقع تسويقي بسيط (10-30 صفحة، مدونة) عادةً ما يتراوح من 15,000-40,000 دولار للهجرة الكاملة. مواقع التجارة الإلكترونية مع WooCommerce أكثر تعقيدًا، تتراوح من 50,000-150,000 دولار فأكثر. عادةً ما يأتي العائد من محسّنة معدلات التحويل وتقليل تكاليف الاستضافة. تحتوي صفحة التسعير على مزيد من التفاصيل.

هل ستنخفض رتبة تحسين محركات البحث الخاصة بي إذا انتقلت إلى Next.js؟ لا، إذا قمت بمعالجة الهجرة بشكل صحيح. تحويلات 301 الصحيحة، هياكل URL المتطابقة (أو تحويلات مرسومة)، بطاقات فوقية صحيحة، البيانات المنظمة، وخريطة موقع XML ضرورية جميعها. في الواقع، Next.js له مزايا تحسين محركات البحث — Core Web Vitals أسرع تحسن مباشرة الترتيبات، و Metadata API يسهل إدارة البطاقات الفوقية برمجيًا. معظم المواقع ترى تحسينات الترتيب خلال 2-3 أشهر من الهجرة.

هل يفقد محررو المحتوى لوحة تحكم WordPress إذا ذهبنا بدون رأس؟ لا. في إعداد بدون رأس، يستمر WordPress في العمل كخادم إدارة المحتوى الخلفي. يستخدم المحررون نفس لوحة التحكم، نفس المحرر، نفس سير العمل. ببساطة لا يرون موضوع الواجهة الأمامية بعد الآن — بدلاً من ذلك، يستخدمون زر المعاينة الذي يعرض النسخة المصيرة من Next.js. يجد بعض الفريق هذا بالفعل أفضل لأن المعاينة دقيقة في الواقع لموقع الإنتاج.

هل يمكن لـ Next.js التعامل مع التجارة الإلكترونية — يمكنه WooCommerce؟ نعم، لكنها مشروع أكبر. يمكنك استخدام WooCommerce بدون رأس عبر REST API أو امتداد WooCommerce WPGraphQL. بدلاً من ذلك، يهاجر عدد من الفريق إلى Shopify's Storefront API أو Saleor لخادم التجارة، باستخدام Next.js كواجهة أمامية. تتطلب تدفق الدفع معالجة دقيقة لأنها تتضمن معالجة الدفع والامتثال لـ PCI. إنها ممكنة، لكن خطط لوقت تطوير إضافي.

هل Next.js هو الخيار الوحيد للواجهة الأمامية السريعة؟ لا. Astro و Remix و SvelteKit و حتى Nuxt (لفرق Vue) جميعها خيارات قابلة للحياة. يتفوق Astro خاصة للمواقع الثقيلة بالمحتوى لأنه يشحن صفرًا JavaScript بشكل افتراضي. يفوز Next.js للمواقع التي تحتاج إلى ميزات تفاعلية كبيرة أو ديناميكية أو التجارة الإلكترونية. نعمل مع كل من Next.js و Astro حسب احتياجات المشروع.

كيف يعمل Incremental Static Regeneration (ISR) مع محتوى WordPress؟ عند نشر أو تحديث مشاركة في WordPress، يطلق Webhook الإشعار إلى نشر Next.js الخاص بك للتحقق من تلك الصفحة المحددة. الزائر التالي يحصل على صفحة ثابتة معاد إنتاجها بشكل جديد، والتي يتم بعد ذلك تخزينها مؤقتًا في الحافة. يحدث إعادة التحقق في الخلفية، لذا لا ينتظر المستخدمون أبدًا عملية بناء. يمكنك أيضًا تعيين إعادة التحقق التي تستند إلى الوقت (على سبيل المثال، إعادة بناء كل 60 ثانية) كخطة احتياطية.

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