كل الأنشطة

تعد ريآكت React أحد أشهر مكتبات لغة جافا سكريبت المستخدمة في تطوير الواجهات الأمامية front-end development، إلا أن تطوير التطبيقات بهذه المكتبة يمكن أن يتسبب لك ببعض المشكلات مع محركات البحث. نستعرض في هذه المقالة أهم التحديات التي تواجه المطورين في تحسين محركات البحث SEO للتطبيقات المصممة باستخدام مكتبة ريآكت React، ونوضح أهم الخطوات التي يمكنك اتباعها لتجاوز هذه المشكلات بفعالية، وتحسين سيو التطبيقات، ورفع رتبتها في صفحة نتائج محرك البحث. لمحة عن ريآكت React وآلية عملها ريآكت React هي مكتبة جافا سكريبت مخصصة لإنشاء واجهات مستخدم تفاعلية متعددة المنصات وهي تعتمد على تقسيم التطبيق لعدة مكونات أو أجزاء صغيرة قابلة لإعادة الاستخدام لتساعد في إنشاء تطبيقات واجهات أمامية فعالة وعالية الأداء. طُورت مكتبة ريآكت في الأساس من أجل إنشاء تطبيقات الصفحة الواحدة Single Page Applications أو اختصارًا SPAs -وهي تطبيقات مبنية بالاعتماد على صفحة واحدة ويمكنك أن تنتقل بين صفحاتها دون الحاجة إلى تحميل الصفحات الجديدة بالكامل- ولكنها اليوم تصلح لإنشاء مختلف أنواع مواقع الويب وتطبيقات الجوال. إلا أن المواقع والتطبيقات المصممة بهذه المكتبة قد تواجه مجموعة من التحديات والمشكلات المتعلقة بترتيبها في محركات البحث، وهذا ما ستلاحظه بنفسك إذا كنت قد طورت في البداية تطبيقات ويب بالطريقة التقليدية وكتبت بنفسك كافة التعليمات الأساسية اللازمة لواجهات هذه التطبيقات دون الاستعانة بمكتبات أوأطر عمل جاهزة، ثم انتقلت بعد ذلك لاستخدام مكتبة ريآكت إذ ستلاحظ أن جزءَا كبيرًا من شيفرات HTML و CSS الخاصة بتطبيقك قد أصبحت جزءًا من شيفرات جافا سكريبت JavaScript. السبب في ذلك هو أن مكتبة ريآكت React لا توصي بإنشاء عناصر واجهة المستخدم أو تحديثها بشكل مباشر، بل تعتمد طريقة أخرى بدلاً وهي وصف (حالة state) عناصر واجهة المستخدم أي تصف كيف يجب أن تظهر واجهة المستخدم في أي وقت، ثم تُحدِّث بعد ذلك نموذج تمثيل المستند ككائن DOM ليتوافق مع هذه الحالة بطريقة فعالة، كما توفر ريآكت مكونات قابلة لإعادة الاستخدام يمكننا استخدامها لوصف حالة واجهة المستخدم. ونتيجة لذلك، سيتوجب عليك إجراء جميع التغييرات على واجهة المستخدم أو على مستند DOM من خلال محرك ريآكت، وبالرغم من أن هذا الأمر مريح للمطورين، إلا أنه من ناحية أخرى يجعل وقت تحميل الصفحات أطول بالنسبة للمستخدمين، كما أنه يتطلب المزيد من العمل في محركات البحث للعثور على المحتوى وفهرسته، الأمر الذي ينجم عنه مشكلات محتملة في ترتيب الصفحات المبنية باستخدام React في نتائج محركات البحث. سنشرح في الفقرات التالية من المقالة المزيد حول المشكلات التي قد تواجهها في سيو التطبيقات والمواقع التي أنشأتها باستخدام رياكت، ونوفر لك عدة حلول واستراتيجيات للتعامل معها والتخلص منها. طريقة زحف محرك البحث جوجل إلى صفحات الويب وفهرستها قبل الغوص في حلول تحسين سيو تطبيقات رياكت من الضروري أن تفهم كيف يزحف محرك البحث جوجل Google إلى تطبيقاتك ومواقعك ويفهرسها، فمحرك البحث جوجل هو أشهر محرك بحث ويتلقى ما يزيد على 90% من مجمل عمليات البحث عبر الإنترنت ويمكنك من خلال فهم طريقة عمله معرفة العوامل التي تؤثر على فهرسة موقعك. للنظر للصورة التالية المقتبسة من وثائق Google وتجدر الملاحظة بأن هذا المخطط ليس سوى رسم توضيحي مبسط لعملية فهرسة موقع الويب، فالفهرسة الفعلية التي يقوم بها زاحف جوجل Googlebot أعقد بكثير. خطوات فهرسة جوجل يتبع زاحف جوجل Googlebot عملية من عدة خطوات لفهرسة مواقع الويب وهي كالتالي: ينشئ زاحف جوجل رتل انتظار للزحف crawl queue يتضمن كافة عناوين URL التي اكتشفها والتي يحتاج للزحف إليها وفهرستها لاحقًا. عندما يكون الزاحف جاهزًا، فإنه يأخذ عنوان URL التالي في رتل الانتظار، ويرسل طلبًا لجلب محتوى HTML للصفحة. بعدها يقوم الزاحف Googlebot بتحليل محتوى HTML وتحديد فيما إذا كان يحتاج كذلك إلى جلب سكربتات جافا سكريبت وتنفيذها لعرض المحتوى. إذا كانت الإجابة نعم سيضاف عنوان URL إلى رتل انتظار التصيير render queue. لاحقًا، يقوم المصيّر renderer الخاص بالزاحف بجلب شيفرات جافا سكريبت وتنفيذها من أجل تصيير أو عرض render الصفحة ويرسل كود HTML الناتج مرة أخرى إلى وحدة لمعالجة الكود processing unit. تستخرج وحدة المعالجة جميع وسوم الروابط <a> لعناوين URL المكتشفة في صفحة الويب وتضيفها من جديد إلى رتل انتظار الزحف crawl queue. أخيرًا يضاف المحتوى إلى فهرس جوجل. لاحظ أن هناك اختلافات واضحة بين مرحلة المعالجة التي تحلل كود HTML ومرحلة التصيير التي تنفذ أكواد جافا سكريبت لاحقًا، والسبب في ذلك هو أن تنفيذ أكواد جافا سكريبت مكلف ويستغرق وقتًا طويلاً جدًا، ويحتاج زاحف جوجل للاطلاع على ما يزيد على 130 تريليون صفحة على الويب، لذا عندما يزحف على صفحة ويب فإنه يحلل HTML فورًا ثم يضع أكواد جافا سكريبت في رتل انتظار لتشغيلها لاحقًا، وبحسب وثائق جوجل قد تبقى أكواد جافا سكريبت في رتل انتظار التصيير render queue لمدة بضع ثوانٍ أو أكثر. ومن الجدير بالذكر أيضًا الإشارة إلى ميزانية الزحف، فعملية زحف وفهرسة جوجل مقيدة بالموارد المتاحة مثل سعة النطاق الترددي والوقت وعدد روبوتات جوجل المتاحة. وتخصص جوجل ميزانية أو موارد محددة لفهرسة كل موقع إلكتروني على شبكة الإنترنت. فإذا كنت تنشئ موقع ويب ضخم يضم آلاف الصفحات والكثير من المحتوى كموقع تجارة إلكترونية على سبيل المثال، وتستخدم في صفحات موقعك قدرًا كبيرًا من أكواد جافا سكريبت لعرض المحتوى، فقد لا يتمكن جوجل من الزحف لكافة صفحات موقعك وقراءة كافة محتوياته لأنه مكلف في الزحف. ملاحظة: ينصح بقراءة الإرشادات التي يعتمدها جوجل من أجل إدارة وتحسين ميزانية الزحف الخاصة بك من هنا. لماذا يمثل السيو تحديًا في ريآكت React ؟ بعد أن كونت فكرة عامة عن طريقة عمل زاحف جوجل Googlebot وفهرسته للموقع ستتمكن كمهندس برمجيات من تحديد المشكلات المحتملة التي تواجهها محركات البحث التي تحاول الزحف إلى صفحات مواقع أو تطبيقات ريآكت وفهرستها بشكل أفضل. وفيما يلي نبين أبرز أسباب حدوث مشكلات في تحسين محركات البحث لمواقع وتطبيقات React ونوضح سبل حلها والتغلب عليها. السبب الأول: محتوى الصفحة فارغ عند المرور عليها لأول مرة تعتمد تطبيقات ريآكت بشكل أساسي على أكواد جافا سكريبت لعرض المحتوى الديناميكي للصفحات، لذا تواجه مشكلات مع محركات البحث في معظم الحالات، حيث تعتمد ريآكت بشكل افتراضي على بنية أو نموذج (هيكل التطبيق App Shell) وهو نموذج لتصميم لتطبيقات الويب يعتمد على إنشاء ملف HTML أساسي عند تحميل الصفحة، ولكن لا يحتوي هذا الملف على أي محتوى ذي معنى، ويجب على المستخدم أو روبوت الزحف تنفيذ أكواد جافا سكريبت لإنشاء ورؤية المحتوى الفعلي للصفحة. وهذا بدوره يعني أن زاحف جوجل Googlebot سيعثر على صفحة فارغة عند مروره الأول على الصفحة ولن يرى المحتوى الفعلي إلا في مرحلة تصيير أو عرض الصفحة، ونظرًا لكون الزاحف يتعامل مع آلاف الصفحات، سيتسبب هذا الأمر في تأخير فهرسة المحتوى. السبب الثاني: زيادة وقت التحميل التي تؤثر على تجربة المستخدم UX قد يستغرق جلب أكواد جافا سكريبت وتحليلها وتنفيذها وقتًا طويلًا، أضف إلى ذلك فقد تحتاج أكواد جافا سكريبت إلى الاتصال مع شبكة لطلب المحتوى من مصادر مختلفة (مثل قواعد البيانات أو الواجهات البرمجية APIs) وفي هذه الحالة سيضطر المستخدم إلى الانتظار لفترة من الزمن قبل أن يتمكن من الحصول على نتيجة الطلب وعرض المعلومات المطلوبة. وبما أن جوجل تعتبر أن مواقع الويب التي تستغرق وقتًا طويلاً للتحميل تؤثر سلبًا على تجربة المستخدم وتعتمد هذا الأمر كمعيار لتحديد ترتيب المواقع في محركات البحث فالمواقع الأبطأ في التحميل ستحصل على ترتيب أقل في صفحة نتائج البحث. السبب الثالث: صعوبة تخصيص البيانات الوصفية metadata لكل صفحة من صفحات الموقع تفيد الوسوم الوصفية أو ما يعرف بوسوم ميتا في وصف صفحات الموقع لمحركات البحث، وتسمح لمحرك بحث جوجل ولمواقع التواصل الاجتماعي بإظهار عناوين وأوصاف هذه الصفحات وصورها المصغرة، لكن المواقع المطورة باستخدام ريآكت تستخدم الوسم في صفحات الويب المستردة للحصول على هذه المعلومات، وهي لا تنفذ شيفرات جافا سكريبت للصفحة الهدف. كما تعتمد رياكت على منهجية تصيير كل المحتوى بما في ذلك وسوم ميتا من جانب العميل، وبالتالي سيكون هيكل التطبيق App shell هو نفسه لكامل الموقع أو التطبيق، بمعنى آخر ستكون البيانات الوصفية metadata موحدة لكافة صفحات موقع الويب أو التطبيق وسيكون من الصعب تخصيص هذه البيانات لكل صفحة على حدة، وبهذا سترى محركات البحث نفس البيانات الوصفية لجميع الصفحات، حتى لو كانت هذه الصفحات مختلفة تمامًا عن بعضها البعض وهذا قد يؤثر على فهرستها بصورة صحيحة. السبب الرابع: عدم وجود طريقة مدمجة لإنشاء خريطة الموقع Sitemap خريطة الموقع Sitemap هي ملف يوفر معلومات حول محتوى صفحات الموقع ومقاطع الفيديو التي تتضمنها والملفات الأخرى الموجودة على الموقع، ويوضح العلاقات أو الروابط فيما بينها، وتقرأ محركات البحث -ومن بينها محرك جوجل- هذا الملف لتتمكن من الزحف إلى موقعك بطريقة أفضل. ولا توفر مكتبة ريآكت طريقة مدمجة لإنشاء خريطة الموقع، لكن في حال كنت تستخدم مكتبة React Router للتعامل مع توجيه الصفحات Routing فيمكنك في هذه الحالة العثور على أدوات مساعدة لإنشاء خريطة الموقع، لكن هذا قد يحتاج منك لبعض الجهد. نصائح عامة لتحسين محركات البحث غير مرتبطة بمكتبة ريآكت إليك أهم النصائح والممارسات التي يمكنك الأخذ بها لتحسين محركات البحث للمواقع والتطبيقات بشكل عام وليست خاصة بتطبيقات ريآكت فقط. احصل على عنوان URL سهل لموقعك أو تطبيقك ويمكن فهمه من قبل البشر ومحركات البحث ويعطي فكرة واضحة عن المحتوى الذي يتضمنه. حَسّن ملف robots.txt لمساعدة روبوتات البحث على فهم كيفية الزحف إلى صفحات موقعك. استخدم شبكة توصيل محتوى CDN لتخزين جميع الأصول الثابتة مثل CSS و JS والخطوط، واستخدم صورًا متجاوبة لتقليل أوقات تحميل الصفحات. كما يمكن معالجة العديد مشكلات السيو باستخدام التصيير من جانب الخادم SSR أو التصيير المسبق pre-rendering وسنستعرض هذه الأساليب بمزيد من التفصيل في فقرات لاحقة. ما هي تطبيقات ريآكت المتماثلة Isomorphic يشير مصطلح إسومورفيك Isomorphic بشكل عام إلى التوافق أو التشابه في الشكل، أما في مكتبة ريآكت React فهو يعني هذا أن الخادم والعميل لهما له نفس نموذج أو قاعدة الشيفرة تقريبًا، بمعنى آخر يمكن إعادة استخدام نفس مكونات ريآكت React على كل من الخادم والعميل. وبالتالي يعرف تطبيق رياكت المتماثل Isomorphic بأنه تطبيق يمكن تشغيله على كل من جانب العميل وجانب الخادم باستخدام نفس الشيفرة، إذ يمكن استخدام نفس المكونات على كل منهما ونفس المنطق في التصيير على الخادم والتصيير على العميل وهذا يقلل هذا من تكرار الشيفرة ويضمن تناسق التطبيق. يسمح هذا النهج المتماثل للخادم يتصيير render تطبيق رياكت وإرسال النتيجة إلى المستخدمين ومحركات البحث ليتمكنوا من عرض المحتوى على الفور، بينما تُحمّل أكواد وتنفذ جافا سكريبت في الخلفية وقد اعتمدت عدة أطر على هذا الأسلوب وزادت من شهرته مثل إطار Next.js ومولد المواقع Gatsby . تجدر الملاحظة بأن المكونات المتماثلة قد تبدو مختلفة عن مكونات React التقليدية بشكل واضح. على سبيل المثال، يمكن أن تحتوي على كود يعمل على الخادم بدلاً من العميل، كما يمكن أن تشمل حتى مفاتيح سرية وبيانات وصول لواجهات برمجة التطبيقات API رغم أن كود الخادم يحذف قبل إرساله للعميل. تسهل هذه الأطر من الكثير من التعقيدات على المطورين وتقدم طريقة محددة لكتابة التعليمات البرمجية. وسنتعمق في تأثيرها على أداء التطبيقات ونوضح العلاقة بين مسارات التصيير render paths وأداء الموقع لاحقًا، لكن لنناقش قبل ذلك بعض المعايير الأساسية لقياس أداء موقع الويب. مقاييس أداء الموقع سنوضح الآن بعض المعايير التي تستخدمها محركات البحث لتصنيف وترتيب مواقع الويب لنساعدك على فهم المزيد حول رفع رتبة موقعك في نتائج البحث. إلى جانب الإجابة على استفسار المستخدم بسرعة ودقة، تعتقد جوجل أن موقع الويب الجيد يجب أن يحقق ما يلي: يتمكن المستخدمون من الوصول إلى محتوى الموقع بسرعة ودون الانتظار لوقت طويل. يتفاعل الموقع مع إجراءات المستخدم خلال وقت قصير. يُحمّل الموقع بسرعة. لا يجلب الموقع أي بيانات غير ضرورية، ولا ينفذ تعليمات برمجية مستهلكة للموارد تستنزف بيانات المستخدم أو موارد جهازه. تتوافق هذه الميزات تقريبًا مع المقاييس التالية: زمن وصول أول بايت (TTFB): هو اختصار لعبارة Time to First Byte ويعني مقدار الوقت الذي يستغرقه وصول أول جزء من المحتوى من الخادم إلى المتصفح، أو الوقت بين النقر على الرابط ووصول الجزء الأول من المحتوى للمستخدم. أضخم محتوى مرئي (LCP): وهو اختصار لعبارة Largest Contentful Paint ويمثل الزمن الذي يحتاجه عرض العنصر الذي يتضمن أضخم جزء مرئي من الصفحة وهو يعطي فكرة عن زمن انتظار المستخدم لتحميل ما يكفي من الصفحة لتصبح ذات معنى، وتوصي جوجل بأن لا تتجاوز هذه القيمة 2.5 ثانية. زمن التفاعل (TTI): وهو اختصار لعبارة Time to Interactive ويعني الوقت الذي تصبح فيه الصفحة تفاعلية أي يمكن للمستخدم النقر فوق عناصر أو تمريرها…إلخ. حجم الحزمة (Bundle Size): ويمثل إجمالي عدد البايتات المحملة والتعليمات البرمجية المنفذة قبل أن تصبح الصفحة مرئية وتفاعلية بالكامل. سنعود للحديث عن هذه المقاييس لاحقًا لفهم كيفية تأثير مسارات التصيير render paths المختلفة على كل منها بشكل أفضل. وسنوضح تاليًا ما هي مسارات التصيير المتاحة لمطوري رياكت. مسارات التصيير Render Paths نعني بمسارات التصيير الطرق المختلفة التي يمكن من خلالها الوصول إلى محتوى الصفحة حيث يمكننا تصيير أو عرض تطبيق React على جانب المتصفح client-side أو على جانب الخادم server-side وإنتاج مخرجات مختلفة. وهنالك وظيفتان تتفاوتان بشكل كبير بين التطبيقات المصيًّرة من جانب العميل والخادم وهما عملية التوجيه routing، وعملية تقسيم التعليمات البرمجية code splitting، لنتعرف على آلية القيام بكل منهما في كل حالة: حالة التصيير من جانب العميل (CSR) التصيير من جانب العميل هو مسار التصيير الافتراضي في تطبيقات رياكت ذات الصفحة الواحدة React SPA. حيث أن الخادم يوفر غلاف تطبيق shell app لا يتضمن أي محتوى فعلي وبمجرد قيام المتصفح بتحميل أكواد جافا سكريبت JavaScript المضمنة في الصفحة ويحللها وينفذها سيملأ محتوى HTML ويعرض بالكامل. في هذه الحالة يتم التعامل مع وظيفة التوجيه بواسطة تطبيق العميل client app من خلال إدارة سجل المتصفح browser history. وهذا يعني أنه يتم تصيير أو عرض نفس ملف HTML بغض النظر عن المسار الذي طُلِب، ويقوم العميل بتحديث حالة العرض view state الخاصة به بعد عرضه. أما تقسيم الكود في هذه الحالة فهو أمر بسيط نسبيًا حيث يمكن تقسيم التعليمات البرمجية الخاصة بالتطبيق باستخدام الاستيراد الديناميكي dynamic imports أو بالاستعانة بمكتبة React.lazy إذ يقسم الكود بحيث يتم تحميل التبعيات المطلوبة فقط بناءً على المسار أو إجراءات المستخدم. إذا كانت الصفحة بحاجة إلى جلب بيانات معينة من الخادم لتصيير المحتوى مثل عنوان المدونة أو وصف منتج ما فلن تتمكن من القيام بذلك إلا عندما يتم تثبيت المكونات ذات الصلة وعرضها، وسيرى المستخدم غالبًا عبارة مثل "جاري تحميل البيانات" أثناء قيام موقع الويب بجلب واستيراد الموقع لبيانات إضافية. إذَا في هذه الحالة لن تسترد البيانات من الخادم إلا عند الحاجة إليها لعرض المحتوى. وهذا يقلل وقت التحميل الأولي للصفحة ويوفر تجربة مستخدم أفضل. ومع ذلك، قد يرى المستخدم مؤشر تحميل أثناء استرداد البيانات الإضافية. التصيير من جانب العميل باستخدام البيانات التمهيدية (CSRB) لنفترض أن لدينا حالة تصيير من جانب العميل CSR ولكن بدلاً من جلب البيانات بعد تصيير وعرض مستند DOM بحيث تظهر المحتويات أو البيانات ذات الصلة بشكل تدريجي، سنفترض أن الخادم يرسل البيانات ذات الصلة مباشرة داخل كود HTML المُصَيَّر. يمكن أن نضيف عقدة node كما يلي داخل صفحة HTML: <script id="data" type="application/json"> {"title": "My blog title", "comments":["comment 1","comment 2"]} </script> يضمن هذا الكود البيانات بصيغة JSON داخل صفحة HTML، وتحلل هذه القاعدة التي تحتوي على البيانات المطلوبة (وهي عنوان المدونة والتعليقات عليها) وتفسر عند إضافة المكون إلى مستند DOM على النحو التالي: var data = JSON.parse(document.getElementById('data').innerHTML); بهذا نكون قد وفرنا عملية ذهاب وعودة من الخادم، وسيظهر المحتوى بشكل أسرع للمستخدم لأن المتصفح لم يضطر إلى الانتظار لطلب البيانات من الخادم مرة أخرى. تصيير المحتوى الثابت من جانب الخادم (SSRS) في هذه الحالة يتم إنشاء وتصيير الصفحة بالكامل على جانب الخادم قبل إرساله إلى المتصفح، تخيل على سبيل المثال حالة لموقع أو تطبيق ويب تحتاج فيه إلى إنشاء كود HTML بسرعة، على سبيل المثال إذا كنت تريد بناء تطبيق ريآكت لآلة حاسبة عبر الإنترنت، وأدخل المستخدم لهذا التطبيق استعلام من المستخدم من خلال عنوان URL على النحو التالي: /calculate/34+15 يحتاج التطبيق لمعالجة هذا الاستعلام وتقييم النتيجة والرد بكود HTML الذي تم إنشاؤها، وبما أن كود HTML النتاتج يملك بنية بسيط جدًا فلست بحاجة لأن تقوم رياكت بإدارة DOM ومعالجته ويمكنك الاكتفاء بعرض HTML الناتج مباشرة. لذلك يمكن توفير محتوى HTML و CSS فقط واستخدام التابع renderToStaticMarkup لتحقيق ذلك. سيتعامل التطبيق في هذه الحالة مع التوجيه بالكامل من جانب الخادم لأنه يحتاج إلى إعادة حساب HTML لكل نتيجة (كلما تم تغيير عنوان URL)، كما يمكن استخدام التخزين المؤقت لكود HTML الناتج ضمن شبكة توصيل المحتوى CDN لتسريع استجابة التطبيق. ويمكن أيضًا تخزين ملفات CSS مؤقتًا بواسطة المتصفح لتحميل الصفحات اللاحقة بسرعة أكبر. التصيير من جانب الخادم مع المكونات المعززة (SSRH) المكونات المشبعة أو المعززة Hydrated Components هي مكونات رياكت تعمل كجسر بين نسخ التطبيق التي تنشأ على الخادم والعميل، ولفهم آلية عملها تخيل الآن أنك تحتاج لتطوير تطبيق رياكت كامل الوظائف على العميل، أي تطبيق يتطلب تفاعل المستخدمين ويوفر إمكانية تنقلهم بين الصفحات ويحتاج لجلب البيانات من الخادم. ملاحظة:يشير مصطلح التشبيع أو التعزيز hydration في رياكت إلى الطريقة التي تتصل بها React مع كود HTML الموجود مسبقًا والذي تم تصييره بالفعل بواسطة رياكت في جانب الخادم. فهو عملية يتم فيها ربط أو تعزيز شيفرة جافا سكريبت التفاعلية لمحتوى HTML الثابت المصير مسبقًا على الخادم لجعل كود HTML تفاعليًا. وبالتالي تقوم رياكت بتنفيذ التصيير الأول لصفحات الموقع على الخادم، وترسل محتوى HTML الناتج إضافة إلى ملفات جافا سكريبت إلى العميل، ثم تقوم بإعادة تعزيز الكود المرسل من جانب الخادم، ليصبح التطبيق وكأنه تطبيق تصيير من جانب العميل (CSR) من هذه النقطة فصاعدًا. توفر رياكت عدة طرق مدمجة لتنفيذ هذه الإجراءات تسمى ReactDOMServer، حيث تعالج رياكت أول طلب لعرض أو تصيير صفحة ما من جانب الخادم، ثم تتعامل مع الطلبات التالية لعرض هذه الصفحة من جانب العميل. ولهذا يطلق على هذه التطبيقات اسم تطبيقات رياكت العامة لكون عملية العرض أو التصيير تتم على جانبي الخادم والعميل كليهما، وقد يتم تقسيم (أو تكرار) الكود الذي يتعامل مع التوجيه على كل من الخادم والعميل. إن تقسيم الكود أمر صعب بعض الشيء أيضًا، لأن توابع ReactDOMServer المستخدمة لإنشاء صفحات HTML ثابتة على الخادم لا تدعم React.lazy، لذلك لا يمكن استخدامها لتحميل المكونات ديناميكيًا على الخادم وللتعامل مع هذا الأمر قد تضطر لاستخدام المكونات القابلة للتحميل وهي مكونات يمكنك تحميلها ديناميكيًا عند الحاجة. وقد تضطر إلى استخدام شيء مثل Loadable Components. يجب التنويه أيضًا أن ReactDOMServer تقوم فقط بعرض بسيط. وبالرغم من استدعاء طريقة التصيير لمكوناتك، إلا أن الطريقة componentDidMount التي ستحتاج لاستدعائها بعد أن يتم تثبيت المكون في DOM لا تستدعى في هذه الحالة. لذلك تحتاج إلى إعادة تصميم كودك لتوفر البيانات لمكونات التطبيق باستخدام طريقة بديلة. هنا تبرز فائدة إطارات العمل مثل NextJS. فهي تختفي التعقيدات المرتبطة بعمليات التوجيه وتقسيم الكود في حالة تصيير الصفحات على الخادم وتعتمد أسلوب التصيير من جانب الخادم مع المكونات المعززة SSRH لتوفر تجربة أكثر سلاسة للمطورين. التصيير المسبق للمحتوى الثابت (PRS) ماذا لو تمكنا من عرض صفحات الموقع قبل أن يطلبها المستخدم؟ يسمى هذا الأمر التصيير المسبق Pre-rendering وهو أسلوب لإنشاء محتوى HTML للتطبيق بالكامل على الخادم قبل أن يطلبه المستخدم، بعدها يرسل المحتوى للمتصفح ويعرض مباشرة دون الحاجة إلى إنشاء واجهة المستخدم بالكامل من البداية، ويمكن القيام بذلك في وقت إنشاء الموقع أو ديناميكيًا عندما تتغير البيانات. ويمكن فيما بعد تخزين محتوى HTML الناتج على شبكة توصيل المحتوى CDN وتصييره بشكل أسرع عندما يطلبه المستخدم وهو أمر مفيد في كافة المواقع التي لا يعتمد محتواها على البيانات المقدمة من قبل المستخدم كالمدونات وتطبيقات التجارة الإلكترونية. التصيير المسبق مع تفعيل المكونات (PRH) قد ترغب في أن يكون HTML المصير مسبقًا تطبيق React يعمل بكامل طاقته عندما يعرضه العميل. في هذه الطريقة، ينشأ محتوى HTML للتطبيق بالكامل على الخادم كما هو الحال في التصيير المسبق العادي، وإلى جانب ذلك تضمن كذلك معلومات الحالة المقابلة لكل عنصر رياكت في محتوى HTML. وبالتالي في هذه الطريقة، بعد تقديم الطلب الأول لعرض التطبيق، سيتصرف التطبيق مثل تطبيق React القياسي. وبشكل مشابه لحالة تصيير الصفحات على الخادم SSRH من حيث التعامل مع وظائف التوجيه وتقسيم التعليمات البرمجية. مصفوفة الأداء لنناقش الآن كيفية تأثير كل مسار من مسارات التصيير التي وضحناها سابقًا على مقاييس أداء مواقع الويب ونعرف أي طريقة منها هي الأفضل من خلال الجدول التالي الذي يعطي نتيجة تتراوح من 1 إلى 5 وتدل النتائج على ما يلي: نتيجة غير مرضية نتيجة ضعيفة 3.نتيجة متوسطة نتيجة جيدة نتيجة ممتازة TTFB LCP TTI حجم الحزمة المجموع CSR 5 يمكن تخزين HTML مؤقتاً على شبكة CDN 1 يحتاج للذهاب مرات متعددة للخادم لجلب البيانات 2 تأخر في جلب البيانات وفي تنفيذ أكواد جافا سكريبت 2 تحميل جميع تبعيات الجافا سكريبت قبل التصيير 10 CSRB 4 يمكن تخزين HTML مؤقتًا بشرط عدم اعتماده على بيانات الطلب 3 تحميل البيانات مع التطبيق 3 يجب جلب جافا سكريبت وتحليلها وتنفيذها قبل التفاعل 2 تحميل جميع تبعيات الجافا سكريبت قبل التصيير 12 SSRS 3 يُولَّد كود HTML في كل طلب ولا يمكن تخزينه مؤقتًا 5 عدم تحميل جافا سكريبت أو عمليات غير متزامنة 5 الصفحة تكون تفاعلية فورًا بعد الرسم الأول 5 يحتوي على المحتوى الثابت الأساسي فقط\ 18 SSRH 3 يُولَّد HTML في كل طلب ولا يمكن تخزينه مؤقتًا 4 الرسم الأول أسرع بسبب التصيير الأول على جانب الخادم 2 أبطأ بسبب تنشيط DOM بعد تحليل ورسم HTML أول مرة 1 HTML الناتج+ تحميل تبعيات الجافا سكريبت 10 PRS 5 تخزين HTML مؤقتًا على شبكة CDN 5 عدم تحميل جافا سكريبت أو عمليات غير متزامنة 5 تكون الصفحة تكون تفاعلية فورًا بعد الرسم الأول 5 يحتوي على المحتوى الثابت الأساسي فقط 20 PRH 5 تخزين HTML مؤقتًا على شبكة CDN 4 التصيير الأول أسرع بسبب التصيير من جانب الخادم لأول مرة 2 أبطأ بسبب تفعيل DOM بعد تحليل ورسم HTML الأول 1 HTML المصير+ تحميل تبعيات الجافا سكريبت 12 يمكن أن نستنتج من الجدول السابق ما يلي: يؤدي التصيير المسبق للمحتوى الثابت (PRS) إلى أفضل أداء لمواقع الويب، بينما قد يؤدي التصيير من جانب الخادم مع المكونات المعززة (SSRH) أو التصيير من جانب العميل (CSR) إلى نتائج غير مرضية. من الممكن أيضًا استخدام أساليب متعددة لأجزاء مختلفة من موقع الويب. على سبيل المثال، قد تكون مقاييس الأداء هذه مهمة لصفحات الويب العامة حتى يمكن فهرستها بشكل أكثر فعالية، بينما قد تكون أقل أهمية بمجرد دخول المستخدم ورؤية بيانات حسابه الخاصة. يعتمد اختيار كل مسار على طبعة تطبيقك وكيفية معالجة بياناتك، اختر ما يناسبك بحيث تحسن تجربة المستخدمين بأفضل صورة ممكنة. طرق إضافية لتحسين سيو مواقع الويب حاولنا في هذه المقالة أن نناقش الأساليب والتقنيات الشائعة حاليًا بتحسين أداء تطبيقات رياكت وتعزيزها في محركات البحث، ويمكن إضافة إلى ما سبق الاطلاع على النصائح والاستراتيجيات التي يوفرها مطورو جوجل. وأخيرًا من العوامل الإضافية التي تساعدك على تحسين سيو تطبيقات ومواقع الويب المطورة بمكتبة رياكت اعتماد نظام إدارة محتوى موقعك CMS جيد لاسيما عند إنشاء مواقع ويب ذات محتوى ضخم، وتوفير ميزة إنشاء وتعديل معاينات وسائل التواصل الاجتماعي بسهولة وتحسين الصور لتتناسب مع مختلف أحجام الشاشات فهذه العوامل من شأنها تحسين سرعة تحميل الصفحة وتحسين تجربة المستخدم بشكل كبير. الخاتمة هذا تكون قد وصلت لنهاية هذا المقال الذي وضحنا فيه أبرز تحديات تحسين محركات البحث في تطبيقات ومواقع رياكت، ووضحنا أهم الاستراتيجيات التقنيات المستخدمة التي يمكنك القيام بها للتغلب عليها لتحسين سيو تطبيقات ومواقع رياكت React الخاصة بك وتحسين فرصك في ظهورها في نتائج البحث. اقرأ أيضًا مقارنة شاملة بين رياكت React و Next.js المصطلحات المستخدمة في React شمولية تطبيقات React لكافة أنواع المستخدمين تقسيم تطبيق React إلى مكونات