انتقل من Gatsby إلى Astro | Social Animal
الخليفة الطبيعي لـ Gatsby لمواقع المحتوى
Why leave Gatsby?
- GraphQL data layer adds unnecessary complexity for content sites that just need to read local files.
- Build times scale poorly—500+ page sites can take 15-30 minutes to rebuild.
- Gatsby ships the full React runtime to every page, even purely static content with zero interactivity.
- The plugin ecosystem is deteriorating with unmaintained dependencies and mounting security vulnerabilities.
- Active development has stalled since the Netlify acquisition, with no clear roadmap for major improvements.
What you gain
- Zero client-side JavaScript by default, with Lighthouse mobile scores consistently hitting 95-100.
- Content collections provide type-safe content querying without GraphQL overhead—just getCollection() calls.
- Build times drop 80-90%, with 500-page sites building in under 30 seconds via Vite.
- Islands architecture lets you hydrate only interactive components, keeping the rest as pure HTML.
- Active development community with major releases every few months and a growing integration ecosystem.
لماذا يترك المطورون Gatsby للانتقال إلى Astro
كان لـ Gatsby فترة جيدة. لقد رسخت فئة مولدات المواقع الثابتة القائمة على React وقدّمت الآلاف من المطورين إلى JAMstack. لكنها توقفت. استحوذت Netlify على Gatsby في أوائل 2023، تباطأ التطوير بشكل كبير، ينهار النظام البيئي للمكونات الإضافية، وأوقات البناء على مواقع المحتوى الكبيرة لا تزال بطيئة بشكل مؤلم.
تم بناء Astro لحل المشاكل التي أنشأتها Gatsby بالضبط. لا توجد JavaScript افتراضياً، مجموعات محتوى تحل محل تعقيد GraphQL، وأوقات بناء تجعل Gatsby تبدو بطيئة بشكل محرج. إذا كنت تحافظ على موقع محتوى Gatsby، فإن الهجرة إلى Astro ليست مجرد ترقية—إنها متأخرة جداً.
نقاط الألم في Gatsby التي تدفع الهجرة
تعقيد GraphQL للبيانات البسيطة
كانت طبقة بيانات GraphQL في Gatsby مبتكرة عند إطلاقها. كانت أيضاً مبالغاً فيها بشكل هائل لمعظم مواقع المحتوى. هل تريد إدراج منشورات مدونتك؟ اكتب استعلام GraphQL. هل تريد سحب frontmatter من ملف markdown؟ استعلام GraphQL. هل تريد عرض صورة؟ استعلام GraphQL مغلف في مكون خاص.
بالنسبة لموقع تسويقي بـ 50 صفحة، أنت تحافظ على عشرات استعلامات GraphQL فقط لتقديم محتوى يعيش في نظام الملفات الخاص بك. يضيف التجريد عبئاً معرفياً بدون فائدة متناسبة.
أوقات بناء لا تتسع بشكل جيد
تعالج خط أنابيب بناء Gatsby كل صفحة عبر طبقة GraphQL الخاصة به، وتشغل تحويلات الصور، وتولد حزمة React الكاملة لكل مسار. يمكن لموقع محتوى بـ 500 صفحة أن يستغرق 10-15 دقيقة للبناء. موقع بـ 2000 صفحة؟ أنت تنظر إلى 30+ دقيقة، حتى مع تفعيل الإنشاءات الإضافية.
كل تحديث محتوى يعني الانتظار. كل إصلاح خطأ إملائي يعني الانتظار. يبدأ فريق المحتوى بك في الاستياء من الأداة.
النظام البيئي للمكونات الإضافية يتدهور
كانت قوة Gatsby هي النظام البيئي للمكونات الإضافية—gatsby-plugin-image و gatsby-plugin-sharp و gatsby-source-filesystem و gatsby-transformer-remark. لم يتم تحديث العديد من هذه المكونات الإضافية بشكل مجدٍ لأكثر من سنة. تتكاثر نزاعات الاعتماديات. تتراكم التنبيهات الأمنية. تقوم بتشغيل npm audit وترى 47 ثغرة أمنية، معظمها مدفون بعمق في شجرة اعتماديات Gatsby.
حزم JavaScript ثقيلة
يشحن Gatsby وقت تشغيل React بالكامل لكل زائر، حتى للصفحات التي لا تحتوي على أي تفاعل. لا تزال صفحة "من نحن" الثابتة تحمّل React و ReactDOM و وقت تشغيل Gatsby. تنخفض درجات Lighthouse الخاصة بك، تغرق Core Web Vitals، ويدفع المستخدمون على اتصالات أبطأ الثمن.
ما يعطيك Astro
مجموعات المحتوى تحل محل GraphQL
تم تصميم مجموعات محتوى Astro خصيصاً لمواقع المحتوى. حدّد مخطط في TypeScript، ضع ملفات markdown في مجلد، استعلم عنها باستخدام getCollection('blog'). لا GraphQL. لا مكونات إضافية خاصة. التحقق من صحة frontmatter الآمن من النوع خارج الصندوق.
// src/content/config.ts
import { defineCollection, z } from 'astro:content';
const blog = defineCollection({
schema: z.object({
title: z.string(),
date: z.date(),
tags: z.array(z.string()),
image: z.string().optional(),
}),
});
هذا كل شيء. لا gatsby-node.js، لا createPages API، لا GraphQL fragments. جلب البيانات الخاصة بك هو استدعاء دالة واحدة في المكون الذي يحتاجه.
لا توجد JavaScript افتراضياً
يشحن Astro صفر JavaScript من جهة العميل ما لم تختر الدخول صراحة. يرسل موقع تسويقي بـ 50 صفحة HTML و CSS نقية إلى المتصفح. عندما تحتاج إلى التفاعل—نموذج اتصال، دوامة صور، أداة بحث—تستخدم هندسة الجزر في Astro لترطيب ذلك المكون فقط.
النتيجة: درجات Lighthouse بقيمة 95-100 على الهاتف المحمول بدون أي خدع تحسين.
بناء أقل من ثانية
يعمل Astro على Vite. موقع محتوى بـ 500 صفحة ينشئ في أقل من 30 ثانية. موقع بـ 2000 صفحة ينشئ في أقل من دقيقتين. استبدال الوحدة الساخنة في التطوير فوري. يمكن لفريق المحتوى الخاص بك معاينة التغييرات في أجزاء من الثانية بدلاً من انتظار خادم تطوير Gatsby لإعادة تجميع مخطط GraphQL الخاص به.
مكونات مستقلة عن الإطار
هل لديك بالفعل مكونات React من موقع Gatsby الخاص بك؟ يقوم Astro بتقديمها في وقت البناء أو ترطيبها من جانب العميل—اختيارك. هل تريد الهجرة تدريجياً إلى مكونات Astro، أو تجربة Vue أو Svelte لميزات محددة؟ يدعم Astro جميعها في نفس المشروع.
عملية الهجرة من Gatsby إلى Astro الخاصة بنا
المرحلة 1: التدقيق والعمارة (الأسبوع 1)
نبدأ بتعيين موقع Gatsby الموجود—كل قالب صفحة، كل استعلام GraphQL، كل اعتماد مكون إضافي، كل مسار ديناميكي. نوثق تكوين gatsby-node.js الخاص بك، نحدد المكونات الإضافية المصدر المخصصة، ونوثق جميع التكاملات الخارجية.
من هناك، نصمم عمارة Astro: مخططات مجموعة المحتوى، والتسلسل الهرمي للتخطيط، واختيارات التكامل، والهدف النشر.
المرحلة 2: هجرة المحتوى (الأسبوع 2)
ننشئ نصوصاً تلقائية للهجرة تحول محتواك من بنية Gatsby إلى مجموعات محتوى Astro. يتم التحقق من صحة مخططات Frontmatter وتطبيعها. يتم تعيين مكونات MDX إلى نظراء Astro الخاص بهم أو تغليفها كجزر إطار عمل.
يتم تحويل استخدام gatsby-image الخاص بـ Gatsby إلى مكون <Image /> المدمج في Astro، والذي يتعامل مع الصور المتجاوبة وتحويل الصيغة والتحميل البطيء بشكل أصلي—لا تحتاج إلى سلسلة مكونات إضافية.
المرحلة 3: تحويل القوالب والمكونات (الأسبوعان 2-3)
تصبح قوالب صفحة Gatsby تخطيطات وصفحات Astro. مكونات React التي لا تحتاج إلى تفاعل من جانب العميل تصبح مكونات Astro—أبسط، أسرع، بدون JS. المكونات التفاعلية تبقى كـ React (أو يتم إعادة كتابتها) وتستخدم تعليمات client: للترطيب الجزئي.
نستبدل مكونات Gatsby الإضافية بتكاملات Astro:
gatsby-plugin-sitemap→@astrojs/sitemapgatsby-plugin-feed→ RSS مخصص مع@astrojs/rssgatsby-plugin-mdx→ دعم MDX المدمج عبر@astrojs/mdxgatsby-plugin-sharp→astro:assetsتحسين الصور المدمج
المرحلة 4: الحفاظ على SEO (الأسبوع 3)
هنا حيث تعيش الهجرات أو تموت. ننفذ استراتيجية الحفاظ على URL شاملة:
- إعادات التوجيه 301 لأي تغييرات في بنية URL، المُعدة على مستوى الاستضافة لإعادة توجيهات بدون تأخير
- علامات Canonical على كل صفحة مطابقة لبنية URL الموجودة لديك
- البيانات المنظمة (JSON-LD) تم ترحيلها والتحقق منها ضد اختبار Rich Results من Google
- علامات Meta محفوظة بالضبط—عناوين الصفحات والأوصاف وOpen Graph وTwitter Cards
- خريطة XML الموقع المُعاد إنشاؤها وتقديمها إلى Google Search Console
- تدقيق الارتباط الداخلي لاكتشاف أي مراجع مكسورة بعد الهجرة
نراقب Google Search Console لمدة 30 يوماً بعد الإطلاق لاكتشاف مشاكل الفهرسة على الفور.
المرحلة 5: الاختبار والإطلاق (الأسبوع 4)
اختبار الانحدار البصري الكامل ضد موقع Gatsby الموجود. معايير الأداء مقارنة جنباً إلى جنب. تدقيق إمكانية الوصول. الاختبار عبر المتصفحات. ننشر على URL مرحلي لفريقك للمراجعة، ثم نقطع مع عدم توقف.
إذا كان موقع Gatsby الخاص بك يستخدم عامل خدمة (شائع مع gatsby-plugin-offline)، فإننا ننشر عامل خدمة بديل يفرض إبطال ذاكرة التخزين المؤقت على متصفحات الزوار الموجودة—خطوة يتخطاها معظم أدلة الهجرة بالكامل.
الجدول الزمني والتسعير
عادة ما تعمل هجرة Gatsby إلى Astro لموقع محتوى بـ 50-200 صفحة 3-4 أسابيع وتبدأ من 8000 دولار. قد تحتاج المواقع الأكبر بمكونات إضافية مخصصة أو توجيه ديناميكي معقد أو تكامل CMS ثقيل إلى 5-6 أسابيع.
عوامل النطاق تشمل: عدد قوالب الصفحات الفريدة، مكونات Gatsby المخصصة، تكاملات API من جهات خارجية، وما إذا كنت تريد الاحتفاظ بمكونات React أو تحويل كل شيء إلى Astro الأصلي.
الخط السفلي
Gatsby ليست ميتة، لكنها لا تتحسن. Astro قيد التطوير النشط، لديها مجتمع مزدهر، وتم تصميمها من الألف إلى الياء للمواقع الثقيلة المحتوى. مسار الهجرة موثق بشكل جيد، مكاسب الأداء فورية، وسيشكرك فريق التطوير الخاص بك على القضاء على GraphQL boilerplate.
توقف عن صيانة إطار عمل يقف في مكانه. انتقل إلى الذي يتحرك بسرعة.
The migration process
Discovery & Audit
We map every page, post, media file, redirect, and plugin. Nothing gets missed.
Architecture Plan
New stack designed for your content structure, SEO requirements, and performance targets.
Staged Migration
Content migrated in batches. Each batch verified before the next begins.
SEO Preservation
301 redirects, canonical tags, sitemap, robots.txt — every ranking signal carried over.
Launch & Monitor
DNS cutover with zero downtime. 30-day monitoring period included.
Gatsby vs Astro
| Metric | Gatsby | Astro |
|---|---|---|
| Lighthouse Mobile | 45-65 | 95-100 |
| TTFB | 1.2-2.5s | <0.2s |
| Build Time (500 pages) | 8-15 min | 15-30s |
| Client JS Bundle | 200-400 KB | 0 KB (default) |
| Hosting Cost | $20-50/mo | $0-20/mo |
| Content Querying | GraphQL (complex) | Content Collections (simple) |
Common questions
كم من الوقت تستغرق هجرة Gatsby إلى Astro؟
تستغرق معظم مواقع المحتوى بـ 50-200 صفحة 3-4 أسابيع للهجرة. يغطي ذلك هجرة المحتوى وتحويل القالب والحفاظ على SEO والاختبار الشامل. قد تحتاج المواقع الأكبر بمكونات Gatsby مخصصة أو توجيه ديناميكي معقد إلى 5-6 أسابيع. نعطيك جدول زمني مفصل بعد تدقيق إعداد Gatsby المحدد الخاص بك.
هل سأفقد تصنيفات Google الخاصة بي أثناء الهجرة؟
لا، إذا تمت بشكل صحيح. ننفذ إعادات توجيه 301 لكل URL، نحافظ على جميع علامات meta والبيانات المنظمة، نحافظ على خريطة XML الموقع الخاصة بك، ونراقب Search Console لمدة 30 يوماً بعد الإطلاق. تم تصميم عملية الحفاظ على SEO الخاصة بنا خصيصاً لحماية تصنيفاتك الموجودة وحركة البحث العضوية من خلال الانتقال.
هل يمكنني الاحتفاظ بمكونات React الخاصة بي عند الهجرة إلى Astro؟
نعم. يدعم Astro مكونات React أصلياً من خلال هندسة الجزر الخاصة به. يمكن ترطيب مكونات React التفاعلية من جانب العميل باستخدام تعليمات العميل في Astro. تقوم مكونات React الثابتة بالعرض في وقت البناء بدون JavaScript مُرسل. يمكنك أيضاً تحويل مكونات React تدريجياً إلى مكونات Astro الأصلية بمرور الوقت—لا توجد ضغط للقيام بكل ذلك في المرة الواحدة.
كم أسرع هو Astro مقارنة بـ Gatsby؟
عادة ما تنخفض أوقات البناء بنسبة 80-90%. موقع Gatsby يستغرق 10 دقائق للبناء غالباً ما ينتهي في أقل من 60 ثانية مع Astro. كما تتحسن أداء تحميل الصفحة بشكل كبير—يشحن Astro صفر JavaScript افتراضياً، لذا تقفز درجات Lighthouse للهاتف المحمول من نطاق 45-65 إلى 95-100 بدون أي خدع تحسين.
ما الذي يحل محل طبقة بيانات GraphQL في Gatsby في Astro؟
تحل مجموعات محتوى Astro محل GraphQL للمحتوى المحلي. تحدد مخطط TypeScript، وضع الملفات في دليل المحتوى، والاستعلام مع getCollection() أو getEntry(). بالنسبة لمصادر البيانات الخارجية، يستخدم Astro استدعاءات جلب قياسية في وقت البناء. إنها أبسط بشكل كبير—لا توجد شظايا الاستعلام، لا خياطة المخطط، لا جلسات تصحيح GraphiQL.
ما الذي يحدث لـ gatsby-image وتحسين الصور؟
يحتوي Astro على تحسين صور مدمج من خلال وحدة astro:assets ومكون Image. يتعامل مع الأحجام المتجاوبة والتحميل البطيء وتحويل الصيغة التلقائي إلى WebP و AVIF بشكل أصلي. لا تحتاج إلى سلسلة مكونات إضافية. نحول جميع استخدام gatsby-image إلى مكون Image في Astro أثناء الهجرة، بجودة إخراج معادلة أو أفضل.
هل Astro خيار جيد إذا كان موقع Gatsby الخاص بي يستخدم CMS بدون رأس؟
بالتأكيد. يتكامل Astro بنعومة مع كل CMS بدون رأس رئيسي—Contentful و Sanity و Storyblok و Strapi وغيرها—باستخدام استدعاءات API القياسية أو التكاملات الرسمية. على عكس مكونات مصدر Gatsby وطبقة GraphQL، يجلب Astro بيانات CMS مباشرة في وقت البناء، الأمر الذي يسهل عملية تصحيح الأخطاء والصيانة.
ما هي عيوب استخدام Gatsby؟
قد يكون Gatsby صعباً بسبب أوقات البناء المعقدة للمواقع الأكبر، مما قد يبطئ عملية التطوير. يعتمد بشكل كبير على GraphQL، والتي قد يكون لها منحنى تعليمي حاد للمطورين غير المألوفين بها. النظام البيئي للمكونات الإضافية الخاص بـ Gatsby، على الرغم من أنه واسع النطاق، قد يؤدي أحياناً إلى مشاكل الاعتماديات أو مشاكل التوافق. بالإضافة إلى ذلك، لأنها مولد موقع ثابت، يتطلب المحتوى الديناميكي تكوينات إضافية، مما قد يضيف التعقيد وقد لا يكون مثالياً للمواقع التي تحتاج إلى تحديثات متكررة.
لماذا تستخدم Gatsby بدلاً من React؟
غالباً ما يُفضل Gatsby على React لبناء المواقع الثابتة بسبب قدرات توليد المواقع الثابتة القوية. يأتي مع نظام بيئي غني من المكونات الإضافية التي تبسط المهام مثل الحصول على البيانات وتحسين الصور، مما قد يسرع بشكل كبير من وقت التطوير. يتضمن إعداد Gatsby الافتراضي أيضاً تحسينات الأداء مثل تقسيم الكود والتحميل البطيء، والتي قد تكون شاقة يدوياً في إعداد React النقي. بالإضافة إلى ذلك، يسمح تكامل GraphQL الخاص بـ Gatsby بالاستعلام المرن عن البيانات، مما يجعله خياراً قوياً للمواقع الثقيلة المحتوى.
Ready to migrate?
Free assessment. We'll audit your current site and give you a clear migration plan — no commitment.
Let's build
something together.
Whether it's a migration, a new build, or an SEO challenge — the Social Animal team would love to hear from you.