ترجمة المقالة إلى العربية

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

لذا قمنا بهدمه وإعادة بناؤه باستخدام Astro. النتيجة: درجات 100 كاملة عبر جميع فئات Lighthouse الأربع — الأداء، إمكانية الوصول، أفضل الممارسات، وتحسين محركات البحث. ليس على صفحة واحدة. على كل صفحة. هذه قصة كيف وصلنا إلى هناك، ما الذي انقطع في الطريق، وما الذي كان يجب أن نفعله بشكل مختلف.

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

WordPress to Astro: How We Hit Lighthouse 100 on Our Rebuild

لماذا تركنا WordPress

حسنًا، WordPress يشغل حوالي 43% من الويب. إنها ليست منصة سيئة. لقد بنينا الكثير من مواقع WordPress للعملاء وسنستمر في القيام بذلك عندما يكون هذا هو الخيار الصحيح. لكن بالنسبة لموقع الوكالة الخاص بنا — موقع تسويقي ثابت في الغالب مع مدونة — كان WordPress مبالغًا فيه بأسوأ طريقة.

إليك شكل إعدادنا على WordPress:

  • المظهر: مظهر مخصص مبني على Sage (Roots.io)
  • المكونات الإضافية: 14 مكونًا إضافيًا نشطًا بما في ذلك Yoast SEO و WP Rocket و Advanced Custom Fields Pro و Gravity Forms وعدد من المكونات الأخرى
  • الاستضافة: خطة WP Engine Professional بـ 60 دولارًا/شهر
  • CDN: Cloudflare Pro بـ 20 دولارًا/شهر
  • تعقيد البناء: قوالب PHP، Webpack للأصول، قاعدة بيانات MySQL

حتى مع قيام WP Rocket بالتخزين المؤقت العدواني، كانت Core Web Vitals الخاصة بنا متوسطة. كان Largest Contentful Paint (LCP) 2.4 ثانية على الهاتف المحمول. كان Cumulative Layout Shift (CLS) 0.12 — ليس سيئًا، لكن ليس جيدًا أيضًا. وفي كل مرة نحدّث مكونًا إضافيًا، كان هناك احتمال غير صفري أن ينقطع شيء ما.

الجزء الفعلي المحرج؟ كنا ندفع 80 دولارًا/شهر في تكاليف الاستضافة لموقع حصل على حوالي 3000 زيارة شهريًا. هذا ليس الكثير من حركة المرور، وهذا الكثير من المال لما كان في الأساس موقع كتيب مع مدونة.

نقطة الانقطاع

جاءت القشة الأخيرة في يناير 2025. تحديث WordPress الأساسي كسر كتل Gutenberg المخصصة لدينا. يتطلب إصلاحها تحديث ACF Pro، مما تطلب تحديث توافق إصدار PHP لمظهرنا، مما تطلب تحديث بيئة الاستضافة. ما كان يجب أن يكون تحديثًا روتينيًا تحول إلى يوم عمل كامل.

نظرت إلى فريقي وقلت، "نخبر العملاء بالذهاب بدون رأس. لماذا لا نأكل من طهينا الخاص؟"

لماذا اخترنا Astro

قيمنا أربعة خيارات لإعادة البناء:

الإطار المميزات العيوب رأينا
Next.js نعرفه جيدًا، نظام بيئي رائع مبالغ فيه لموقع محتوى، يتطلب خادمًا أو وقت تشغيل حافة ثقيل جدًا
Astro موجه للمحتوى، لا يشحن JavaScript افتراضيًا، معمارية الجزر نظام بيئي أصغر، أحدث مناسب تمامًا
Eleventy بسيط، بناء سريع، ناضج نموذج مكون محدود، DX أقل حداثة ثاني قريب
Hugo بناء سريع جدًا، ملف واحد قوالب Go محرجة، مرونة محدودة ليس لنا

نبني الكثير من مشاريع Next.js للعملاء، وهو اختيارنا المفضل لأي شيء به وظائف ديناميكية. لكن لموقع غني بالمحتوى التسويقي؟ Next.js يشحن وقت تشغيل JavaScript سواء احتجت إليه أم لا. حتى مع التصدير الثابت، أنت ترسل React إلى المتصفح.

