تفاعل استراتيجيات تحسين محركات البحث وأفضل الممارسات

تم تطوير React لإنشاء واجهات مستخدم تفاعلية تكون تعريفية ونمطية ومتعددة المنصات . اليوم ، يعد أحد أكثر إطارات عمل JavaScript شيوعًا - إن لم يكن الأكثر شيوعًا - لكتابة تطبيقات الواجهة الأمامية عالية الأداء. تم تطوير React مبدئيًا لكتابة تطبيقات الصفحة الواحدة (SPAs) ، ويستخدم الآن لإنشاء مواقع ويب وتطبيقات جوال كاملة.

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

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

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

كيف يزحف Google إلى صفحات الويب ويفهرسها

تتلقى Google أكثر من 90٪ من جميع عمليات البحث عبر الإنترنت. دعنا نلقي نظرة فاحصة على عملية الزحف والفهرسة.

يمكن أن تساعدنا هذه اللقطة المأخوذة من وثائق Google. يرجى ملاحظة أن هذا مخطط كتلة مبسط. إن Googlebot الفعلي أكثر تعقيدًا بكثير.

النقاط التي يجب ملاحظتها:

1. يحتفظ Googlebot بقائمة انتظار زحف تحتوي على جميع عناوين URL التي يحتاجها للزحف والفهرسة في المستقبل.
2. عندما يكون الزاحف في وضع الخمول ، فإنه يلتقط عنوان URL التالي في قائمة الانتظار ، ويقدم طلبًا ، ويجلب HTML.
3. بعد تحليل HTML ، يحدد Googlebot ما إذا كان يحتاج إلى جلب وتنفيذ جافا سكريبت لعرض المحتوى. إذا كانت الإجابة بنعم ، تتم إضافة عنوان URL إلى قائمة انتظار العرض.
4. في وقت لاحق ، يقوم العارض بجلب وتنفيذ جافا سكريبت لعرض الصفحة. يرسل HTML الذي تم تقديمه مرة أخرى إلى وحدة المعالجة.
5. تستخرج وحدة المعالجة جميع <a> tags المذكورة في صفحة الويب وتضيفها مرة أخرى إلى قائمة انتظار الزحف.
6. يضاف المحتوى إلى فهرس Google.

لاحظ أن هناك تمييزًا واضحًا بين مرحلة المعالجة التي تحلل HTML ومرحلة العارض التي تقوم بتنفيذ JavaScript.

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

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

ملاحظة: يمكنك قراءة إرشادات Google لإدارة ميزانية الزحف الخاصة بك هنا.

لماذا يعد تحسين رد الفعل من أجل تحسين محركات البحث أمرًا صعبًا

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

إفراغ محتوى المرور الأول

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

يعني هذا الأسلوب أن Googlebot يكتشف صفحة فارغة أثناء المرور الأول. يرى Google المحتوى فقط عند عرض الصفحة. سيؤدي هذا إلى تأخير فهرسة المحتوى عند التعامل مع آلاف الصفحات.

وقت التحميل وتجربة المستخدم

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

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

نقوم بمراجعة أداء الموقع بالتفصيل في القسم التالي.

البيانات الوصفية للصفحة

تعد علامات Meta <meta> مفيدة لأنها تسمح لـ Google ومواقع الوسائط الاجتماعية الأخرى بعرض العناوين والصور المصغرة والأوصاف المناسبة للصفحات. لكن مواقع الويب هذه تعتمد على علامة <head> لصفحة الويب التي تم جلبها للحصول على هذه المعلومات. لا تقوم مواقع الويب هذه بتنفيذ JavaScript للصفحة المستهدفة.

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

خريطة الموقع

ملف Sitemap هو ملف تقدم فيه معلومات حول الصفحات ومقاطع الفيديو والملفات الأخرى على موقعك والعلاقات بينها. تقرأ محركات البحث مثل Google هذا الملف للزحف إلى موقعك بشكل أكثر ذكاءً.

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

اعتبارات أخرى لتحسين محركات البحث

