بناء موقع ويب فائق السرعة وآمن باستخدام CMS ليس بالأمر الهين. أو هو؟

هل يمكنني كسر موقعك؟ هل لديك أي نصوص متبقية هناك يمكنني الاستفادة منها؟ هل هناك طريقة لسرقة بيانات الاعتماد الخاصة بك وتغيير المحتوى على موقعك؟ هل يمكنني الوصول إلى المعلومات الخاصة؟ لا؟ هل أنت واثق؟ أم أنني لن أكتشف أبدًا لأن صفحتك تستغرق وقتًا طويلاً للتحميل؟

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

التقليدية CMS

إذا كنت تستخدم نظامًا تقليديًا لإدارة المحتوى (CMS) ، فإن الموقف يكون أكثر تعقيدًا بالنسبة لك. تحتوي هذه الأنظمة على الكثير من الميزات. يجب عليهم تغطية جميع حالات الاستخدام المحتملة لأي موقع ويب. هذا يعني الرمز. الكثير من التعليمات البرمجية. آلاف الملفات. وهذا ليس كل شيء - تحتاج واجهات الإدارة إلى توفير واجهة مستخدم لطيفة لتهيئة كل هذه الميزات. يحتمل ، بضعة آلاف أخرى من الملفات.

الأمان

إنه ليس رمزك ، أليس كذلك؟ لذلك يجب أن تكون آمنة بالفعل. حسنًا ، يبذل العديد من بائعي CMS قصارى جهدهم لضمان أمان عمليات التنفيذ الخاصة بهم. لا يزال يتعين عليهم تغطية الكثير من الملفات. وقد يحتوي كل ملف على خطأ ، أو بعض التعليمات البرمجية التي تم تركها ، أو ربما معلمة سلسلة استعلام تعرض قاعدة بيانات. هذا في حد ذاته يمكن أن يخلق ثغرة أمنية محتملة.

يمكن أن يكون استخدام نظام إدارة المحتوى مفتوح المصدر أكثر خطورة ، حيث أن التنفيذ معروف للجميع. نعم ، يمكنك القول أن المصدر المفتوح مفيد. يمكن لأي شخص المساهمة وإصلاح المشكلات الموجودة. لكن هذا لا يغطي سوى المشكلات المعروفة بالفعل. ربما يحتفظ المهاجمون بمآثرهم لأنفسهم. حتى إذا تم العثور على مشكلة وتم إصلاحها ، فلا يزال يتعين عليك بذل الكثير من الجهد للتأكد من تحديث موقع الويب الخاص بك. يجب عليك إجراء ترقيات في كل مرة يتم فيها إصدار إصلاح عاجل للأمان.

إذا كنت مهتمًا بإحصائيات العالم الحقيقي ، فقم بإلقاء نظرة على تقرير موقع الويب الذي تم اختراقه بواسطة Sucuri.

لذا ، ماذا يريد المهاجمون أن يفعلوا بموقعك على الويب؟ في الأساس ، يريدون الحصول على بياناتك ، حتى يتمكنوا من إساءة استخدام موقع الويب الخاص بك عن طريق:

  • الوصول إلى قاعدة البيانات الخاصة بك من خلال أحد البرامج النصية. عادة ما يكون هذا هو حالة البرامج النصية المخصصة المتبقية ، وصفحات الاختبار ، وغيرها.
  • المساومة وإساءة استخدام بياناتك السرية. ملفات التكوين هي خيار تخزين نموذجي للعديد من المفاتيح السرية وبيانات الاعتماد للخدمات أو قواعد البيانات الأخرى.
  • تعديل محتوى موقع الويب الخاص بك.
  • جعل موقع الويب الخاص بك غير ممكن الوصول إليه ، أي إغلاقه.

أداء

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

على أي حال ، يبدو أن موقع الويب الخاص بك يعمل بشكل جيد ، فلماذا يكون هذا مصدر قلق؟ كذلك لأنه:

  • تدفعه مقابل قوة حوسبة الخادم
  • تقوم بتجميع ونسخ رمز الوظائف التي لا تنوي استخدامها مطلقًا
  • زوار موقعك ينتظرون الرد

يمكن أن يكون الوقت حتى البايت الأول لهذه المواقع أكثر من ثانية واحدة. بالتأكيد ، يمكن تحسينه ، ولكن بعد ذلك تنفق الوقت والمال في معرفة كيفية التخفيف من مشكلات الأداء ، وعادة ما ينتهي بك الأمر إلى تعزيز وحدة المعالجة المركزية والذاكرة ، أو ما هو أسوأ من ذلك ، إضافة خادم إضافي.

