خدمة WordPress · تطوير متقدم
ووردبريس يدير المحتوى، وواجهة منفصلة (موقع، تطبيق، شاشة) تستهلكه عبر REST أو GraphQL. بنية قوية لمشاريع بعينها، ومكلفة بلا مبرر لغيرها. أبدأ بالسؤال الصريح: هل يحتاج مشروعك هذا فعلًا؟ ولا أعد بأنه أسرع تلقائيًا.
متى headless مناسب وغير مناسب
أغلب مواقع الشركات والعيادات والمتاجر الصغيرة تحصل على سرعة ممتازة بووردبريس تقليدي مضبوط جيدًا، بتكلفة صيانة أقل بكثير. Headless يستحق حين يكون هناك سبب معماري حقيقي.
منصات تقنية وتطبيقات وخدمات رقمية؛ النوع الذي يُطرح فيه سؤال الواجهة المنفصلة. أعرضها كأمثلة لمواقع من المعرض لا كمشاريع Headless بالضرورة.
لانا AI، موقع ووردبريس في مجال منصات تجربة الموظفين؛ عرض المنصة، المزايا، التواصل.
xobanking، موقع ووردبريس في مجال التطبيقات المالية؛ معاينة التطبيق، تقديم المنتج، مداخل المعلومات.
تجارتي، موقع ووردبريس في مجال برامج المبيعات والمحاسبة؛ معاينة البرنامج، تقديم الوظائف، التطبيق.
People By App، صفحة هبوط ووردبريس في مجال تطبيقات التواصل المهني؛ معاينة التطبيق، خطوات الاستخدام، دعوة الاستكشاف.
إدارة، صفحة هبوط ووردبريس في مجال برامج إدارة الأعمال؛ التعريف بالنظام، طلب التواصل، شرح الاحتياج.
Qualidev، موقع ووردبريس في مجال الخدمات البرمجية والسحابية؛ عرض الخدمة، تعريف الشركة، تصنيف الحلول.
SmartUp Egypt، موقع ووردبريس في مجال الحلول البرمجية؛ تقديم الشركة، خدمات البرمجيات، تنظيم الروابط.
ووردبريس كمركز محتوى
في البنية المنفصلة يحتفظ ووردبريس بما يجيده: المحرر الذي يعرفه الفريق، أنواع المحتوى والحقول، الوسائط، المستخدمين والصلاحيات، وسير النشر. الواجهة تتولى العرض والتفاعل والتوجيه.
نموذج المحتوى يصبح عقدًا بين الطرفين: كل نوع محتوى وحقل يُعرض عبر REST (بإضافة show_in_rest وتسجيل الحقول) أو GraphQL (عبر WPGraphQL عند الحاجة)، ويُوثق حتى يبني فريق الواجهة عليه دون تخمين.
| المسؤولية | ووردبريس | الواجهة |
|---|---|---|
| التحرير والنشر | نعم | لا |
| نموذج المحتوى والحقول | نعم | يستهلك فقط |
| الوسائط ومقاساتها | نعم | تحسين عرض |
| العرض والتوجيه (routing) | لا | نعم |
| SEO (عناوين، بيانات منظمة، خريطة) | المصدر | التنفيذ في HTML المعروض |
| المعاينة قبل النشر | يطلبها | تنفذها |
| النماذج والتفاعل | يستقبل عبر REST | نعم |
| المصادقة للمحتوى الخاص | المصدر | توكن |
اختر البنية المناسبة لمشروعك
الاختلاف في مكان بناء الصفحة وكيف تصل البيانات إليها. قارن مسار العرض ومتطلبات الإدارة، واختر ما يخدم فريقك وطريقة نشر محتواك.
المحتوى وتصميم الصفحات في نظام واحد.
يطلب الصفحة من الموقع.
يجهّز المحتوى ويعرضه كصفحة HTML، مع كاش صفحات أو CDN عند ضبطهما.
مناسب غالبًا للمواقع التي تحتاج تحريرًا مباشرًا وتكاملًا مع القالب والإضافات.
إدارة المحتوى منفصلة عن طريقة عرضه للزوار.
يطلب الصفحة من الواجهة المستقلة.
يعرض HTML من الخادم أو صفحات مولّدة مسبقًا، مع كاش مناسب.
يوفّر المحتوى للواجهة، ويمكن مشاركته مع قنوات أخرى.
مناسب عند الحاجة لواجهة خاصة أو عدة قنوات، مع تجهيز المعاينة وSEO والتكاملات.
معاينة المحرر وSEO
المعاينة: في ووردبريس التقليدي زر «معاينة» يعمل تلقائيًا. في البنية المنفصلة يجب بناؤه: توكن معاينة مؤقت يسمح للواجهة بطلب المسودة من ووردبريس وعرضها للمحرر فقط. من دون ذلك سينشر الفريق ليرى النتيجة، وهذا ما لا يقبله أحد.
SEO: محركات البحث تحتاج HTML كاملًا عند الطلب. لذلك تُعرض الصفحات على الخادم (SSR) أو تُولّد مسبقًا (SSG) ولا تُترك للمتصفح وحده. العناوين والأوصاف والبيانات المنظمة وخريطة الموقع وروابط canonical تُنفذ في الواجهة من بيانات ووردبريس، وتُفحص بأدوات Google بعد البناء.
الأداء والتخزين المؤقت
واجهة منفصلة بلا كاش تكون أبطأ من ووردبريس تقليدي مع كاش صفحات. لذلك يُصمم التخزين المؤقت في ثلاث طبقات ويُقاس بالأرقام الفعلية بعد البناء، لا بوعد مسبق.
استجابات REST/GraphQL تُكاش وتُبطل عند تحديث المحتوى، حتى لا يصبح ووردبريس عنق زجاجة عند كل طلب من الواجهة.
الصفحات المعروضة أو المولدة تُخدم من CDN مع إبطال انتقائي عند النشر (on-demand revalidation) بدل إعادة بناء الموقع كله.
مقاسات ووردبريس المسجلة أو خدمة صور للواجهة، مع تحميل كسول وأبعاد صريحة لتجنب CLS.
Core Web Vitals من بيانات الميدان بعد الإطلاق، مقارنة بالموقع السابق بنفس الظروف. الهدف LCP ≤ 2.5 ثانية وINP ≤ 200 مللي ثانية وCLS ≤ 0.1 عند النسبة المئوية 75، كأهداف لا ضمانات.
حدود معدل ومهل وصفحات نتائج (pagination) حتى لا تسقط الواجهة ووردبريس عند ذروة الزيارات أو إعادة بناء كبيرة.
تحديثات ووردبريس وإضافاته على جهة، وتبعيات الواجهة على جهة أخرى، لكل منهما نسخة تجريبية واختبار. هذا هو ثمن البنيتين الذي يُذكر في النطاق.
مراحل البناء
لا أعرض مشاريع headless كدراسات حالة في هذه الصفحة لأن ذلك يحتاج إذنًا وتفاصيل بنية لا تُنشر؛ أعرض بدلًا منها المنهجية وإثبات المفهوم المتفق عليه لكل مشروع.
القنوات، الفريق، وتيرة النشر، المحتوى الخاص والعام، الإضافات التي يعتمد عليها الموقع الحالي، والميزانية. ينتهي بتوصية صريحة: headless أو تقليدي محسّن.
المخرج: مذكرة قرار معماريأنواع المحتوى والحقول وما يُعرض عبر REST أو GraphQL، موثق لفريق الواجهة.
المخرج: توثيق APIصفحة أو صفحتان من الواجهة الفعلية مع معاينة تعمل وقياس أولي للأداء، على بيئة تجريبية. يُقرر بعده الاستمرار أو التعديل.
المخرج: POC قابل للتجربةالواجهة الكاملة، SEO، الصور، النماذج عبر REST، المصادقة إن لزمت، وطبقات الكاش.
المخرج: واجهة كاملة على التجريبيالنشر من ووردبريس وظهوره في الواجهة، المعاينة، إبطال الكاش، Core Web Vitals، وفحص Google للصفحات.
المخرج: تقرير اختباربنيتان تحتيتان موثقتان، إجراءات نشر لكل جهة، ودليل للمحررين وللمطورين.
المخرج: توثيق تشغيل للبنيتينأسئلة شائعة
كم قناة ستستهلك المحتوى، من سيبني ويصون الواجهة، وما الإضافات التي يعتمد عليها موقعك الحالي. إن كان التقليدي أنسب سأقول ذلك.