ترتبط هذه الاعتبارات بإعداد ممارسات تحسين محركات البحث الجيدة بشكل عام.

1. لديك بنية عنوان URL مثالية لمنح البشر ومحركات البحث فكرة جيدة حول ما يمكن توقعه على الصفحة.
2. يمكن أن يساعد تحسين ملف robots.txt روبوتات البحث على فهم كيفية الزحف إلى الصفحات الموجودة على موقع الويب الخاص بك.
3. استخدم CDN لخدمة جميع الأصول الثابتة مثل CSS و JS والخطوط وما إلى ذلك واستخدم الصور المتجاوبة لتقليل أوقات التحميل.

يمكننا معالجة العديد من المشكلات الموضحة أعلاه باستخدام العرض من جانب الخادم (SSR) أو العرض المسبق. سنراجع هذه الأساليب أدناه.

أدخل تفاعل متماثل

تعريف القاموس المتماثل هو "مطابق أو مشابه في الشكل."

في مصطلحات React ، هذا يعني أن الخادم له شكل مشابه للعميل. بمعنى آخر ، يمكنك إعادة استخدام نفس مكونات React على الخادم والعميل.

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

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

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

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

مقاييس أداء الموقع

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

بصرف النظر عن الإجابة على استعلام المستخدم بسرعة وبدقة ، تعتقد Google أن موقع الويب الجيد يجب أن يتمتع بالسمات التالية:

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

ترتبط هذه الميزات تقريبًا بالمقاييس التالية:

• TTFB : Time to First Byte - الوقت بين النقر فوق ارتباط وظهور الجزء الأول من المحتوى.
• LCP : أكبر رسم محتوى - الوقت الذي تصبح فيه المقالة المطلوبة مرئية. توصي Google بالحفاظ على هذه القيمة أقل من 2.5 ثانية.
• TTI : Time To Interactive - الوقت الذي تصبح فيه الصفحة تفاعلية (يمكن للمستخدم التمرير والنقر وما إلى ذلك).
• حجم الحزمة - إجمالي عدد وحدات البايت التي تم تنزيلها والتعليمات البرمجية المنفذة قبل أن تصبح الصفحة مرئية بالكامل وتفاعلية.

سنعيد النظر في هذه المقاييس لفهم أفضل لكيفية تأثير مسارات العرض المختلفة على كل منها.

بعد ذلك ، دعنا نفهم مسارات العرض المختلفة المتاحة لمطوري React.

تقديم المسارات

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

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

العرض من جانب العميل (CSR)

التقديم من جانب العميل هو مسار التجسيد الافتراضي لـ React SPA. سيعرض الخادم تطبيق shell لا يحتوي على أي محتوى. بمجرد تنزيل المستعرض لمصادر جافا سكريبت وتحليلها وتنفيذها ، يتم ملء محتوى HTML أو عرضه .

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

تقسيم الكود بسيط نسبيًا. يمكنك تقسيم التعليمات البرمجية الخاصة بك باستخدام عمليات الاستيراد الديناميكية أو React.lazy بحيث يتم تحميل التبعيات المطلوبة فقط بناءً على المسار أو إجراءات المستخدم.

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

من المرجح أن يرى المستخدم علامة أو مؤشر "تحميل البيانات" أثناء قيام موقع الويب بجلب بيانات إضافية.

العرض من جانب العميل باستخدام بيانات التمهيد (CSRB)

ضع في اعتبارك نفس السيناريو مثل CSR ولكن بدلاً من جلب البيانات بعد تقديم DOM ، دعنا نقول أن الخادم أرسل البيانات ذات الصلة التي تم تمهيدها داخل HTML.

يمكننا تضمين عقدة تبدو كالتالي:

 <script type="application/json"> {"title": "My blog title", "comments":["comment 1","comment 2"]} </script>

وحللها عندما يتصاعد المكون:

 var data = JSON.parse(document.getElementById('data').innerHTML);