تناسبت فلسفة Astro معنا: شحن HTML، أضف JavaScript فقط حيث تحتاج إليه. تعني معمارتهم بالجزيرة أنه يمكنك أن يكون لديك مكون React تفاعلي تمامًا بجانب HTML ثابت تمامًا، والأجزاء الثابتة لا تشحن أي JavaScript. هذا بالضبط ما احتجناه.

كنا أيضًا نقوم بمزيد من عمل تطوير Astro للعملاء طوال عام 2024، لذا كان الفريق مرتاحًا للإطار. لم تكن تمرينًا في التعلم — كانت أداة نثق بها بالفعل.

سؤال طبقة المحتوى

قرار اتخذناه في وقت مبكر: لم نكن سنستخدم CMS بدون رأس لموقعنا الخاص. بالنسبة لمشاريع العملاء، غالبًا ما نوصي بـ إعدادات CMS بدون رأس مع Contentful أو Sanity أو Storyblok. لكن بالنسبة لمدونتنا، حيث كل مؤلف مطور مرتاح مع Markdown و Git؟ Content Collections في Astro مع ملفات MDX المرتكبة على الريبو كانت أبسط وأسرع.

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

استراتيجية الهجرة

لم نقم بهجرة انفجار كبيرة. إليك نهجنا المرحلي:

المرحلة 1: تدقيق المحتوى (أسبوع واحد) قمنا بتصدير جميع محتويات WordPress باستخدام wp-cli وتحويل المنشورات إلى MDX باستخدام نص مخصص مبني مع turndown (محول HTML إلى Markdown) بالإضافة إلى بعض تنظيف regex. كان لدينا 47 مشاركة مدونة في الوقت الذي كنا فيه. حوالي 12 منها كانت قديمة أو منخفضة الأداء، لذا أعدنا توجيهها إلى محتوى أحدث ذي صلة ولم نهاجرها.

المرحلة 2: نظام التصميم في Astro (أسبوعان) أعدنا بناء مكتبة المكونات الخاصة بنا كمكونات Astro. أزرار، بطاقات، تخطيطات القسم، الملاح — كل شيء كملفات .astro. لا يتطلب إطار عمل لأي منها. HTML و CSS نقي مع أنماط محدودة النطاق.

المرحلة 3: بناء الصفحة (أسبوعان) الصفحة الرئيسية، صفحات الإمكانيات، حول، جهة الاتصال، قائمة المدونة، منشورات المدونة الفردية، 404. بنينا جميعها كصفحات Astro مع مكتبة المكونات الخاصة بنا.

المرحلة 4: ضبط الأداء (أسبوع واحد) هنا حدث العمل الفعلي لـ Lighthouse 100. المزيد حول هذا أدناه.

المرحلة 5: الإطلاق وإعادة التوجيه (يومان) قمنا بإعداد عمليات إعادة توجيه 301 صحيحة لكل عنوان URL قديم، والتحقق باستخدام Screaming Frog بعدم كسر أي شيء، وتقديم خريطة الموقع الجديدة إلى Google Search Console، وتبديل DNS.

الجدول الزمني الإجمالي: حوالي 6 أسابيع من العمل بدوام جزئي إلى جانب مشاريع العملاء.

WordPress to Astro: How We Hit Lighthouse 100 on Our Rebuild - architecture

قرارات العمارة التي أحدثت الفرق

لا JavaScript افتراضيًا

موقعنا بالكامل يشحن حوالي 2KB من JavaScript إجمالاً. هذا ليس خطأ مطبعي. كيلوبايتان. ومعظم ذلك هو نص صغير لتبديل الملاح على الهاتف المحمول والتحليلات.

إليك ملاح الهاتف المحمول الخاص بنا — لا إطار عمل، لا التبعيات:

---
// MobileNav.astro
---
<button id="menu-toggle" aria-expanded="false" aria-controls="mobile-menu">
  <span class="sr-only">Toggle menu</span>
  <svg><!-- hamburger icon --></svg>
</button>
<nav id="mobile-menu" hidden>
  <slot />
</nav>

<script>
  const toggle = document.getElementById('menu-toggle');
  const menu = document.getElementById('mobile-menu');
  
  toggle?.addEventListener('click', () => {
    const expanded = toggle.getAttribute('aria-expanded') === 'true';
    toggle.setAttribute('aria-expanded', String(!expanded));
    menu?.toggleAttribute('hidden');
  });
