قررت مساعدة أولئك المنشغلين في اختيار SSG. قام أحد زملائي بتجميع قائمة من الأسئلة لمساعدتك في العثور على منشئ موقع ثابت. مرفق بهذه القائمة ملخص عن مجموعات SSG الشائعة. إنه يفتقر فقط إلى تقييم لكيفية أداء مجموعات SSG المختلفة في العمل.
ما تشترك فيه جميع مجموعات SSG هو كيفية عملها. وهي تقبل بعض البيانات كمدخلات وتمرير هذه البيانات عبر محرك القالب. الإخراج هو ملفات HTML. يشار إلى هذه العملية عادة باسم بناء المشروع.
من أجل الحصول على بيانات أداء قابلة للمقارنة لمختلف مجموعات SSG ، هناك العديد من الفروق الدقيقة التي يجب مراعاتها. من الضروري الانتباه إلى ميزات المشاريع والعوامل التي تبطئ أو تسرع التجميع. هذا هو المكان الذي يبدأ فيه استكشافنا لأداء مجموعات SSG الشهيرة.
ومع ذلك ، فإن هدفنا ليس فقط العثور على أسرع SSG. اكتسبت شهرة هوغو بأنها "الأسرع" بالفعل . أعني ، موقع المشروع يقول أن Hugo هو أسرع إطار عمل لبناء مواقع الويب في العالم. وهذا يعني - على ما هو عليه.
تقارن هذه المقالة أداء مجموعات SSG الشائعة. أي أننا نتحدث عن وقت بناء المشاريع. لكن الشيء الأكثر أهمية هنا هو التحليل العميق لسبب ظهور بعض الأدوات لنتائج معينة. سيكون من الخطأ ، بغض النظر عن أي شيء آخر غير وقت بناء المشروع ، اختيار "أسرع SSG" أو التخلي فورًا عن "الأبطأ". دعنا نتحدث عن سبب ذلك.
الاختبارات
تم تصميم عملية اختبار SSG لتبدأ من خلال البحث في عدد قليل من المشاريع الشائعة واستكشاف معالجة تنسيقات البيانات البسيطة. هذا هو الأساس الذي يتم على أساسه بناء دراسة لمولدات المواقع الأكثر ثباتًا وتوسيع هذه الدراسة بتنسيقات بيانات أكثر تعقيدًا. تتضمن الدراسة الآن ستة مجموعات SSG شائعة:
عند دراسة كل منها ، يتم تطبيق النهج التالي والشروط التالية:
- مصدر البيانات لكل اختبار (عملية بناء المشروع) هو ملفات Markdown التي تحتوي على رأس تم إنشاؤه عشوائيًا (ما يسمى "الجزء الأمامي") وجسم المستند (ثلاث فقرات من النص).
- لا توجد صور في الوثائق.
- يتم إجراء الاختبارات عدة مرات على نفس الكمبيوتر. هذا يجعل القيم المحددة التي تم الحصول عليها من الاختبار أقل أهمية من مقارنة النتائج النسبية.
- الإخراج في نص عادي على صفحة HTML. تتم معالجة البيانات باستخدام الإعدادات القياسية الموضحة في أدلة البدء لكل من مجموعات SSG التي تم فحصها.
- « ». Markdown-.
تعتبر هذه الاختبارات اختبارات أداء (معايير). يستخدمون ملفات Markdown بسيطة ، مما ينتج عنه كود HTML غير منظم.
بعبارة أخرى ، الناتج هو ، من وجهة نظر فنية ، موقع ويب يمكن نشره في الإنتاج. لكن هذا ليس تنفيذًا لسيناريو SSG حقيقي. بدلاً من محاولة إعادة إنتاج موقف حقيقي ، نريد الحصول على خط أساس لمقارنة الأطر قيد الدراسة. عند استخدام الأدوات المذكورة أعلاه لإنشاء مواقع حقيقية ، ستعمل مجموعات SSG مع بيانات أكثر تعقيدًا وإعدادات مختلفة ، مما سيؤثر على وقت بناء المشاريع (هذا عادةً ما يؤدي إلى إبطاء الإنشاء ).
على سبيل المثال ، أحد الاختلافات بين حالات استخدام SSG في الاختبار وفي العالم الحقيقي هو حقيقة أننا ندرس عمليات البناء البارد. في الواقع ، الأمور مختلفة قليلاً. على سبيل المثال ، إذا تضمن المشروع 10000 ملف Markdown والتي هي مصدر البيانات لـ SSG ، وإذا تم استخدام Gatsby لبناء المشروع ، فسيتم استخدام ذاكرة التخزين المؤقت لـ Gatsby. وهذا يقلل بشكل كبير (بمقدار النصف تقريبًا) من وقت التجميع.
يمكن قول الشيء نفسه بالنسبة للبنيات الإضافية. يتعلق هذا بمقارنة الإنشاءات الساخنة والباردة بمعنى أن الملفات التي تم تغييرها فقط تتم معالجتها عند إجراء بناء إضافي. نحن لا نفحص التراكيب الإضافية في هذه الاختبارات. في المستقبل ، من الممكن أن يتم توسيع هذه الدراسة في هذا الاتجاه.
SSG من مستويات مختلفة
قبل أن نبدأ في الاستكشاف ، دعنا ننظر إلى حقيقة أن هناك بالفعل نوعين من النكهات SSG ، مستويين من مولدات الموقع الثابتة. دعنا نسميها "أساسية" و "متقدمة".
- المولدات الأساسية (على الرغم من أنها ليست بهذه البساطة) هي في الواقع أدوات سطر أوامر (واجهة سطر الأوامر ، CLI) تأخذ البيانات وإخراج HTML. غالبًا ما تكون قدراتهم قابلة للتوسع في اتجاه معالجة الموارد الإضافية (نحن لا نقوم بذلك هنا).
- تقدم المولدات المتقدمة بعض الميزات الإضافية بالإضافة إلى إنشاء مواقع ثابتة. هذه ، على سبيل المثال ، عرض من جانب الخادم للصفحات ، وظائف بدون خادم ، تكامل مع أطر ويب مختلفة. عادة ما يتم تكوينها ، فور التثبيت ، لمنح المستخدم قدرات ديناميكية أكثر من المولدات الأساسية.
بالنسبة لهذا الاختبار ، اخترت بشكل خاص ثلاثة مولدات لكل مستوى. تشمل العناصر الأساسية إيليفنتي وهوجو وجيكيل. تعتمد المولدات الثلاثة الأخرى على أطر أمامية. تتضمن مجموعات SSG هذه أدوات إضافية متنوعة. يعتمد Gatsby و Next على React ، بينما يعتمد Nuxt على Vue.
| المولدات الأساسية | مولدات متقدمة |
| أحد عشر | جاتسبي |
| هوغو | التالى |
| جيكل | Nuxt |
الفرضيات والافتراضات
أقترح تطبيق المنهج العلمي في بحثنا . العلم مثير للغاية (ويمكن أن يكون مفيدًا جدًا).
فرضيتي هي أنه إذا تم تطوير SSG ، فهذا يعني أنه سيعمل بشكل أبطأ من المولدات الأساسية. أنا متأكد من أن هذا سينعكس في نتائج الدراسة ، حيث يتم إشراك المزيد من الآليات في عمل مجموعات SSG المتقدمة أكثر من عمل الآليات الأساسية. نتيجة لذلك ، من المحتمل جدًا ، استنادًا إلى البحث ، أنه يمكن تقسيم المولدات الأساسية والمتقدمة بوضوح إلى مجموعتين. في الوقت نفسه ، ستعمل المولدات الأساسية بشكل أسرع من المولدات المتقدمة.
▍ SSG الأساسي: السرعة العالية والاعتماد الخطي لسرعة البناء على عدد الملفات
سيعالج Hugo و Eleventy مجموعات البيانات الصغيرة بسرعة كبيرة. إنها (نسبيًا) عمليات بسيطة تم إنشاؤها بواسطة Go و Node.js على التوالي. يجب أن تعكس نتائج اختبارهم هذا. في حين أن كلا من مجموعات SSG هذه سوف تتباطأ مع زيادة عدد الملفات ، أتوقع أن يظلوا قادة. في الوقت نفسه ، من الممكن أن يُظهر Eleventy ، مع زيادة الحمل ، ديناميكيات التغيير في وقت التجميع ، والذي ينحرف عن الخطي أكثر من Hugo. قد يكون هذا نتيجة بسيطة لحقيقة أن أداء Go أفضل بشكل عام من أداء Node.js.
▍ SSG المتقدم: بداية بطيئة للبناء وزيادة السرعة اللاحقة ، ولكن ليس خطيرًا جدًا
ستبدأ مجموعات SSG المتقدمة ، أو تلك المرتبطة بنوع من إطار عمل الويب ، ببطء ، وستكون ملحوظة. أظن أنه في اختبار ملف واحد ، سيكون الفرق بين الأطر الأساسية والمتقدمة كبيرًا جدًا. بالنسبة إلى الأجزاء الأساسية ، ستكون بضع ميلي ثانية ، وبالنسبة للأجزاء المتقدمة ، ستكون ثوانٍ بالنسبة إلى Gatsby و Next و Nuxt.
تستخدم مجموعات SSG المبنية على أطر عمل الويب حزمة الويب ، والتي تضيف حملًا إضافيًا للنظام أثناء تشغيله. في الوقت نفسه ، لا يعتمد هذا الحمل الإضافي على كمية البيانات المعالجة. لكننا نحن أنفسنا نوافق على ذلك ، باستخدام أدوات أكثر تقدمًا (سنتحدث أكثر عن هذا أدناه).
وعندما يتعلق الأمر بمعالجة آلاف الملفات ، أظن أن الفجوة بين مجموعات المولدات الأساسية والمتقدمة ستضيق. ومع ذلك ، في الوقت نفسه ، ستظل مجموعات SSG المتقدمة متخلفة بشكل خطير عن الأساسيات.
إذا تحدثنا عن مجموعة المولدات المتقدمة ، فأنا هنا أتوقع أن أسرعها هو Gatsby. أعتقد ذلك فقط لأنه لا يحتوي على مكون عرض من جانب الخادم يمكنه إبطاء الأمور. لكن هذا مجرد انعكاس لمشاعري الداخلية. ربما تم تحسين عرض الخادم في Next و Nuxt إلى مستوى بحيث إذا لم يتم استخدامه ، فلن يؤثر على وقت بناء المشاريع بأي شكل من الأشكال. أظن أن Nuxt سيكون أسرع من Next. أقوم بهذا الافتراض بناءً على حقيقة أن Vue "أخف" من React.
▍Jekyll هو ممثل غير عادي لـ SSG الأساسي
تشتهر منصة روبي بضعف أدائها. بمرور الوقت ، يتم تحسينها ، وتصبح أسرع ، لكنني لا أتوقع أن تكون سرعتها قابلة للمقارنة مع Node.js ، ناهيك عن Go. ولكن في الوقت نفسه ، لا تتحمل Jekyll العبء الإضافي المرتبط بإطار عمل الويب.
أعتقد أنه في بداية الاختبار ، عند معالجة عدد صغير من الملفات ، سيظهر Jekyll سرعة عالية. ربما يصل ارتفاعه إلى أحد عشر. ولكن مع وصولنا إلى فحص معالجة آلاف الملفات ، سيتأثر الأداء. يبدو لي أن هناك أسبابًا أخرى تجعل Jekyll هو الأبطأ من بين مجموعات SSG الستة التي تمت دراستها. لاختبار ذلك ، نفحص أداء مولداتنا على مجموعات من الملفات ذات الأحجام المختلفة - حتى 100000.
يوجد أدناه رسم بياني يوضح افتراضاتي.
الافتراضات المتعلقة بالاعتماد على سرعة عمل مجموعات SSG المختلفة
يمثل المحور Y وقت بناء المشاريع ، والمحور X هو عدد الملفات. يظهر التالي باللون الأخضر ، Nuxt باللون الأصفر ، Gatsby باللون الوردي ، Jekyll باللون الأزرق ، Eleventy باللون الفيروزي ، Hugo باللون البرتقالي. تعكس جميع الأسطر الزيادة في وقت إنشاء المشروع مع زيادة عدد الملفات. في الوقت نفسه ، يكون للخط المقابل لـ Jekyll أكبر زاوية ميل.
النتائج
هذا هو الكود الذي ينتج عنه النتائج التي سأناقشها الآن. لقد أنشأت أيضًا صفحة تجمع نتائج الاختبار النسبية.
بعد عدة محاولات للعثور على شروط لإجراء الاختبارات ، استقرت على 10 عمليات تشغيل لكل اختبار باستخدام ثلاث مجموعات بيانات مختلفة.
- مجموعة البيانات الأساسية (القاعدة). هذا ملف واحد. تسمح لك معالجتها بتقدير الوقت الذي يحتاجه SSG للاستعداد للعمل. هذا هو الوقت الذي سيستغرقه إطلاق SSG. يمكن أن يطلق عليه أساسي ، بغض النظر عن عدد الملفات التي تتم معالجتها.
- مجموعة من "المواقع الصغيرة" (المواقع الصغيرة). يقوم بفحص تجميع مجموعات من الملفات من 1 إلى 1024. يتم تنفيذ كل اختبار جديد بعدد مضاعف من الملفات (لتسهيل معرفة ما إذا كان وقت معالجة الملفات ينمو خطيًا مع نمو عددها).
- مجموعة من "المواقع الكبيرة" (المواقع الكبيرة). هنا يتغير عدد الملفات من 1000 إلى 64000 ، ويتضاعف مع كل تشغيل اختباري جديد. في البداية ، كنت أرغب في الوصول إلى 128000 ملف ، لكنني واجهت اختناقات في بعض أطر العمل. نتيجة لذلك ، اتضح أن 64000 ملف كافية لمعرفة كيف تتصرف مجموعات SSG المدروسة عند معالجة المواقع واسعة النطاق.
ها هي النتائج التي حصلت عليها.
مجموعة البيانات الأساسية
مجموعة بيانات المواقع الصغيرة
مجموعة بيانات المواقع الكبيرة
تلخيص النتائج
فاجأتني بعض النتائج ، لكن بعضها اتضح تمامًا كما توقعت. فيما يلي بعض النتائج العامة:
- كما هو متوقع ، كان أسرع SSG هو Hugo. إنه يعمل بشكل رائع مع مجموعات الملفات من جميع الأحجام. لكنني لم أتوقع أن تقوم المولدات الأخرى على الأقل بالاقتراب منها ، حتى في مجموعة البيانات الأساسية (لم أكن أتوقع أن تظهر سلوكًا خطيًا ، ولكن أكثر من ذلك أدناه).
- كل من SSGs ، الأساسي والمتقدم ، متميزان تمامًا في الرسوم البيانية التي تعرض معالجة الملفات من مجموعة المواقع الصغيرة. هذا كان متوقعا. ومع ذلك ، كان من غير المتوقع أن يكون Next أسرع من Jekyll في مجموعة من 32000 ملف ، وأنه يتجاوز كل من Jekyll و Eleventy في 64000 ملف. أيضًا ، من المدهش أن Jekyll أسرع بـ 64000 ملف من Eleventy.
- SSG . Next, , , . Hugo , — - .
- , Gatsby , , . , .
- , , , . , , Hugo 170 , Gatsby. 64000 Hugo 25 . , Hugo, SSG, . , - .
ماذا يعني كل هذا؟
عندما شاركت النتائج التي توصلت إليها مع منشئي مجموعات SSG هذه ، ومع أولئك الذين يدعمونها ، تلقيت منهم ، إن لم أخوض في التفاصيل ، نفس الرسائل. إذا تم تقليل هذه الرسائل إلى نوع من الرسائل "المتوسطة" ، فستحصل على التالي:
المولدات التي تقضي وقتًا أطول في بناء مشروع تعمل بهذه الطريقة لأنه يتعين عليها حل المزيد من المشكلات. إنها توفر للمطورين المزيد من الخيارات ، بينما الأدوات الأسرع (أي "الأساسية") تهتم بشكل أساسي بتحويل القوالب إلى ملفات HTML.
أنا أتفق مع ذلك.
باختصار ، تبين أن توسيع مواقع Jamstack أمر صعب للغاية.
تعتمد الصعوبات التي سيواجهها المطور ، الذي ينمو مشروعه ويتطور ، على خصائص كل مشروع محدد. لا توجد بيانات لدعم هذا. نعم ، لا يمكن أن يكونوا هنا ، لأن كل مشروع فريد بطريقة أو بأخرى.
لكن كل ذلك يعود إلى التفضيلات الشخصية للمطور ، إلى هذا الحل الوسط بين وقت بناء الموقع وراحة العمل مع SSG ، وهو ما هو مستعد للقيام به.
على سبيل المثال ، إذا كنت ستنشئ موقعًا كبيرًا مليئًا بالصور وتخطط لاستخدام Gatsby ، فأنت بحاجة إلى الاستعداد لحقيقة أن إنشاء هذا الموقع سيستغرق وقتًا طويلاً. ولكن في المقابل ، تحصل على نظام بيئي ضخم من المكونات الإضافية والأساس لبناء موقع ويب قوي ومنظم جيدًا وقائم على المكونات. إذا كنت تستخدم Jekyll في نفس المشروع ، فسيتعين عليك بذل المزيد من الجهد من أجل الحفاظ على المشروع في حالة جيدة التنظيم ، من أجل ضمان فعالية العمل في المشروع. وسيكون تجميع الموقع أسرع.
في العمل ، عادةً ما أقوم بإنشاء مواقع باستخدام Gatsby(أو استخدام التالي ، حسب المستوى المطلوب للتفاعل الديناميكي للمشروع). لقد عملنا مع Gatsby لإنشاء إطار عمل نبني عليه بسرعة مواقع ويب عالية التخصيص تحتوي على العديد من الصور بناءً على عدد كبير من المكونات. مع نمو حجم هذه المواقع ، استغرق الأمر وقتًا أطول لبناءها ، وبدأنا في الإبداع. يتعلق الأمر بتنفيذ واجهات صغيرة ومعالجة الصور خارج نظام البناء الرئيسي ومعاينات المحتوى والعديد من التحسينات الأخرى.
في المشاريع الخاصةعادةً ما أستخدم Eleventy. عادةً ما أكتب رمزًا لمثل هذه المشاريع فقط ، واحتياجاتي متواضعة إلى حد ما (أرى نفسي كعميلي الجيد) لدي تحكم أفضل في نتائج الإنشاء ، مما يساعدني على تحقيق إنتاجية عالية من جانب العميل. وهذا مهم بالنسبة لي.
نتيجة لذلك ، فإن اختيار SSG ليس مجرد اختيار بين "سريع" و "بطيء". إن اختيار الأداة هو الأنسب لمشروع معين ، والذي تبرر نتائجه الوقت الذي يمر في انتظار هذه النتائج.
النتيجة
في الحقيقة ، ما قلته هو مجرد بداية. الهدف من عملي هو إنشاء قاعدة يمكننا من خلالها قياس أوقات البناء النسبية للمشاريع التي تنتجها SSG الشعبية.
هل وجدت أي تناقضات في عملية الاختبار المقترحة لمولدات المواقع الثابتة؟ كيفية تحسين إجراء الاختبار؟ كيف تجعل الاختبارات أقرب إلى الواقع؟ هل أحتاج إلى نقل معالجة الصور إلى كمبيوتر منفصل؟ أدعو كل من يهتم بـ SSG للانضمام إلي ومساعدتي في العثور على إجابات لهذه الأسئلة والعديد من الأسئلة الأخرى.
ما مولدات الموقع الثابتة التي تستخدمها؟