تحقق من موقعك باستخدام Google PageSpeed ​​أو احصل على تحليل أكثر تفصيلاً باستخدام SpeedCurve لترى كيف يعمل موقع الويب الخاص بك.

المواقع المستندة إلى API

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

عدد الملفات المستخدمة لمثل هذه المواقع يتوافق مع وظائفها. لكن ماذا عن واجهة الإدارة لتحرير المحتوى؟ لا تقلق. يتعامل نظام CMS بدون رأس مع هذا الجزء نيابة عنك ، دون الحاجة إلى رمز إضافي لاستضافته أو صيانته.

الأمان

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

الفائدة الرئيسية من هذا الأسلوب هي أنك لست بحاجة إلى قاعدة بيانات. هذا صحيح ، لا توجد نقطة واحدة لتخزين البيانات يمكن للمهاجم الوصول إليها.

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

إذا كنت تضع في اعتبارك أن تطبيق JS مفتوح للجميع ، وتتعامل مع البيانات الحساسة بالطريقة الصحيحة ، فسيكون لديك عمل أقل بكثير من أجل جعل موقع الويب الخاص بك آمنًا. يؤدي عدم وجود قاعدة بيانات واستهلاك جميع خدمات API من خلال القنوات الآمنة إلى إغلاق جميع الأبواب تقريبًا أمام أي مهاجم محتمل.

أداء

في هذا السيناريو ، يوفر خادم الويب الأصول فقط. يتم تخزين منطق الأعمال الخاص بتطبيقك في ملف JS. يتم تجميع المحتوى من نقاط النهاية المختلفة عبر الطلبات غير المتزامنة بواسطة متصفحات الزوار.

طلبات غير متزامنة للحصول على محتوى من خدمات الجهات الخارجية؟ يجب أن يكون ذلك بطيئًا ، أليس كذلك؟ بالتأكيد ، سوف يستغرقون بعض الوقت. ولكن ، عادةً ما يتم إنشاء نقاط نهاية التسليم الخاصة بهم للسرعة واستضافتها في السحابة ومرنة للغاية. يمكنك أيضًا اختيار نظام CMS مقطوع الرأس يستخدم CDN للتسليم ، أحدها هو Kentico Cloud. وبهذه الطريقة ، سيتم دائمًا التعامل مع الطلب من خلال مركز البيانات الأقرب جغرافيًا لكل زائر.

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

ألق نظرة على المدة التي استغرقها خادم الويب لمعالجة الطلبات الواردة (خلفية صفراء فاتحة). طوال هذا الوقت ، ينتظر الزائر بنشاط ، ولا يمكنه البدء في تنزيل الصور والأصول الأخرى. لن يكونوا معروفين لمتصفح الزائر إلا بعد تلقي الرد.

يعد موقع الويب المستند إلى واجهة برمجة التطبيقات أسرع بكثير ، حيث تكون الاستجابة الأولية لملف HTML الثابت فورية. يقوم المتصفح بتنزيل منطق الأعمال الخاص بالموقع كأحد الأصول ، ويقوم بإنشاء جميع الطلبات اللاحقة غير المتزامنة للمحتوى. يرى الزائر الصفحة التي تم عرضها بالكامل بشكل أسرع ، كما يرى أيضًا أن شيئًا ما يحدث. عندما ينتظرون صفحة يعرضها الخادم ، كل ما يرونه هو أداة تحميل مسبق في شريط العنوان في متصفحهم. تحسين الأداء العام لموقع الويب المستند إلى API في هذه الحالة يزيد عن 50٪. يمكن أن يكون أعلى بكثير اعتمادًا على تنفيذ موقع الويب.

المواقع الثابتة

فلماذا نهتم بحل الأداء ، إذا كان لدينا بالفعل موقع ويب قائم على واجهة برمجة التطبيقات؟

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

ماذا يمكننا أن نفعل حيال هذا؟ لا ، لن نضيف أي أدوات تحميل مسبقة. كيف تشعر عندما ترى أداة التحميل المسبق اللانهائية التي تدور وتدور وتدور فقط؟ يمكننا أن نجعل مواقعنا الإلكترونية ثابتة ، مع الحفاظ عليها ديناميكية.