</script>

تُحزم علامة <script> في مكون Astro تلقائيًا وتُنزع تكرارها. إنها صغيرة، إنها vanilla JS، وتعمل في كل مكان.

استراتيجية CSS: أنماط محدودة النطاق + طبقة عامة بسيطة

استخدمنا CSS محدودة النطاق المدمجة في Astro لأنماط مستوى المكون وورقة نمط عامة واحدة (حوالي 8KB مضغوطة) لتصنيف الخط والإعادة والخصائص المخصصة وفئات الأداة. لا Tailwind. رأي مثير للجدل، أعرف.

نحب Tailwind للتطبيقات الأكبر ومشاريع العملاء. لكن لموقع بهذا الحجم الصغير، أضافت تعقيد البناء وحجم الملف الذي لم نحتجه. CSS المكتوب بخط اليد أصغر من مخرجات Tailwind التي كانت ستكون عليها، حتى مع التطهير.

/* Global custom properties */
:root {
  --color-text: #1a1a2e;
  --color-bg: #ffffff;
  --color-accent: #e94560;
  --color-accent-dark: #c81e45;
  --font-body: 'Inter', system-ui, sans-serif;
  --font-heading: 'Cal Sans', var(--font-body);
  --max-width: 72rem;
  --space-unit: 0.25rem;
}

التوليد الثابت مع الحمل المسبق الذكي

يتم إنشاء كل صفحة بشكل ثابت وقت البناء. نستخدم تكامل prefetch المدمج في Astro لتحميل الروابط مسبقًا عند المرور، مما يجعل الملاح يشعر فوري:

// astro.config.mjs
import { defineConfig } from 'astro/config';
import mdx from '@astrojs/mdx';
import sitemap from '@astrojs/sitemap';

export default defineConfig({
  site: 'https://socialanimal.dev',
  integrations: [mdx(), sitemap()],
  prefetch: {
    prefetchAll: false,
    defaultStrategy: 'hover',
  },
  build: {
    inlineStylesheets: 'auto',
  },
});

الغوص العميق في تحسينات الأداء

الوصول إلى Lighthouse 100 لا يتعلق فقط باختيار الإطار الصحيح. Astro يعطيك بداية قوية، لكن آخر 10-15 نقطة تتطلب جهدًا مقصودًا. إليك ما فعلناه.

تحسين الصور

يتعامل مكون <Image /> المدمج في Astro مع الصور المتجاوبة مع تحويل الصيغة التلقائي (WebP/AVIF)، والتحميل الكسول، وسمات width/height الصحيحة لمنع CLS.

---
import { Image } from 'astro:assets';
import heroImage from '../assets/hero.jpg';
---
<Image 
  src={heroImage} 
  alt="Social Animal development team working on headless architecture"
  widths={[400, 800, 1200]}
  sizes="(max-width: 600px) 400px, (max-width: 900px) 800px, 1200px"
  format="avif"
  fallbackFormat="webp"
  quality={80}
  loading="eager"
/>

بالنسبة لصورة البطل على وجه التحديد، نستخدم loading="eager" لأنها فوق الطي. كل شيء آخر يحصل على loading="lazy" افتراضيًا.

مررنا أيضًا بكل صورة على الموقع وسألنا: "هل تحتاج هذه إلى أن تكون صورة؟" تحولت عناصر زخرفية عديدة إلى تدرجات CSS أو SVGs بدلاً من ذلك. خلفية قسم البطل الخاص بنا، على سبيل المثال، هي تدرج CSS مع نسيج ضوضاء دقيق طُبق عبر SVG مضمن صغير.

استراتيجية تحميل الخط

