إنشاء تطبيقات ويب تقدّمية قابلة لل��هرسة

الأربعاء 9 تشرين الثاني (نوفمبر) 2016

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

إتاحة إمكانية الزحف إلى المحتوى الخاص بك

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

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

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

إذا لم تكُن مطّلعًا من قَبل على مصطلحَي العرض من جهة الخادم ومن جهة العميل، يمكنك مراجعة المقالتين التاليتين بخصوص العرض من جهة الخادم ومن جهة العميل والعرض من جهة الخادم في React وNode.js.

https://www.example.com/product/25/

توفير عناوين URL سهلة الاستخدام

لماذا؟ كانت معرّفات الأجزاء (مثل ‎#user/24601/ أو ‎#!user/24601/) حلاً بديلاً فعالاً للمتصفحات لكي يتم الزحف إلى المحتوى الجديد من خادم ��استخدام نظام AJAX بدون أن تتم إعادة تحميل الصفحة. ويُعرف هذا التصميم باسم العرض من جهة العميل.

مع ذلك، إنّ بنية معرّفات الأجزاء غير متوافقة مع بعض الأدوات وأُطر العمل والبروتوكولات على الويب، مثل بروتوكول Open Graph الخاص بـ Facebook.

يتيح لنا History API تعديل عنوان URL بدون معرّفات الأجزاء مع مواصلة جلب الموارد بشكل غير متزامن، وبالتالي تجنُّب إعادة تحميل الصفحات، ويوفّر هذا الخيار أفضل ما في الطريقتين. وقد بدا مخطّط زحف AJAX (مع ‎#! / عناوين URL التي تم إلغاء أجزاء منها) منطقيًا في ذلك الحين، إلا أنّنا لم نعُد ننصح باستخدامه.

يظهر History API في نموذجَي PWA المختلط وPWA من جهة العميل.

    https://www.example.com/product/25/
  

    https://www.example.com/#!product/25/

تحديد عناوين URL الأساسية

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

<link rel="canonical"  href="https://www.example.com/your-url/" />

إنشاء تصميم متوافق مع عدة أجهزة

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

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

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

تعرَّف على مزيد من المعلومات عن تجربة المستخدم في تطبيقات PWA.

التطوير عن طريق التكرار

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

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

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

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

في كلتا الحالتين، إنّ النقطتين الأهم اللتين يجب الانتباه إليهما هما عناوين URL الأساسية وإعدادات ملف robots.txt على موقعك الإلكتروني.

استخدام التحسين المتدرّج

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

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

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

if ('serviceWorker' in navigator) {
...

تنفيذ اختبارات باستخدام Search Console

لماذا؟ من المهم أن تفهم كيف يرى محرّك بحث Google موقعك الإلكتروني. يمكنك استخدام Search Console بهدف جلب عناوين URL فردية من موقعك الإلكتروني والاطّلاع على كيفية ظهورها لمحرّك بحث Google باستخدام ميزة "الزحف > الجلب مثل Google". ستعالج خدمة Search Console ترميز JavaScript وتعرض الصفحة في حال كان ذلك الخيار محددًا. إذا لم يكُن الأمر كذلك، سيتم عرض استجابة HTML الأولية فقط.

تحلّل خدمة Google Search Console أيضًا المحتوى على صفحتك باستخدام طرق متعددة، بما في ذلك رصد توفُّر البيانات المنظَّمة والبطاقات التفاعلية ��روابط أقسام الموقع وصفحات Accelerated Mobile Pages.

إضافة التعليقات التوضحية باستخدام بيانات Schema.org المنظَّمة

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

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

تتوفر أنواع متعددة من البيانات، بما في ذلك NewsArticle وRecipe وProduct والكثير غيرها. يمكنك أيضًا التعرّف هنا على جميع أنواع البيانات المتوافقة.

إضافة التعليقات التوضيحية باستخدام Open Graph وبطاقات Twitter

لماذا؟ بالإضافة إلى استخدام بيانات Schema.org الوصفية، قد يكون مفيدًا أيضًا إتاحة التوافق مع بروتوكول Open Graph من Facebook والبطاقات التفاعلية من Twitter أيضًا.

هاتان الصيغتان من البيانات الوصفية تحسّنان تجربة المستخدم عندما تتم مشاركة المحتوى الخاص بك على شبكة التواصل الاجتماعي المعنيّة.

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

الاختبار باستخدام متصفحات متعددة

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

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

قياس أداء تحميل الصفحة

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

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

نأمل أن تفيدك قائمة التحقّق أعلاه وأن توفّر لك الإرشادات المناسبة لمساعدتك في تطوير تطبيقات الويب التقدّمية الخاصة بك بدون إغفال أهمية قابلية الفهرسة.

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

الناشر: "توم غرينواي"، مسؤول علاقات المطوّرين