يتعلق مفهوم المواقع الثابتة بمخرجات موقع الويب الخاص بك. يبدأ بالمحتوى. لا يقوم المحررون عادةً بتحديث المحتوى كثيرًا. يجب أن يتم تكوين موقع الويب بناءً على كل طلب (مثل أنظمة إدارة المحتوى التقليدية). الفكرة مشابهة للتخزين المؤقت - تخزين البيانات أو الصفحات التي تم إنشاؤها في الذاكرة. لكن المواقع الثابتة تذهب أبعد قليلاً. يتم إنشاء موقع الويب بالكامل ، وجميع الصفحات التي تحتوي على جميع المحتويات ، في كل مرة ينشر فيها محرر المحتوى. لذلك إذا كان لديك 153 منشورًا في مدونتك ، فسيحتوي موقع الويب الآن على 153 صفحة ثابتة (بالإضافة إلى بعض الصفحات الأخرى مثل الصفحة الرئيسية ، جهة الاتصال ، والمزيد).

كيف ستدير 153 صفحة؟ حسنًا ، أنت لا تفعل ذلك. ما زلت تدير فقط تنفيذ صفحة ديناميكية واحدة. يتم إنشاء الموقع الثابت من خلال الجمع بين التنفيذ والمحتوى من نظام CMS مقطوع الرأس. لذلك عندما يكون هناك محتوى جديد ، يتم إنشاء الموقع تلقائيًا مرة أخرى.

ترى فائدة السرعة ليست كبيرة مقارنة بالمواقع الديناميكية القائمة على واجهة برمجة التطبيقات. ومع ذلك:

  • يحصل زوار موقعك على الصفحة وكل المحتوى في الاستجابة الأولى. لن ينظروا إلى صفحة يتم بناؤها. لا تحتاج المستعرضات الخاصة بهم إلى إنشاء طلبات غير متزامنة إضافية للمحتوى
  • تتصرف جميع الطلبات اللاحقة بنفس الطريقة
  • يتنقل الزوار بين مجموعة من الصفحات الثابتة وهو سريع جدًا
  • تتيح بعض أدوات إنشاء المواقع الثابتة ميزات رائعة إضافية للزوار مثل التحميل المسبق للصفحات المرتبطة (مما يجعل التنقل إليها فوريًا) أو عرض الصور بجودة منخفضة قبل تنزيلها بالكامل

كل ذلك يترك للزائرين انطباعًا عن موقع ويب سريع النيران.

بالطبع ، كل موقع مختلف. قد تحتاج إلى بعض ميزات التخصيص ، أو ترغب في عرض محتوى حساس. في هذه الحالات يمكنك الجمع بين كلا النهجين. لديك موقع ويب ثابت ، وما زلت تستخدم الخدمات المستندة إلى واجهة برمجة التطبيقات لتقديم محتوى يختلف باختلاف الزوار.

استنتاج

تعد جوانب الأداء والأمان لكل موقع مهمة للغاية. عادةً ما تكون أنظمة إدارة المحتوى التقليدية تتطلب موارد أكثر من مواقع الويب القائمة على واجهة برمجة التطبيقات ، ولكنها توفر المزيد من الوظائف خارج الصندوق.

من ناحية أخرى ، فإن المواقع القائمة على API أسرع وأكثر أمانًا. إنها تمكّنك من توفير المال على الاستضافة ، وتوفر تجربة أفضل للزائرين.

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

هل موقع الويب الخاص بك ثابت بالفعل؟ هل استخدمت أي مولدات مواقع ثابتة؟ اسمحوا لي أن أعرف عن تجربتك في قسم التعليقات أدناه.

سأوضح لك في مقالتي التالية كيفية إنشاء موقع ويب على Vue.js باستخدام منشئ الموقع الثابت.

مقالات أخرى في السلسلة:

  1. كيف تبدأ في إنشاء موقع ويب رائع لأول مرة
  2. كيف تقرر أفضل تقنية لموقعك على الويب؟
  3. كيفية تعزيز موقع الويب الخاص بك باستخدام Vue.js بأقل جهد
  4. كيفية مزج CMS مقطوعة الرأس مع موقع Vue.js ودفع الصفر
  5. كيفية جعل عمليات إرسال النماذج آمنة على موقع ويب API
  6. بناء موقع ويب فائق السرعة وآمن باستخدام CMS ليس بالأمر الهين. أو هو؟
  7. كيفية إنشاء موقع ويب ثابت باستخدام Vue.js في لمح البصر
  8. كيفية إعداد عملية إنشاء لموقع ثابت بسرعة