الخطوط هي قاتل Lighthouse. إليك نهجنا:

  1. استضفها بنفسك. لا Google Fonts CDN. قمنا بتنزيل Inter و Cal Sans ونخدمهما من نطاقنا الخاص. هذا يزيل بحث DNS والاتصال بـ TCP ومصافحة TLS إلى fonts.googleapis.com.

  2. حد أحرف بعدوانية. استخدمنا glyphhanger لتحليل الأحرف التي نستخدمها فعلاً، ثم حددنا خطوطنا مع pyftsubset. ذهب Inter Regular WOFF2 من 96KB إلى 18KB.

  3. استخدم font-display: swap مع نوع خط نظام نسخة احتياطية يطابق المقاييس بشكل وثيق، مما يقلل التحول أثناء المبادلة.

  4. قم بتحميل ملفات الخط الحرجة مسبقًا:

<link rel="preload" href="/fonts/inter-latin-400.woff2" as="font" type="font/woff2" crossorigin />
<link rel="preload" href="/fonts/cal-sans-latin-600.woff2" as="font" type="font/woff2" crossorigin />

الاستضافة: صفحات Cloudflare

انتقلنا من WP Engine (60 دولار/شهر) إلى Cloudflare Pages (الطبقة المجانية). نعم، مجاني. موقعنا ضمن حدود الخطة المجانية من Cloudflare — 500 نسخة شهريًا، نطاق ترددي غير محدود، طلبات غير محدودة.

تُنشر صفحات Cloudflare من دفع Git، وتُخدم من شبكتهم العامة، وتتعامل مع رؤوس الذاكرة المؤقتة تلقائيًا. أوقات البناء متوسط 22 ثانية لموقعنا بالكامل. قارن ذلك مع إعدادنا على WordPress حيث يمكن لتطهير الذاكرة المؤقتة وحده أن يستغرق وقتًا أطول.

انخفضت تكلفة الاستضافة الشهرية من 80 دولارًا إلى 0 دولار.

محاذاة CSS الحرجة

Astro تحزم تلقائيًا أوراق الأنماط الصغيرة عندما تعيّن build.inlineStylesheets: 'auto'. بالنسبة لصفحاتنا، يتم محاذاة كل نمط حرج في <head>، مما يعني عدم وجود طلبات CSS محظورة للتصيير. يمكن للمتصفح البدء بالرسم فورًا.

انضباط نصوص الطرف الثالث

هنا تفقد معظم المواقع درجاتها المثالية. كل نص من طرف ثالث هو كارثة محتملة للأداء. حددنا بقسوة لدينا:

  • التحليلات: التبديل من Google Analytics (70KB+ من JavaScript) إلى Plausible Analytics (< 1KB نص، محمل بشكل غير متزامن). ندفع 9 دولارات/شهر لـ Plausible، وجودة البيانات أفضل فعلاً لاحتياجاتنا.
  • النماذج: نموذج الاتصال الخاص بنا في /contact يستخدم نموذج HTML بسيط مع معالجة من جانب الخادم عبر Cloudflare Pages Functions. لا مكتبة نماذج JavaScript.
  • لا أدوات الدردشة. لا عمليات تضمين وسائط اجتماعية. لا لافتات قبول ملفات تعريف الارتباط (لا نستخدم ملفات تعريف الارتباط التي تتطلب موافقة).

بطاقة درجات Lighthouse 100

إليك درجات Lighthouse الفعلية الخاصة بنا اعتبارًا من مايو 2025، مقاسة باستخدام Chrome DevTools على اتصال مقيد (محاكاة الهاتف المحمول الافتراضية في Lighthouse):

المقياس الدرجة
الأداء 100
إمكانية الوصول 100
أفضل الممارسات 100
تحسين محركات البحث 100
First Contentful Paint 0.6 ثانية
Largest Contentful Paint 0.8 ثانية
Total Blocking Time 0ms
Cumulative Layout Shift 0
Speed Index 0.8 ثانية

Total Blocking Time الخاص بي من 0ms هو إحصائيتي المفضلة. صفر. لا يوجد أساسًا JavaScript يحظر الخيط الرئيسي. أبدًا.

قبل وبعد: الأرقام

المقياس WordPress (قبل) Astro (بعد) التحسن
أداء Lighthouse 58 100 +72%
LCP (الهاتف المحمول) 2.4 ثانية 0.8 ثانية 3x أسرع
CLS 0.12 0 تم حذفه
TBT 380ms 0ms تم حذفه
وزن الصفحة (الرئيسية) 1.8MB 142KB 92% أصغر
طلبات HTTP 47 6 87% أقل
JavaScript المشحون 340KB 2KB 99.4% أقل
تكلفة الاستضافة الشهرية 80 دولار 9 دولارات (Plausible فقط) 89% أرخص
وقت البناء/الانتشار 3-5 دقائق 22 ثانية ~10x أسرع
وقت البايت الأول 420ms 18ms 23x أسرع

