Next.js كما صُمم ليُستخدم، لا كما يُنسخ.
App Router وServer Components وISR والتشغيل على الحافة أدوات قوية حين تُستخدم لسبب، ومصدر تعقيد حين تُستخدم لأنها رائجة. نختار منها ما يحتاجه موقعك فعلاً، ونكتب لماذا.
نبني مواقع وتطبيقات ويب على Next.js: صفحات تُعرض من الخادم فتفتح بسرعة وتقرؤها محركات البحث، واستراتيجية تخزين مؤقت مدروسة لكل صفحة، ونشر على Vercel أو Cloudflare مع رابط معاينة لكل تغيير. ننقل المشاريع القائمة إلى App Router على مراحل، ونقول لك بصراحة متى يكفيك موقع أبسط.
آخر تحديث نوفمبر 2026
Next.js لا يجعل الموقع سريعاً. القرارات المتخذة داخله هي التي تفعل.
يعطيك Next.js طرقاً عدة لعرض كل صفحة: ثابتة تُبنى مرة، أو تُعاد توليدها كل فترة، أو تُعرض عند كل طلب، أو تُبث على أجزاء. معظم مواقع Next.js البطيئة التي نراها ليست بطيئة بسبب الإطار، بل لأن كل شيء يُعرض في المتصفح، أو لأن التخزين المؤقت أُطفئ احتياطاً ولم يُعَد تشغيله.
لذلك نقرر لكل صفحة على حدة: ما الثابت، وما يتجدد كل فترة، وما يجب أن يكون حديثاً عند كل زيارة. ونكتب القرار في المشروع، ليعرف المطور التالي لماذا لا كيف فقط.
وفي الخليج يُضاف إلى ذلك العربية والإنجليزية في التطبيق نفسه، بمسارات لغوية ووسوم hreflang واتجاه من اليمين إلى اليسار، وإدارة محتوى يحرّر منها فريقك الصفحات دون مطور. ولمتاجر Shopify التي كبرت على قوالبها، تُبنى الواجهة على Next.js وتبقى الطلبات والدفع في Shopify.
ما نبنيه.
الانتقال إلى App Router
من Pages Router على مراحل، صفحة بعد صفحة، والموقع يعمل طوال الوقت. لا إعادة كتابة شاملة في عطلة نهاية أسبوع.
Server Components حيث تفيد
كود أقل يُرسل إلى الهاتف، وبيانات تُجلب على الخادم. ومكوّنات المتصفح تبقى للأجزاء التفاعلية فقط.
ISR واستراتيجية التخزين المؤقت
قرار مكتوب لكل نوع صفحة: متى يُعاد توليدها، وما الذي يُحدّثها، وما الذي لا يُخزَّن أبداً.
التشغيل على الحافة والبث
أجزاء الصفحة تصل تباعاً بدل انتظار أبطأها، والمنطق القريب من الزائر يعمل على الحافة حيث يستحق ذلك.
النشر على Vercel أو Cloudflare
نشر عند كل دفع للكود، ورابط معاينة لكل تغيير، وتراجع بنقرة. أو على خادمك أنت إن كان ذلك ما تحتاجه.
إدارة محتوى منفصلة
Sanity أو Strapi أو Contentful أو WordPress بلا واجهة، ليحرّر فريقك الصفحات والمنتجات دون أن يلمس الكود.
تحسين محركات البحث مبني فيه
بيانات وصفية لكل صفحة، وبيانات منظمة، وخريطة موقع، ووسوم hreflang للعربية والإنجليزية. منذ البداية لا بعد الإطلاق.
سرعة تُقاس على شبكات حقيقية
Core Web Vitals على اتصالات جوال عادية في الخليج وباكستان، لا على خط مكتب سريع، قبل العمل وبعده.
أي طريقة عرض لأي صفحة؟
القرار الذي يحدد سرعة موقع Next.js أكثر من أي شيء آخر. معظم المواقع تحتاج مزيجاً، لا طريقة واحدة لكل شيء.
| ثابتة (Static) | إعادة توليد تدريجي (ISR) | عرض عند كل طلب (SSR) | في المتصفح فقط | |
|---|---|---|---|---|
| سرعة الفتح الأولى | الأسرع | سريعة جداً | تعتمد على الخادم والبيانات | الأبطأ على الجوال |
| تقرؤها محركات البحث ومساعدو الذكاء الاصطناعي | نعم | نعم | نعم | بشكل غير موثوق |
| حداثة البيانات | عند كل نشر | كل فترة تحددها، أو عند التحديث | لحظية | لحظية |
| الحمل على الخادم | شبه معدوم | منخفض | الأعلى | منخفض على الخادم، ثقيل على الهاتف |
| الأنسب لـ | الصفحات التعريفية والمقالات | صفحات المنتجات والفئات والمحتوى المتغير | الحسابات والأسعار الخاصة واللوحات | الأجزاء التفاعلية بعد تسجيل الدخول |
أين يناسب هذا.
حين تصبح حدود قوالب Shopify مكلفة، تُبنى الواجهة على Next.js وتبقى المنتجات والطلبات والدفع في Shopify.
كل طلب دمج يحصل على رابط معاينة تفتحه وتراجعه قبل أن يصل إلى الموقع الحي.
مسارات لغوية ووسوم hreflang واتجاه من اليمين إلى اليسار في المشروع نفسه، لا موقعان منفصلان يبتعد أحدهما عن الآخر.
متى يكون هذا القرار الصحيح.
موقع يعتمد على البحث والسرعة
مواقع تسويقية ومحتوى ومتاجر بلا واجهة، حيث تقرأ محركات البحث الصفحة كاملة ويفتحها الزائر بسرعة على الجوال.
تطبيق ويب بواجهة React
لوحات وبوابات ومنتجات SaaS تحتاج صفحات عامة سريعة ومنطقة حسابات تفاعلية في المشروع نفسه.
مشروع Next.js قديم يثقل
Pages Router، وتخزين مؤقت غير مفهوم، وفواتير استضافة ترتفع. ننقله على مراحل ونكتب ما قررناه.
لا تشترِ هذا إذا كان موقعك صفحات قليلة يحدّثها فريق التسويق
موقع تعريفي من عشر صفحات لا يحتاج Next.js. WordPress مبني جيداً أو منصة أبسط يخدمك أفضل، ويحرّره فريقك دون مطور. سنقول لك ذلك قبل أن نقترح شيئاً.
كيف نعمل.
نراجع ما لديك
الموقع الحالي، وسرعته على الجوال، وطريقة عرض كل صفحة، وما تدفعه في الاستضافة. تقرير مكتوب قبل أي اقتراح.
نقرر طريقة العرض لكل صفحة
ثابتة، أو تتجدد، أو عند كل طلب. قرار مكتوب يبقى في المشروع.
نتفق على النطاق والمواعيد
ما الذي يُبنى أو يُنقل، وبأي ترتيب، ومتى. كتابةً قبل البدء.
نبني على دفعات من أسبوعين
كل تغيير على رابط معاينة تفتحه، ويراجعه مهندس ثانٍ قبل الدمج.
ننقل دون خسارة الترتيب
كل عنوان قديم يُوجَّه إلى مقابله، ونتحقق من البيانات المنظمة والوسوم قبل الإطلاق وبعده.
نسلّمه موثّقاً
الكود في مستودعك، والنشر على حساباتك، ووثائق تشرح القرارات لا الأوامر فقط.
تطوير Next.js
7 أسئلة مع إجاباتها. لديك سؤال آخر؟ تواصل معنا.
إن كان موقعك صفحات تعريفية ومقالات يحدّثها فريق التسويق، فـ WordPress مبني جيداً يكفيك غالباً، وسنقول ذلك. Next.js يستحق مكانه حين يكون الموقع جزءاً من منتج: حسابات، بيانات حية، متجر بلا واجهة، أو حين تكون السرعة على الجوال تكلّفك مالاً فعلاً. ويمكن الجمع بينهما: WordPress لإدارة المحتوى وNext.js للواجهة.