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

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

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

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

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

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

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

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

أفضل الممارسات:

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

احرص دائمًا على توفير إمكانية الوصول بشكل مستقل إلى عناوين URL الخاصة بك:

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

من المفترض أن يؤدي العنوان أعلاه إلى الربط بذلك المورد المعيّن.

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

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

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

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

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

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

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

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

أفضل الممارسات:

وفِّر عناوين URL سهلة الاستخدام بدون أيّ معرّفات أجزاء (# أو ‎#!)، مثل:

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

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

تجنَّب ما يلي:

لا يُنصح باستخدام بنية ‎#! لعنوان URL بهدف إنشاء عناوين URL فريدة:

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

لقد تم تقديم هذه الطريقة كحل بديل قبل توفُّر History API، وتُعتبر نمطًا منفصلاً عن بنية # البحتة لعنوان URL.

لا نتيح استخدام بنية # لعنوان URL بدون إرفاق الرمز !، مثلاً:

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

بنية عنوان URL هذه هي من المفاهيم الحالية على الويب، وهي ذات صلة بالربط بمحتوى صفحة معيّنة.

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

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

أفضل الممارسات:

ضمِّن العلامة التالية في جميع الصفحات التي تعرض نسخًا مطابقة من المحتوى نفسه:

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

إذا كنت تتيح Accelerated Mobile Pages، احرص أيضًا على استخدام تعليمات العلامة النظيرة rel="amphtml" بشكل صحيح.

تجنَّب ما يلي:

تجنَّب تكرار المحتوى عن قصد ضمن عدة عناوين URL بدون استخدام عنصر الرابط rel="canonical".

على سبيل المثال، يمكن لعنصر الرابط rel="canonical" تقليل الالتباس بالنسبة إلى عناوين URL التي تتضمّن معايير التتبع.

احرص على ألا يكون هناك تعارُض في الروابط المؤدية إلى الصفحة الأساسية.

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

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

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

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

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

أفضل الممارسات:

استخدِم السمة srcset لجلب صور ذات درجات دقة مختلفة للشاشات ذات الكثافات المختلفة، وذلك لتجنُّب تنزيل صور يزيد حجمها عن قدرة العرض الخاصة بشاشة الجهاز.

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

اختبِر درجات الدقة المختلفة للشاشات باستخدام ميزة مجموعة محاكاة الأجهزة الجوّالة من "أدوات مطوّري برامج Chrome" وأداة فحص التوافق مع الأجهزة الجوّالة.

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

استخدِم أداة "الجلب مثل Google" في Search Console للتأكّد من أنّ المحتوى الذي يجلبه محرّك بحث Google مطابق للمحتوى الذي يراه المستخدم.

لأسباب مرتبطة بسهولة الاستخدام، تجنَّب استخدام الخطوط ذات الحجم الثابت.

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

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

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

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

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

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

أفضل الممارسات:

نفِّذ التكرار على موقعك الإلكتروني بشكل تدريجي عن طريق إضافة الميزات الجديدة على مراحل.

على سبيل المثال، إذا كان موقعك الإلكتروني لا يتيح HTTPS بعد، ننصحك أن تبدأ بالانتقال إلى موقع إلكتروني آمن.

تجنَّب ما يلي:

إذا كنت قد طوّرت تطبيق الويب التقدّمي الخاص بك في بيئة تطوير معزولة، تجنَّب إطلاقه قبل التأكد من إعداد روابط rel-canonical وملف robots.txt بشكل صحيح.

احرص على أن تشير روابط rel-canonical إلى الموقع الإلكتروني الفعلي وأن تكون إعدادات ملف robots.txt تتيح لبرامج الزحف أن تزحف إلى موقعك الإلكتروني الجديد.

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

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

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

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

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

أفضل الممارسات:

قبل تسجيل "مشغّل الخدمات"، تأكَّد مِن توفّر واجهة برمجة التطبيقات الخاصة به:

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

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

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

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

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

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

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

أفضل الممارسات:

راقِب موقعك الإلكتروني باستخدام Search Console وتعرَّف على الميزات المختلفة لهذه الخدمة، بما في ذلك ميزة "الجلب مثل Google".

وفِّر ملف Sitemap من خلال Search Console عبر الانتقال إلى الزحف > ملفات Sitemap. يمكن أن تكون هذه الطريقة فعّالة لضمان أن يطّلع محرّك بحث Google على جميع صفحات موقعك الإلكتروني.

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

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

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

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

أفضل الممارسات:

تأكَّد من أنّ ترميز بيانات Schema.org صحيح باستخدام أداة اختبار البيانات المنظَّمة من Google.

تأكَّد من أنّ البيانات التي قدّمتها تظهر ومن أنّها خالية من أيّ أخطاء.

تجنَّب استخدام نوع بيانات لا يطابق المحتوى المعروض على صفحتك. على سبيل المثال، إذا كنت تعرض قميصًا للبيع، لا تستخدِم Recipe، بل استخدِم Product.

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

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

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

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

أفضل الممارسات:

اختبِر ترميز Open Graph باستخدام أداة Facebook Object Debugger.

اطّلِع على معلومات عن صيغة البيانات الوصفية على Twitter.

لا تنسَ تضمين هاتين الصيغتين إذا كانتا متاحتين على موقعك الإلكتروني الحالي.

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

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

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

أفضل الممارسات:

استخدِم أدوات اختبار متوافقة مع مختلَف المتصفحات مثل BrowserStack.com أو Browserling.com أو BrowserShots.org لضمان أن يكون تطبيق PWA الخاص بك متوافقًا مع مختلَف المتصفحات.

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

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

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

أفضل الممارسات:

استخدِم أدوات مثل إحصاءات PageSpeed وWebPageTest لقياس مستوى أداء تحميل الصفحة على موقعك الإلكتروني. وبينما قد يكون برنامج Googlebot صبورًا نسبيًا أثناء عرض الصفحات، أظهرت الأبحاث أنّ %40 من المستهلكين سيغادرون الصفحة إذا استغرق تحميلها أكثر من ثلاث ثوانٍ.

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

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

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

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

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