انخفاض وزن الصفحة مذهل حتى بالنسبة لنا. 1.8MB لأسفل إلى 142KB. هذا ما يحدث عندما تتوقف عن شحن jQuery و React و محمل النصوص بـ WP Rocket و حاقن علامات الشيما بـ Yoast و أربعة عشر ورقة نمط مكون إضافي.

ما الذي أخطأنا فيه على طول الطريق

لم تكن كل الأمور سلسة. حان وقت الصراحة.

الخطأ 1: كدنا نهندس الإفراط في إدارة المحتوى

غريزتنا الأولى كانت إعداد Sanity كـ CMS بدون رأس للمدونة. قضينا يومين في تكوين الأنماط وإعداد Sanity Studio قبل أن نتراجع ونسأل، "من سيستخدم هذا فعلاً؟" الجواب كان... نحن. مطورين. الذين يرتاحون تمامًا لكتابة MDX في VS Code. قمنا بسحب Sanity والانتقال إلى Astro Content Collections. وفرت التكاليف المستمرة والتعقيد.

الخطأ 2: حد الخط كسر الأحرف الخاصة

كان حد الخط الأولي لدينا عدوانيًا جدًا. قمنا بتجريد الأحرف التي اعتقدنا أننا لن نستخدمها أبدًا، ثم نشرنا منشاور مدونة برقم em dash وعدد قليل من علامات الاستشهام المنحنية التي تم تقديمها كصناديق. الدرس: اختبر حدودك مع محتوى حقيقي، وليس فقط "ABCDEFG."

الخطأ 3: نسينا صور OpenGraph

لقد أطلقنا بدون صور OG ديناميكية. عندما يشارك شخص ما منشاور مدونة على Twitter/X أو LinkedIn، أظهر احتياطيًا عامًا. كان علينا العودة وبناء خط أنابيب توليد صور OG باستخدام @astrojs/og (الذي يستخدم Satori تحت الغطاء). كان يجب أن يكون في النطاق الأصلي.

الخطأ 4: خريطة إعادة التوجيه 301 كانت بها ثغرات

على الرغم من استخدام Screaming Frog لتعيين عناوين URL القديمة، فقدنا حفنة من عناوين URL للصور التي كانت مواقع خارجية تربط ارتباطات ساخنة بها. اكتشفنا هذه في تحليلات Cloudflare حوالي أسبوع بعد الإطلاق وأضفنا عمليات إعادة التوجيه المفقودة. تحقق دائمًا من سجلات الخادم بعد الهجرة — لن تلتقط Google Search Console بكل شيء.

دروس لهجرتك الخاصة

إذا كنت تفكر في الانتقال من WordPress إلى إطار موجه نحو الثابت، فإليك ما كنت سأخبرك به:

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

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

  3. لا تنسخ معمارتك القديمة. لم نحاول تكرار إعدادنا على WordPress في Astro. أعدنا التفكير في كل شيء من الصفر. هل نحتاج فعلاً إلى مكون إضافي لنماذج؟ لا، عنصر <form> مع دالة بدون خادم يعمل بشكل جيد.

  4. قس قبل، وقس بعد، وقس بشكل مستمر. أعددنا وظيفة Lighthouse CI في GitHub Actions التي تعمل على كل طلب سحب. إذا انخفضت أي درجة أقل من 95، فإن الفحص يفشل.

  5. ميزانية آخر 5%. الانتقال من Lighthouse 85 إلى 95 مباشر. الانتقال من 95 إلى 100 يتطلب حد الخط وتحليل CSS الحرج وتحسين صيغ الصور ومراجعة نصوص الطرف الثالث. خطط لها.

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

إذا كنت مهتمًا برؤية كيف ستبدو الهجرة مثل هذه لمشروعك، فراجع صفحة التسعير أو تواصل معنا. لقد فعلنا مسار الهجرة هذا لعدة عملاء الآن، وتكاليف الأداء متسقة بشكل دراماتيكي.

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