لقد وفرنا على أنفسنا للتو رحلة ذهابًا وإيابًا إلى الخادم. سنرى المفاضلات بعد قليل.

التقديم من جانب الخادم للمحتوى الثابت (SSRS)

تخيل سيناريو نحتاج فيه إلى إنشاء HTML سريعًا.

على سبيل المثال ، إذا كنا نبني آلة حاسبة عبر الإنترنت وأصدر المستخدم استعلامًا عن الفرز / الحساب / 34 + 15 (مع استبعاد الهروب من عنوان URL). نحتاج إلى معالجة الاستعلام وتقييم النتيجة والرد باستخدام HTML المُنشأ.

HTML الذي تم إنشاؤه لدينا بسيط للغاية من حيث الهيكل ولسنا بحاجة إلى React لإدارة ومعالجة DOM بمجرد تقديم HTML الذي تم إنشاؤه.

لذلك نحن نقدم فقط محتوى HTML و CSS. يمكنك استخدام التابع renderToStaticMarkup لتحقيق ذلك.

سيتم التعامل مع التوجيه بالكامل بواسطة الخادم لأنه يحتاج إلى إعادة حساب HTML لكل نتيجة ، على الرغم من إمكانية استخدام التخزين المؤقت لـ CDN لخدمة الاستجابات بشكل أسرع. يمكن أيضًا تخزين ملفات CSS مؤقتًا بواسطة المتصفح لتحميل الصفحات اللاحقة بشكل أسرع.

التقديم من جانب الخادم مع معالجة الجفاف (SSRH)

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

سنقوم بإجراء أول عرض على الخادم وإرسال محتوى HTML مع ملفات JavaScript. ستعيد React ترطيب الترميز الذي يعرضه الخادم وسيعمل التطبيق مثل تطبيق CSR من هذه النقطة فصاعدًا.

يوفر React طرقًا مضمنة لتنفيذ هذه الإجراءات.

تتم معالجة الطلب الأول بواسطة الخادم ويتم التعامل مع عمليات العرض اللاحقة بواسطة العميل. لذلك ، تسمى هذه التطبيقات تطبيقات React العالمية (يتم تقديمها على كل من الخادم والعميل). قد يتم تقسيم (أو تكرار) الكود الخاص بمعالجة التوجيه على العميل والخادم.

يعد تقسيم الكود أمرًا صعبًا بعض الشيء لأن ReactDOMServer لا يدعم React. كسول ، لذلك قد تضطر إلى استخدام شيء مثل Loadable Components.

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

هذا هو المكان الذي تظهر فيه أطر مثل NextJS. إنها تخفي التعقيدات المرتبطة بالتوجيه وتقسيم الكود في SSRH وتوفر تجربة مطور أكثر سلاسة.

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

التقديم المسبق للمحتوى الثابت (PRS)

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

يمكننا بعد ذلك تخزين محتوى HTML الناتج على CDN وتقديمه بشكل أسرع عندما يطلبه المستخدم.

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

التقديم المسبق مع معالجة الجفاف (PRH)

قد نرغب في أن يكون HTML الذي تم تقديمه مسبقًا تطبيق React يعمل بكامل طاقته عندما يعرضه العميل.

بعد تقديم الطلب الأول ، سيتصرف التطبيق مثل تطبيق React القياسي. هذا الوضع مشابه لـ SSRH ، الموصوف أعلاه ، من حيث وظائف التوجيه وتقسيم الكود.

مصفوفة الأداء

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

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

تتراوح النتيجة من 1 إلى 5:

• 1 = غير مرض
• 2 = ضعيف
• 3 = معتدل
• 4 = جيد
• 5 = ممتاز

الماخذ الرئيسية

يؤدي التقديم المسبق للمحتوى الثابت (PRS) إلى مواقع الويب الأعلى أداءً بينما قد يؤدي التقديم من جانب الخادم مع الترطيب (SSRH) أو التقديم من جانب العميل (CSR) إلى نتائج محبطة.

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

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

مزيد من القراءة والاعتبارات

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

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