كم من الوقت يستغرق الهجرة من موقع WordPress إلى Astro؟ بالنسبة لموقعنا (حوالي 50 صفحة بما في ذلك منشورات المدونة)، استغرق الأمر حوالي 6 أسابيع من العمل بدوام جزئي. قد تستغرق الموقع الأكبر مع مئات المنشورات وأنواع المنشورات المخصصة المعقدة 8-12 أسبوع. التطوير الفعلي عادة ما يكون أسرع من تدقيق المحتوى وتعيين إعادة التوجيه.

هل يمكنك الحصول على Lighthouse 100 مع Next.js بدلاً من Astro؟ من الممكن لكن أصعب بشكل كبير. Next.js يشحن وقت تشغيل JavaScript للمتصفح حتى للصفحات الثابتة (طبقة ترطيب React). يمكنك الاقتراب — درجات 95-99 قابلة للتحقيق مع التحسين الحذر. لكن نهج Astro الذي لا يحتوي على JavaScript افتراضيًا يجعل الدرجات المثالية أكثر قابلية للتحقيق بكثير لمواقع المحتوى.

ماذا عن ميزات WordPress مثل نماذج الاتصال والبحث؟ تعمل نماذج الاتصال بشكل جيد مع نماذج HTML عادية ودالة خادم بدون خادم (Cloudflare Pages Functions و Netlify Functions وغيرها). للبحث، نستخدم بحثًا من جانب العميل مع Pagefind، الذي يبني فهرس بحث في وقت البناء ويشحن فقط 5KB من JavaScript. إنه سريع ويعمل بدون اتصال بالإنترنت.

هل الهجرة من WordPress إلى Astro تضر بـ SEO؟ ليس إذا تعاملت معها بشكل صحيح. قمنا بإعداد عمليات إعادة توجيه 301 لكل عنوان URL، وحافظنا على بنية URL الخاصة بنا حيث كان ممكنًا، وقدمنا خريطة موقع جديدة، والحفاظ على جميع البيانات المنظمة. انخفضت حركة المرور العضوية لدينا بنسبة 23% في الأشهر الثلاثة بعد الهجرة، ربما بسبب Core Web Vitals المحسّنة.

كيف تتعامل مع المحتوى الديناميكي مثل التعليقات على موقع Astro؟ لا نملك تعليقات على مدونتنا — كانت معظمها رسائل غير مرغوب على WordPress على أي حال. إذا كنت بحاجة إلى تعليقات، فإن خدمات مثل Giscus (القائمة على GitHub Discussions) أو Hyvor Talk تعمل بشكل جيد كمكونات مضمنة. يتم تحميلها كجزر Astro، لذا فهي لا تؤثر على تحميل الصفحة الأولي.

هل Astro جاهزة للإنتاج للمواقع الكبيرة؟ بكل تأكيد. Astro 5.x (الصادرة في أواخر 2024) ناضجة واستقرار. شركات مثل Porsche و Google و Microsoft و Netlify تستخدمها في الإنتاج. أداء البناء تتسع بشكل جيد أيضًا — المواقع التي تحتوي على آلاف الصفحات تُبنى في أقل من دقيقة مع التكوين الصحيح.

ما يشبه الصيانة المستمرة بالمقارنة مع WordPress؟ أقل بشكل مذهل. لا تحديثات المكون الإضافي، لا صيانة قاعدة البيانات، لا تصحيحات أمان لـ PHP. نحدث Astro والتبعيات الخاصة به ربما مرة واحدة في الشهر عبر Dependabot PRs. يستغرق كل تحديث حوالي 5 دقائق للمراجعة والدمج. قارن ذلك مع حزام تحديث WordPress.

هل يمكن لأعضاء الفريق غير التقنيين تحرير المحتوى على موقع Astro؟ مع إعدادنا (ملفات MDX في Git)، تحتاج إلى الراحة مع Markdown و Git workflows الأساسية. بالنسبة للفرق التي تحتوي على محررين غير تقنيين، نوصي بإقران Astro مع CMS بدون رأس مثل Sanity أو Contentful أو Storyblok. يحصل المحررون على واجهة مرئية، وتحصل على جميع فوائد الأداء للتوليد الثابت.