البحث في الموقع

دخل إلى مجال الويب مؤخرًا العديد من الأفكار والتقنيات والإضافات لغاية خدمة تجربة المستخدم في تطبيقات الويب، مثل دعم الإشعارات وتوافر أيقونة على سطح المكتب وإتاحة التحكم بالـ API والعمل بشاشة كاملة وأهم عناصر وأركان هذه التقنيات والإضافات "عامل أو منجز خدمة" Service Worker وما يقدمه من عمل التطبيق بدون الاتصال في الشبكة والتخزين المؤقت وغيرها مما ساهم بإنجاح تجربة المستخدم لهذه التطبيقات. مفهوم Service Worker منجز خدمة هو سكريبت (script) ينفذ في خلفية مشروع الويب (موقع أو تطبيق)، غير مرتبط بصفحة معينة. مسؤول عن الأحداث التي تجري بالمشروع مثل طلبات الشبكة الصادرة من الصفحة المسؤول عنها والاستجابات لهذه الطلبات، له عدة غايات من أهمها اتاحة استخدام التطبيق مع الشبكة أو بانقطاعها أو ببطئها. فلو افترضنا شخصًا يستخدم موقعًا وكان متصلًا بالشبكة وأثناء تصفحه للموقع انقطع اتصاله بالشبكة ولكن أراد الرجوع للصفحة السابقة عند إذٍ لن تفتح الصفحة السابقة وستظهر له شاشة تعلمه بإنقطاعه عن الشبكة، لكن إن كان ذلك الموقع يملك Service Worker فلن يحدث هذا، بل ستظهر الصفحة السابقة أو على الأقل جزء منها. ومن اللطيف ذكره أن أي موقع ويب بإمكانه أن يمتلك Service Worker وأن يُفعله مستفيدًا من مزاياه الرائعة، لكن في حالة تطبيقات الويب التقدمية PWA يجب أن تمتلكه وأن يكون مسجلًا وفعالًا فهو من شروط عملها. أهم الميزات التي يضفيها على مشروعك سرعة كبيرة يركز ال Service Worker في فكرته بشكل كبير على السرعة والأداء المثالي في التحميل وذلك في حالة اتصال الشبكة أو بدونها أو ببطئها وتكون أطول فترة تحميل في المرة الأولى وأما في الزيارات المتكررة يتم تحميلها بشكل أسرع. انظر المثال في الصورة حيث كان وقت التحميل في المرة الأولى 2.5 ثانية وفي الزيارات الأخرى 0.8 ثانية أي انخفضت إلى أقل من الثلث وهذا مثال بسيط. (بإمكانك اختبار أداء فاعلية مشروعك من خلال هذه الأداة WEBPAGETSET). العمل بدون شبكة كانت تتميز التطبيقات (العادية) عن الويب إمكانية عملها من غير اتصال شبكة، لكن الآن مع الـ Service Worker يمكن لمواقع وتطبيقات الويب أن تعمل بدون اتصال شبكة والذي يقوم بتخزين الموارد والعناصر التي ترتبط بالأحداث والتفاعل لاستخدامها بدون اتصال شبكة أو ببطئها. التحديث المستمر للتطبيق يعتبر Service Worker المسؤول عن التحديثات في تطبيقات الويب، بل يتميز عن تحديثات أنواع البرامج والتطبيقات الأخرى بالسلاسة والاستمرارية والسهولة وذلك من خلال تخزين وتثبيت الموارد المحدثة فقط وبشكل تلقائي ويظهر شارة صغيرة للمستخدم عند فتح التطبيق بأن التطبيق تم تحديثه. سيطرة أعلى يمنح Service Worker لمطورين المواقع والتطبيقات سيطرة كاملة وأفضل على تجربة المستخدم للتطبيق. تجربة تطبيقات حقيقية يدعم Service Worker ويحسن تجربة المستخدم في التطبيقات ومحاكاتها من خلال ما يوفر من السرعة والعمل بدون اتصال الشبكة والتخزين المؤقت وهيكل التطبيق (الذي سنفصل فيه) وغيرها. وكذلك يمنح تجربة تطبيقات حقيقية ويحسنها للجوال حيث تكون منفصلة ومستقلة عن المتصفحات لا يشترط أن تكون مبنية عليها. بنية هيكل التطبيق application shell architecture عند تكرار زيارة الموقع أو عند تحميل التطبيق يتم تخزين حد معين من الشيفرات المصدرية HTML، و CSS، و JavaScript مؤقتًا ليتم استعمالها بدون اتصال الشبكة أو حتى مع اتصالها ولكن بشكل فوري وأسرع. وصلب الفكرة هنا أننا نملك هيكل يمثل جزءًا معينًا من التطبيق أو الموقع موجود على جهاز المستخدم يُحمل ويُبنى فورًا عند فتحه سواء مع اتصال شبكة أو بدون ثم يبدأ إضافة المحتوى غير المشمول فيها من الشبكة على هذا الهيكل إذ هو بمثابة الوعاء الفارغ الذي يوضع فيه شيء ما.(يعني نحافظ على واجهة المستخدم الأساسية على جهاز المستخدم ولا داعي لتحميلها كل مرة). وبهذا فإنها تخدم التجربة كثيرًا بغض النظر عن اتصال الشبكة أو سرعتها. وحتى إن كانت فكرة التطبيق/الموقع تعتمد بشكل كامل على اتصال الشبكة فإن المستخدم سيحصل على هيكل وشكل جذاب ومناسب بعدم اتصال الشبكة ويتوافق مع شكل التطبيق الأصلي ولن تظهر له شاشة عدم الاتصال، فهذا الهيكل يلعب دورًا عظيمًا في الأداء المثالي للموقع أو التطبيق من سرعة وخفة وتجربة مثالية. بعد فتح الموقع في المرة الأولى وتحميل الـ Service Worker لهذا الهيكل تظهر شارة أن البرنامج جاهز للعمل بدون اتصال شبكة. والمسؤول عن هذا الهيكل هو Service Worker وفي حال عدم دعم المتصفح لـ Service Worker لا داعي للقلق، فإن الهيكل والصفحة كاملة ستعتمد في تحميلها على استراتيجية الويب الشهيرة Progressive Enhancement بدون مشاكل. ومن الأمثلة الناجحة في استخدام فكرة هذا الهيكل: Google’s Inbox و offline Wikipedia app ومعظم مشاريع نقاية. آلية عمل الـ Service Worker وحدود إمكانياته عند الزيارة الأولى للموقع أو عند تثبيت التطبيق يتم بناء الـ Service Worker وأخذ المحتوى والهيكل وكل البيانات والموارد من الخادم، وفي المرات التالية يتم سحب بيانات وعناصر محددة من الخادم ولكن كيف يتم تنظيم هذا السحب؟ كيف يتم تحميل بعض العناصر من Service worker وأخرى من الخادم؟ يعترض Service Worker طلبات الشبكة الصادرة من الصفحة وهنا يقوم بالاستجابة لهذه الطلبات بواحدة مما يلي: جلب المطلوب من الخادم عبر الشبكة. جلب المطلوب من الذاكرة المؤقتة على جهاز المستخدم، يتم جلب من الذاكرة المؤقتة العناصر والموارد المحددة مسبقًا لتجلب منها (مثل الهيكل الذي تحدثنا عنه). بناء المطلوب برمجيًا. والرائع هنا أن هذا كله يحدث دون أن يظهر مصدر الإستجابة ولا حتى أن الـ Service Worker قد تدخل. فلو تتبعنا دورة حياة الـ Service Worker لوجدنا أنه يتم بناءه عند أول دخول ويُحمل بعض الموارد عليه، ثم يُفعل ويَستيقظ عند وجود أي حدث، ويستجيب لهذا الحدث إن لزم الأمر مؤديًا دوره، ثم يُحذف من الذاكرة بمحتواه عند مرور الزمن دون أن ينشط، وتم إنشائه هكذا محدود العمر عن قصد. ومن الجيد معرفته أن Service Worker يحتوي على API محدودة مقارنة بما تحتويه الـ JavaScript في الصفحة العادية، بإمكانك أن تعرف تفاصيل API له هنا. واعلم بأن Service worker لا يمكنه الوصول إلى الـ DOM ولكن يمكنه الوصول إلى ذاكرة التخزين. ويمكنه أيضًا ارسال طلبات الشبكة، كذلك يمكنه أن يتواصل وأن يتبادل البيانات مع الصفحة المسؤول عنها عن طريق IndexedDB API و postMessage. لا تفوت ميزاته مع مشاريعك القادمة لكن بحدود يتبين مما سبق البون الشاسع الذي يُحدِثه الـ Service Worker في أداء مشاريع الويب معه، لذا يُنصح وبشدة استخدامه في تطبيقات ومواقع الويب، لكن بشكل معقول، فليس من المنطق أن تضيفه إلى مواقع صغيرة الحجم أو لا تقدم خدمة وتفاعل وتميل للمحتوى الثابت الخفيف فلا فائدة أو معنى من إضافته لمثلها. تسهيل الحصول على Service Worker مع Workbox يعتبر Workbox مجموعة من المكتبات والأدوات المستخدمة لإنشاء Service Worker والتخزين المؤقت وغيرها وتسهيل ذلك. مراجع Instant Loading Web Apps With A Service Worker Application Shell Architecture Service Workers: an Introduction Using Web Workers Cache Fetch API IndexedDB API Client.postMessage() Application Shell Architecture workbox What Are Service Workers and How They Help Improve Performance

هل تحتاج إلى تطبيق في متجر التطبيقات؟ هل يجب أن تكون أصلية (Native) أم مُهجّنة (Hybrid)؟ ما الفرق بين تطبيق جوال وتطبيق ويب وموقع متجاوب؟ هل تعتقد أن يكون الموقع متجاوبًا (Responsive Website)، فهذا يجعله متوافقًا مع الجوال (Mobile Friendly)؟ كل هذه الاسئلة عليك أن تُجيب عنها إذا ما أردت التعامل مع الأجهزة المحمولة كمُطوِّر، وهذا ما سنسلط عليه الضوء في هذا المقال. أنواع تطبيقات الجوال هناك الكثير من الالتباس بين المؤسسات حول كيفية التعامل مع الأجهزة المحمولة. ومع ذلك، عندما يتعلق الأمر بهذا فلديك 4 خيارات كالتالي: التطبيقات الأصلية أو الأصيلة (Native Applications). تطبيقات الويب (Web Application). التطبيقات المُهجّنة (Hybird Application). المواقع المُتجاوبة (Responsive Websites). التطبيقات الأصلية (Native Applications) التطبيقات الأصلية هي تطبيقات تعمل فعليًا على الجهاز المحمول ويتم ترميزها خصيصًا لنظام تشغيل الجهاز. هذه هي التطبيقات التي تجدها عادةً في متجر تطبيقات Google Play أو iOS. هذا هو أفضل نهج حيث السرعة والميزات الأصلية (Native Features) مطلوبة. تطبيقات الويب (Web Application) هناك خصائص مشتركة بين كلٍ من تطبيقات الويب، التطبيقات الأصلية، والمواقع المُتجاوبة. كما هو الحال مع الموقع المتجاوب، تُصمَّم تطبيقات الويب باستخدام HTML و CSS و Javascript ويكون بالكامل على الإنترنت. ومع ذلك، عندما يكون الموقع المُتجاوب موجَّهًا للمحتوى (Content Oriented)، فإن تطبيق الويب يركز على المهمة بنفس طريقة التطبيق الأصلي. ومن الأمثلة على ذلك تطبيق Blackpool Pleasure Beach للهاتف المحمول. التطبيق متاح عبر الإنترنت ولكنه ليس موقع ويب غني بالمحتوى. بدلاً من ذلك، إنه تطبيق حجز يسمح للمستخدمين بشراء تذاكرهم وبطاقاتهم. نظرًا لأنه يتطلب اتصالًا مستمرًا بالخادم(Server)، ولم يستخدمه المستخدمون بشكل منتظم ولا يحتاج إلى ميزات أصلية، فلا فائدة من جعله تطبيقًا أصليًا. التطبيقات الهجينة (Hybird Application) ربما يكون التطبيق المُهجّن أو الهجين هو الأصعب في شرح الخيارات. يُعَد التطبيق المُهجّن تطبيقًا أصليًا أُنشئ باستخدام HTML و CSS و Javascript. فمن خلال بناء هذه التطبيقات باستخدام تقنية الويب، يكون تطويرها أسرع وأسهل للنشر على منصات متعددة (مثل iOS أو Android). الجانب السلبي هو أن الأداء لا يميل إلى أن يكون جيدًا ويفتقر إلى نمط التصميم لكل منصة. مثال على هذا النوع من التطبيقات هو إثبات مفهوم تطبيق "فراشة العد butterfly counting" الذي طوّرته Headscape. تم بناء هذا التطبيق المُهجَّن في PhoneGap وسمح للمستخدمين بتحديد وحساب الفراشات في الحقل حتى مع عدم وجود اتصال بالانترنت. كان قرار إنشاء هذا كتطبيق هجين لأنه إثباتًا للمفهوم وأرادت الشركة إنتاجه بسرعة وبأقل تكلفة. المواقع المتجاوبة (Responsive Websites) الموقع المُتجاوب هو الذي يتكيف مع أي جهاز يتم عرضه عليه. سواء كان ذلك عبارة عن جهاز سطح مكتب أو جهاز لوحي أو جهاز محمول، سيعرض موقع الويب نفسه المحتوى نفسه باستخدام تصميم مرئي يناسب هذا الجهاز. خذ على سبيل المثال Macmillian English. فهو موقعٌ غنيٌّ جدًا بالمعلومات. يُنقِّب مستخدمو الموقع عن المعلومات بدلاً من إتمام المهام. يضمن موقع الويب المتجاوب أن يتمكنوا من العثور على نفس المعلومات مهما كان الجهاز الذي يستخدمونه. المواقع المُتجاوبة جيدة لـ : المواقع الغنيّة بالمعلومات. المستخدمين الذين يتطلعون إلى جمع المعلومات. إذا كنت لست متأكدًا من الخيار الذي تحتاجه، فعادةً ما يكون الموقع المُتجاوب نقطة انطلاقٍ جيدة. هذا ما نعتقده عادًًة، أن تكون المواقع مُتجاوبة، فهذا يجعلها متوافقة مع الجوال (Mobile Friendly)، لكن هذا ليس كل ما في الأمر. لا تزال هناك طرق كثيرة تُمكّننا من إفساد تجربة المُستخدم والإضرار بموضعنا في نتائج البحث. ألق نظرة على دورة تطوير تطبيقات الجوال باستخدام تقنيات الويب والتي ستتعلم فيها تطوير تطبيقات جوال لأنظمة أندرويد وأيفون و ويندوز فون باستخدام تقنيات الويب البسيطة JavaScript, HTML, CSS مما يمكنك من تطوير تطبيق واحد يعمل مباشرة على جميع المنصات. إنشاء موقع متجاوب متوافق تمامًا مع الجوال ندرك جيدًا أهمية أن يكون الموقع متوافقًا مع الجوال، ويميل معظمنا إلى التفكير في "التصميم المتجاوب Responsive Website" كحل لهذا. لا ريب أن "التصميم المُتجاوب" قد أحدث طفرةً في تطبيقات الويب على الهواتف الذكيّة. فبوجٍه عام، لقد حسّنَ "تجربة المُستخدم User Experience" وسهّل علينا إدارة المواقع وجنّبنا الحفاظ على إصدارات متعددة لنفس الموقع. دعني أقدم لك بعض الأمثلة عن "أين يمكن أن تسوء الأمور" بدءًا من المشكلة الأكبر على الإطلاق "المواقع شبه المتجاوبة". هل موقعك مُتجاوب بالكامل؟ عندما نقوم بإعادة تصميم موقع ويب من البداية، فإن بناءه حيث يصبح "موقعًا متجاوبًا" أمرًا منطقيًا تمامًا. لكن تعديل لموقع موجود بالفعل (خاصةً إذا كان موقعًا كبيرًا) حيث يصبح "موقعًا متجاوبًا"، يمكن لهذا أن يتحول إلى كابوس. العديد من العملاء واجهوا هذه المشكلة، تحتوي معظم المواقع الإلكترونية الخاصة بهم على عشرات الآلاف من الصفحات على الأقل، تم إنشاؤها على مدار سنوات. مما جعل أمر أن تكون هذه المواقع "صديقة للهواتف الذكيّة" تحديًا بشكل لا يُصدَّق. لتقليل العمل الذي ينطوي عليه الأمر، فهم يتخذون قرارًا بالتركيز على الصفحات الأساسية وجعلها سهلة الاستخدام على الهواتف الذكيّة ومٌتجاوبة أيضًا، متجاهلين البقية. بالرغم من أنني أستطيع فهم هذا القرار إلا أنه سيء جدًا من منظور "تجربة المستخدم". ليس هناك ما هو أكثر إحباطًا من التورط في التفكير بأنّك تتصفح موقعًا صديقًا للهاتف، فقط لتجد نفسك عالقًا في صفحة مُحسّنة لسطح المكتب لا يمكنك قراءتها أو تصفّحها. تحتاج هذه المنظمات إلى التفكير بتمعن ولفترة طويلة حول ما إذا كانت تحتاج لمثل هذه المواقع الكبيرة. من واقع خبرتي، نادرًا ما يقومون بذلك، ويقومون فقط بترحيل المحتوى بشكلٍ أعمى من إصدارٍ لآخر. هل قلصت وظائفية الموقع؟ يواجه المصممون مشكلة مماثلة عندما يصطدمون ببعض الوظائف الشاقة للموقع. شيء يبدو معقدًا جدًا لدرجة لا تمكّنه من صداقة الهواتف المحمولة ويكون التعامل مع الموقع على الهاتف شاقًا جدًا على المُستخدم. بدلًا من مضاعفة الجهود والتوصل لحل مُبتكر، نسهل الطريق الأقل صعوبة ومقاومة. نحن نقنع أنفسنا بأن مُستخدمي الهواتف لن يحتاجوا إلى هذه الوظائف وسيُزيلونها من الموقع. هذا بالطبع، أمرٌ ساذج بشكل لا يُصدّق. لا يختلف مُستخدمو الهواتف المحمولة بطريقة سحرية. هم نفس المُستخدمين الذين يستخدمون موقعك على "سطح المكتب Desktop". لقد بدّلوا الأجهزة فقط. لقد رأيتُ حتى أن الناس يستخدمون الهواتف المحمولة أثناء الجلوس في متناول اليد من أجهزة الحاسوب الخاصة بهم. لا يمكننا وضع افتراضات حول متطلباتهم بناءً على الجهاز. هل تؤيد إشارات اللمس؟ لا تتعلق الأخطاء الصديقة لأجهزة الهاتف فقط بإزالة الأشياء، يمكن أن يكون الفشل في إضافة شيء ما بنفس الخطورة. خذ على سبيل المثال "دعم إشارات اللمس". لا عجب أن كثيرًا من المُستخدمين يفضلون أحيانًا تطبيقات الأجهزة المحمولة عندما لا يُمكنهم التحرك والضغط على موقع إلكتروني على الهاتف. يجب حقًا على مصممي المواقع السماح للمستخدمين بتحريك الصور الدائرية والضغط عليها. فغالبًا ما يتم التغاضي عن هذا النوع من الوظائف لأننا نركز على تكييف التصميم لنقاط التوقف المختلفة. هل يتكيف المحتوى وكذلك التصميم؟ أن يكون الموقع صديقًا للهاتف المحمول، فهذا لا يعني تغيير التصميم فقط، إنّه يتعلق أيضًا بتغيير المحتوى نفسه. خذ "الجدول" على سبيل المثال. فقط لأننا نعرض البيانات كجدول بأحجام شاشات أكبر، فهذا لا يعني أن علينا أن نفعل ذلك على الهواتف أيضًا. قد نستنتج أن عرض "مخطط تفاعلي interactive chart" أو شكل من أشكال الآلة الحاسبة أكثر صداقة للهاتف "Mobile Friendly". نحتاج إلى تعديل المحتوى وليس فقط التصميم والجداول ومخططات المعلومات البيانية، إلى شيء يسهل التعامل معه على الهاتف ثم يأتي دور "الرسوم البيانية infographics"، التي تبدو رائعة على الشاشات الكبيرة لكنها تصبح غير قابلة للقراءة على أجهزة الهاتف. نستطيع بالتأكيد أن نسمح للمُستخدم بتكبير الشاشة وندّعي بذلك أننا قمنا بعملنا على أكمل وجه، أو يمكننا أن نعيد تخيلهم. ربما يجب علينا أن نُقسِّم هذه الرسوم البيانية إلى "لوحة رسوم Storyboard" أو نستخدم فيديو عوضًا عن ذلك. هل موقعك مقروءًا على الهاتف بقدر الإمكان؟ لا تقتصر مشاكل الوضوح فقط على الصور والجداول، إنما ينطبق الأمر بنفس القدر على النص. لن تُخلق تجربة ودية ومقروءة مع الهاتف بمجرد إضافة نقاط توقف إلى عناصر إعادة الموضع. انها غالبًا ما تُقصِّر أطوال الخطوط لدرجة تجعل القراءة صعبة للغاية. يبذل المصممون جهدًا في هذا الصدد بجعل حجم الخط يتناسب مع نقطة التوقف (breakpoint)، وبتقليص حجمه وفقًا لذلك. لكنني زرتُ العديد من المواقع على الأجهزة المحمولة حيث أصبحت أحجام الخطوط صغيرة جدًا مما يجعل النص غير مقروء. وأخيرًا، هناك قضية "اللون". غالبًا ما يفشل المصممون في أن يأخذوا بعين الاعتبار وهج الشاشة التي يعاني منها مستخدمو الهواتف المحمولة، ومن ثَمَّ يصنعون لوحات الألوان الدقيقة التي تُصعِّب تجربة القراءة على الهاتف وهذا على أقل تقدير. هل تركز بشكل كبير على أحدث وأفضل الهواتف الذكيّة؟ بالطبع، بعض مشاكل الوضوح هذه غير مرئية لنا حتى عند اختبارها على جهاز محمول. ذلك لأن لدينا أحدث وأكبر هاتف ذكي. إنه يحتوي على شاشة شبكية (retina screen)، ذات دقة عالية جدًا، وسطوع لا يمكن حتى للشمس أن تجاريها! ولكن ليس الجميع لديه أجهزة كهذه. حتى لو تجاهلت الهواتف المميزة كبندٍ للمقارنة، فقد تختلف التجارب بشكل كبير. ثم، بالطبع، هناك نقاط توقف. ما زلت أرى أن المصممين يقومون بتعيين نقاط التوقف استنادًا على الجهاز، بدلًا من المكان المناسب في المحتوى. لديهم تصميم بحجم iPad، وتصميم بحجم iPhone وما إلى ذلك. ولكن في الحقيقة، الأحجام متنوعة بشكل كبير، ونحتاج إلى التوقف عن التفكير في أجهزة معينة. هل أداؤك صديقًا للهاتف؟ الأداء هو ما يجب أن نفكر به. في الواقع، ربما تكون هذه هي المنطقة الأكبر الوحيدة حيث يخذلنا "التصميم المتجاوب". لا تسيئ فهمي أنا لا أقول أن "التصميم المتجاوب" يجعل مواقعنا أبطأ. إنه فقط لا يفعل شيئًا لتحسينه وهو شيء تحتاجه الأجهزة المحمولة. حجم الصورة بالتأكيد هو السبب. قد يؤدي استخدام "استعلامات الوسائط media queries" إلى تصغير الصورة بصريًا، لكنه لن يؤثر في تقليل حجم الصورة أو أوقات التحميل. هذا ليس جيدًا عند استخدام شبكة خلوية. أضف إلى ذلك الخطوط والمكتبات والأطر وجميع العناصر الأخرى التي تنتفخ في مواقع الويب الحالية ولديك أوقات تحميل سيئة. يمكن أن يؤدي اختبار أداء موقعك على الأجهزة المحمولة إلى قراءة محبطة! لكن هذه ليست مجرد مشكلة في حجم التنزيل وسرعة الشبكة الخلوية. الأداء هو مشكلة في الجهاز أيضًا. تفتقر العديد من الأجهزة المحمولة إلى قدرة معالجة أجهزة الحاسوب المحمولة أو أجهزة الحاسوب المكتبية أو الأجهزة اللوحية. والنتيجة هي أنها لا تستطيع التعامل مع قالب مُكثف من كود الجافاسكريبت "intensive javascript" موجود على العديد من المواقع الحديثة. هل ملء البيانات سهلًا على الهواتف؟ بعد ذلك، نأتي إلى مجموعة معينة من الأخطاء تحدث عندما نقوم بإدخال البيانات على الأجهزة المحمولة. فهل لك أن تتخيل كيف يمكن لأحد إدخال كم كبير من البيانات عبر لوحة مفاتيح هاتفه الصغير خلال فترة زمنية قصيرة؟ الأمر مريع حقًا، خصوصًا إن كان المستخدم مسنًا. كمصممي ويب، يبدو أننا نجعل المشكلة أسوأ بمئة مرة على مواقع الويب. عند إدخال بيانات رقمية، نفشل في عرض لوحة مفاتيح رقمية. عند إدخال كلمات المرور، نخفي ما يكتبه المستخدم، على الرغم من حقيقة أن الأخطاء المطبعية أمرًا شائعًا على الأجهزة المحمولة. في الواقع، لا ينبغي لنا أن نتوقع من مستخدمي الجوال ملء كلمات المرور على الإطلاق. هناك العديد من البدائل الأخرى مثل الإشعارات النصية أو روابط البريد الإلكتروني أو "معرف اللمس Touch ID". هناك العديد من المواقف التي يمكن فيها تجنب إدخال البيانات أو تبسيطها. سيكون تذكر اسم المستخدم لتسجيل الدخول بين الجلسات بداية جيدة. ولكن يجب علينا أيضًا تحسين تصميم النموذج وتجنب عناصر الأشكال المملوءة مثل منتقي التواريخ أو القوائم المنسدلة الطويلة. هل الروابط معبأة بإحكام أيضًا؟ عند الحديث عن التفاعلات المزعجة، أشعر بالدهشة إزاء قلة الاهتمام الذي يبديه المصممون للتحديات المحيطة باستخدام شاشة تعمل باللمس. أجد أن العديد من مواقع الويب التي تدّعي أنها صديقة للهاتف، ليست كذلك عندما تبدأ بالتفاعل معها. غالبًا ما يتم تجميع الارتباطات والأزرار معًا لزيادة حجم الشاشة إلى الحد الأقصى، بحيث يصبح من المستحيل النقر عليها. مرةً أخرى، مجرد تغيير موضع المحتوى لا يكفي. نحتاج إلى ضمان أن المساحة حول العناصر تتّسع للسماح بنقص الدقة الذي يحدث جرّاء استخدام الإصبع. من المسلَّم به أن المساحة هي ميزة استثنائية، ولكن إذا استخدمنا المساحة المتوفرة لدينا بحكمة، فلا يوجد سبب يمنع اختيار الروابط بسهولة أكبر. فقط إلقِ نظرة على متوسط التطبيق المحمول الخاص بك. هل يتعين على المستخدمين تحمُّل محتوى ثابت الموضع؟ بالحديث عن قلة المساحة، لماذا على الرغم من رغبة جميع المصممين في إنشاء موقع ويب سهل الاستخدام للهاتف المحمول، فإننا نعتبر أنه من المقبول إضافة محتوى موقع ثابت إلى الصفحة. هذا يقلل بشكل كبير من المساحة المتاحة لعناصر المحتوى الأخرى. فكر بتمعُّن قبل نقل تنقلاتك الثابتة إلى منظور موقعك الإليكتروني على الهاتف. بالمثل، قم بإبعاد تلك الطبقات ونوافذ الحوار، وكذلك رموز مواقع التواصل الاجتماعي الثابتة. ليس لديهم مكان على موقع إليكتروني على الهاتف. يكاد يكون من المستحيل قراءة المحتوى الموجود على Mashable على جهاز محمول نظرًا لحجم عناصر الموضع الثابت. ما المناسب لك؟ كلٌ من الخيارات الأربعة التي تمت مناقشتها في هذا المنشور له مكانه المناسب الذي سيختلف بناءً على الاحتياجات الخاصة بك. ومع ذلك، فإن نقطة الانطلاق الجيدة هي السؤال عمّا إذا كان المستخدمون يقومون في المقام الأول بإكمال مهمة أو الوصول إلى المعلومات. إذا كان الوصول إلى المعلومات هو الهدف، فمن المؤكّد أنّ المواقع المُتجاوبة هي الحل الأمثل. أمّا اذا كان "إكمال مهمة" هو الهدف، فعليك أن تسأل عمّا إذا كانت السرعة أم الوصول إلى الميزات الأصلية أيهما أهم. إذا كان الأمر كذلك، فستحتاج إلى تطبيق أصلي أو مُهجّن، وإلاّ سيكون تطبيق الويب مثاليًا. ترجمة -وبتصرف- للمقالين Is your site as mobile friendly as you think و Mobile app vs mobile website design: Your four options لصاحبهما Paul Boag

يشهد عالم البرمجة في عصرنا تطورًا هائلاً لا حدود له، إذ يُركز المطورين والمبرمجين على تحسين أداء الأعمال البرمجية من أنظمة، وبرامج، ومواقع وغيرها، وراحة المستخدم في التعامل معها، ومن أهم وأبرز عناصر وأركان هذا التطور سرعة استجابتها وأدائها. لاحظ الفرق في الصورة السابقة بين الحالتين، إذ تجد إحداها أسرع في العرض عند طلبها من الأخرى، والسبب في ذلك تطبيق تقنية prefetching فيها. تكمن تقنية prefetching (الجلب أو الاحضار المسبق) في تجهيز وتحميل الملف أو مجموعة الملفات قبل البدء بفتحها واستخدامها، وهي معروفة في كثير من مجالات البرمجة، حيث تستخدم في المعالجات لتسريع جلب البيانات والتعليمات قبل الحاجة لها، وفي ذاكرة DDR SDRAM، وفي أنظمة تشغيل الحاسوب، وفي المواقع الإلكترونية وهي من أبرز تطبيقاتها. سيكون الحديث هنا مقيدًا في مجال المواقع. المقصود من prefetching في مجال المواقع: تنقل أسرع بين صفحات الموقع من خلال تحميل الصفحات أو جزء منها قبل الشروع باستخدامها، أي بكل بساطة نخبر المتصفح بجلب الموارد قبل فتحها، وعند طلب المستخدم فتح الصفحة فإنها تُعرض مباشرةً كونها جاهزة للعرض كما ظهر في الصورة السابقة. كيفية إضافة هذه تقنية والاستفادة منها يستفاد من هذه تقنية في تسريع عرض صفحات الموقع أو جزءٍ منها كملفات JavaScript أو ملفات CSS (من أبرزها الخطوط حيث يتم عرض الخطوط من دون انتظار تحميل DOM و CSSOM)، أو الوسائط (صور ومقاطع مرئية وصوتية)، أو المستندات. يمكن إضافتها بعدة طرق، الأكثر شيوعًا باستخدام الوسم link في لغة HTML، وذلك بإدراجه في الصفحة السابقة للمراد تطبيق تقنية فيها، وفيه rel من نوع prefetching كما يلي: <link rel="prefetch" href="URL"> يوضع مكان URL رابط الملف المراد تحميله سابقًا وتجهيزه للعرض مباشرةً عند طلب المستخدم فتحه. نظرة أعمق لآلية عمل prefetching عند اكتمال تحميل الصفحة التي تحوي الوسم link من النوع prefetching (للمراد تطبيق تقنية الجلب المسبق فيها)، يرسل طلب تحميل الملف (المطبق عليه تقنية) بواسطة ترويسة HTTP التالية: Link: </js/chat-widget.js>; rel=prefetch بعدئذٍ يتم تحميل الملف وتخزينه في ذاكرة المتصفح المؤقتة، ومن المهم معرفته أنها تأخذ أقل أولوية بالتحميل (priority:lowest)، ويتم حفظها مدة لا تتجاوز الخمسة دقائق، خلال هذه المدة تكون جاهزة للعرض وما إن يقوم المستخدم بطلب فتح الصفحة تظهر مباشرةً، وتنتقل إلى إعدادات وقواعد cache-control الافتراضية لأي صفحة عادية، وإن لم يفعل وانتهت المدة يتم حذفها وتفقد هذه تقنية. تحديد الصفحة الأنسب والأولى بالتحميل المسبق تضاف هذه التقنية إلى الصفحات التي تملك الاحتمال الأكبر من انتقال المستخدم إليها، على سبيل المثال عند فتح موقع في صفحته الرئيسية يمكن للمستخدم أن ينتقل إلى 20 صفحة ثانوية، ولكن إحدى هذه الصفحات هي الأهم وأغلب المستخدمين ينتقلون إليها مباشرة عند فتح الموقع. ويتم إضافة تقنية إلى الصفحة التي من المؤكد انتقال المستخدم إليها كخطوة تالية، على سبيل المثال عند دخول إلى موقع تظهر في البداية صفحة إدخال بيانات شخصية وعند إتمام ذلك يتم الانتقال إلى الصفحة الرئيسية. وهذا يتطلب معرفة جيدة لوظيفة الموقع وطريقة استخدامه من قبل الزائرين، ومعرفة الصفحات الأكثر زيارة، ومما يساعد على ذلك الأداة Next Page Predictor فهي أداة تقترح الصفحة التالية التي تناسب تطبيق التقنية عليها. ولكن عند التعمق والتشعب أكثر في الموقع تصبح عملية اختيار الصفحة المناسبة لذلك أكثر صعوبة، ولكن من الممكن باستخدام بيانات إضافية التنبؤ بالصفحة الأنسب لإضافة التقنية، فعند فتح أي رابط URL من الموقع تحديد الصفحة التالية الأنسب لذلك وإضافة لها الوسم <link rel="prefetch" href="URL"‎>، مما يضفي لمسة تقنية أفضل أداءً للموقع كامل، ويمكن التعديل على الاختيارات يدويًا، وهذا ما تقدمه مكتبة Guess المعدة من قبل فريق تابع لجوجل، والتي تستند في نتائجها على استخدام الموقع (عدد الدخولات على الصفحات، وتحليلات جوجل) وعلى التعلم الآلي (Machine Learning) والتنبؤ بالصفحات التالية ذات الصلة بالحالية، وتقوم أيضًا بتجميع مصادر JavaScript المتوفرة بالصفحة الحالية والتي تلزم ببناء الصفحة التالية. توخي الحذر عند استخدام prefetching قد لا يتم الاستفادة من البيانات المحملة مسبقًا، بسبب عدم استخدامها وفتحها أو لانتهاء مدة تخزينها المؤقت أو غيرها من الأسباب، مما يتسبب بسحب وتبديد لبيانات الإنترنت من دون فائدة، وهذا قد يؤثر تأثير كبير على بعض المستخدمين الذين يملكون بيانات محدودة وشحيحة متاحة للسحب من الانترنت. يمكن التخفيف من هذه المشكلة بمعرفة نوع الشبكة بواسطة لغة JavaScript مع navigator.connection.effectiveType، حيث يقوم بإعطاء نوع الشبكة، فمثلا إن كانت الشبكة 4G على الأقل يتم تطبيق التقنية. ومن المشاكل التي قد ترتبط بهذه التقنية، طلب المستخدم فتح الصفحة قبل اكتمال الجلب المسبق لها، فذلك يؤدي إلى حذفها وإعادة تحميلها من جديد، لذا يفضل أن يحرص المبرمج على عرض جزء منها للمستخدم قبل حذفها. وعلى المبرمج أن يتنبه إلى أن التخزين المؤقت للملفات المالكة لهذه التقنية محدود، لذا يفضل عدم إدراج التقنية إلى ملفات كبيرة الحجم، بل إنه قد يعطي الخطأ: Failed to load resource: net::ERR_CACHE_WRITE_FAILURE وذلك لأن حجم الملف المطلوب جلبه مسبقًا كبير بشكل لا يمكن تخزينه في ذاكرة المتصفح المؤقتة. أمثلة عملية الموقع الياباني Nikkei: عندما وثقوا بانتقال المستخدمين إلى صفحات معينة، لم يتركوا المستخدم ينتظر تحميل الصفحة عند طلبها، بل قاموا بإدراج تقنية prefetching إلى تلك الصفحات مما أدى إلى تخفيض الوقت الكلي لعملية الانتقال إلى الصفحات من 880 ملي ثانية إلى 37، أي تخفيضها بنسبة 96% وهو فرق شاسع. شركة Netflix إذ قامت باستثمار هذه التقنية بتسهيل التنقلات إلى الصفحات. موقع Craigslist استفاد من هذه التقنية في تسهيل الوصول إلى صفحات نتائج البحث. موقع IndieGogo استفاد من هذه التقنية في تسهيل التعامل مع صفحات بطاقات الائتمان قبل الدخول إليها. المتصفحات التي تدعم هذه التقنية في ما يلي شكلٌ توضيحي من CanIUse للإصدارات التي تتيح تطبيق تقنية prefetching (الإصدار المظلل باللون الأخضر يدعم تقنية prefetching، والإصدار المظلل باللون الأحمر لا يدعمها): مراجع Speed up next-page navigations with prefetching Prefetching wikipedia Speeding up your website using Prefetching techniques Faster Page-Loads by Prefetching Links During Idle Time Prefetching, preloading, prebrowsing Prefetch W3C ‎<link rel="prefetch/preload"> in webpack Can I use prefetch‎?‎ Nikkei achieves a new level of quality and performance with their multi-page PWA Guess.js announcement

في سعينا المستمرّ لإنشاء مواقع خفيفة قدر الإمكان، تلعب تحسين الصور دورًا مهمًا. إن الصور الرديئة من ناحية الحجم لا تزيد وقت تحميل الصفحة وحسب، بل تستهلك سعة الإنترنت من جهة المستخدمين والشبكات على حد سواء. والأكثر تأثرًا بذلك هي المواقع الأكبر ذات العدد الضخم من الصور. يعرفك المقال بأهم 10 تطبيقات وأدوات مجانية، التي يمكنك الاستعانة بها على تقليل حجم الصور، وبذلك تتجنب زيادة وقت التحميل لموقعك، وتجنب المستخدمين الاستهلاك الزائد لباقات الانترنت. TinyPNG TinyPNG هو موقع لضغط الصور وتقليل حجمها، يساعدك على تقليل حجم ملفات PNG و JPG الخاصة بك مع أقل قدر ممكن من الإخلال بالجودة. وتعد هذه الخدمة مميزة بصورة خاصة في تقليل حجم ملفات PNG الشفافة المعقدة بشكل ملحوظ. ImageOptim ImageOptim هو تطبيق مجاني مفتوح المصدر لنظام التشغيل MacOS يقوم بتحسين الصور مع حذف معلومات التعريف غير الضرورية أيضًا. لإزالة التعريف فائدة أخرى، وهي حماية خصوصيتك. كما يوجد أيضًا وضع التصغير الفقود الذي يقلص حجم صور PNG و GIF و JPG و SVG تقليصًا كبيرًا - بما في ذلك صور PNG و GIF المتحركة. gulp-image إذا كنت تستخدم برنامج تشغيل المهام Gulp، فسيعمل gulp-image تلقائيًا على تحسين صور GIF و JPEG و PNG و SVG من خلال سكربت. إنه خيار رائع لمن لديهم الكثير من الصور التي تحتاج إلى معالجة. تفضل استخدام Grunt؟ سيؤدي grunt-image المهمة بكفاءة. Pngcrush Pngcrush هو برنامج لواجهة الأوامر النصيّة يمكن تشغيله على كل من MSDOS و Linux. يفحص البرنامج ملفات PNG الخاصة بك ويجرب مستويات الضغط المختلفة وطرق التصفية لتقليل حجم الملف. APNG Assembler استخدم APNG Assembler لإنشاء ملفات PNG متحركة عالية التحسين. يتضمن هذا التطبيق المستقل إصدارات لكل من Windows و MacOS و Linux. Compressor.io Compressor.io هي خدمة مجانية عبر الإنترنت تعمل على تحسين ملفات GIF و JPG و PNG و SVG. يمكنك الاختيار من بين أنواع الضغط غير المفقودة أو المفقودة. Simple Image Optimizer تستطيع مع Simple Image Optimizer تحسين الصور وتغيير حجمها عن طريق واجهة إنترنت بسيطة. كما توجد خيارات منفصلة لتغيير حجم الصور أو تحويلها. إضافة ووردبريس Smush Smush هو إضافة ووردبريس يمكنها تحسين صور موقعك تلقائيًا وتغيير حجمها أثناء تحميلها. يمكنك أيضًا تحسين نحو 50 صورة دفعة واحدة. إنه حل مفيد للغاية لضمان تحسين الصور دون الحاجة إلى بذل أي جهد. إضافة دروبال Image Optimize Image Optimize عبارة عن إضافة لمواقع Drupal تستخدم نصوص تحسين الصور الموجودة على خادم الويب الخاص بك، مثل OptiPNG أو jpeglib. تتكامل الوحدة أيضًا مع بعض خدمات التحسين من قبل طرف ثالث. إضافة ماجنتو Apptrian Image Optimizer يعد Apptrian Image Optimizer إضافة لماجنتو يستخدم الضغط بدون فقد لتحسين ملفات GIF و PNG و JPG. يستطيع معالجة الصور دفعة واحدة، وإعداد مهمة cron لمسح التحميلات الجديدة وتهيئتها بشكل دوري. توفير الوقت والمساحة من أهم مميزات أدوات تحسين الصور المجانية التي استعرضناها هي التنوع في الخيارات المتاحة. فهناك حلول للمستخدم الخبير الذي يريد أن يتحكم بدقة كبيرة، وهناك خيارات بسيطة لا تحتاج إلى أي مهارة من المستخدم. ومع إدارة الصورة المجمعة، يمكنك تحسين مكتبة الصور الخاصة بك كلها بسرعة وسهولة. إن تحسين الصور تحدث فارقًا كبيرً. إذا ما أمضيت بعض الوقت في ضبط حجم الصور الخاصة بك، سيكون مستخدمي موقعك سعداء بذلك، وسيجدون توفيرًا في باقات الإنترنت الخاصة بهم. مترجم بتصرف عن ‎10 Free Tools and Apps for Optimizing Images لصاحبه Eric Karkovack

أصبحت الفترة التي تزامنت مع ظهور الوسائل والطرق الجديدة التي يحاول المطورون استخدامها لإقناع الزائرين بالصور المتخصصة والمحتوى الديناميكي وإضافة الفيديو فترةً مهمة لتحميل صفحة الموقع ومصدر قلق دائم لمطوري الويب، خاصةً تلك الوسائط التي تحتاج وقت كبير في التحميل. وقد يظهر هذا القلق واضحًا عند إضافة أي محتوى جديد على اختلاف نوعه إلى صفحة الموقع، وهنا يتطلب من الموقع الخاص بك إنشاء طلبيات HTTPS (بروتوكول نقل النص التشعبي الآمن) إضافية تعمل بدورها على إبطاء موقعك بشكل تدريجي. سوف أتحدث في هذا المقال عن طلبيات خادم HTTPS، وعن ماهية الأدوات التي يجب استخدامها لتتبع هذه الطلبيات وأيضًا سوف أوضح الطرق التي يمكنك بها تقليص تلك الطلبيات داخل موقع ووردبريس الخاص بك. ما هي طلبيات خادم HTTPs وهل لها تأثير على تجربة المستخدم؟ بالطبع لا توجد هناك أهمية أكبر من أهمية تجربة المستخدم التي تعمل على جذب الزوار للموقع والاشتراك فيه أو شراء منتجاتك، أو التعرف على المزيد من المعلومات حول خدماتك. فهنا يظهر واضحًا جدًا أن أي خطأ بسيط يمكن أن يعرّض هذه التجربة للخطر فمثلًا لو كان لديك صفحة ويب تستغرق بضع ثوانٍ قليلة للتحميل، فهذا وحده كافٍ أن يعرّض معدل التحويل لديك للخطر. لذا ولتجنب ذلك، عليك التعرف على هذه المعلومات حول طلبيات خادم HTTPS ولماذا تحدث. ففي كل مرة يزور شخص ما موقع الويب الخاص بك أو إحدى صفحاته (وركّز هنا في عدد الصفحات الموجودة على موقعك)، إذ يقدّم متصفحه طلبًا إلى خادم موقع الويب الخاص بك وهذا يتكرر مع كل صفحة يقوم بزيارتها. وهنا تكمن مسؤولية موقع الويب الخاص بك في إرسال كل ملف بما يحتوي عليه (النصوص والصور التي عادة ما يشتمل عليها أغلب المواقع بالإضافة إلى الفيديو، وملفات CSS، وملفات جافاسكربت، …إلخ) ويتلقى كل ملف من تلك الملفات طلب خادم منفصل. وبعد أن تعالج جميع طلبيات الخادم وتنقل الملفات إلى المتصفح، يمكن تحميل موقع الويب الخاص بك على الشاشة، ولكن تخيل ماذا سوف يحدث إذا كان موقع Wordpress الخاص بك يحتوي على عشرات أو حتى مئات الملفات لإرسالها إلى متصفحات من يزوره؟ توقع فعليًا زمن تحميل الصفحات، بالطبع هذا شيء غير مستحب إن كان الزمن كبيرًا! وقد يزداد الأمر سوءًا بشكل كبير مع تزايد شعبية الموقع وتلقي طلبيات خادم HTTPS كثيرة في وقت واحد. مثال على ذلك: 40٪ من الناس لا يتحملون الانتظار وقد يفقدون صبرهم إذا كان عليهم الانتظار أكثر من ثلاث ثوان لتحميل الصفحة. و قد أشارت دراسة كيس ماتريكس إلى أن التأخير لمدة ثانية واحدة في استجابة الصفحة عندما يتفاعل الزائر معها قد يكلف ما يصل إلى 7٪ من التحويلات؛ لذا، تحتاج إلى العثور على طريقة لتقليص عدد الملفات التي يجب إرسالها إلى المتصفح إذا كنت تريد أن تظل أوقات التحميل هذه مقبولة. فمن غير المعقول أن يكون الحل هو تقليل عدد الصور أو المحتوى الديناميكي أو الانتقال إلى الحد الأدنى من التصميم الخاص بك بحيث تخسر بذلك ميزة العرض الخاصة بموقعك و يصبح الأمر مملًا للغاية. بالرغم من أهمية حجم وكمية الملفات، إلا أنه يتوفر هناك العديد من الطرق في ووردبريس للتغلب على ذلك. الأدوات الخاصة بتتبع طلبيات خادم HTTPS وما يتعلق به من حسن الحظ أن هناك عدد من الأدوات تساعدك في تخطي عقبة تخمين السبب وراء ظهور شاشة الموت البيضاء لدى زوار موقعك ومعرفة ما يسبب ذلك. وتعمل أيضًا على تتبع مصدر التأخر في أوقات تحميل موقعك. أعرض هنا إليك بعض الأدوات المجانية والموثوقة. أدوات التطوير في كروم إذا كنت تريد رؤية دقيقة ومتعمقة في المتصفح كروم للمدة التي يستغرقها كل عنصر وملف يعالج على موقع ووردبريس الخاص بك. ابدأ أولًا بفتح نافذة متصفح جوجل ثم انتقل إلى صفحة الإعدادات التي تسمى أدوات المطور (Developer Tools) كما يظهر في الصورة. ستفتح عند الضغط عليها لوحة تحكم جديدة على الجانب الأيمن من الشاشة. حينئذ اضغط فوق علامة التبويب Network "الشبكة"، ومن هنا ستتمكن من معرفة الإجراءات التي تحدث في صفحتك. وستتمكن أيضًا من البحث بحثًا دقيقًا في توقيت كل ملف على حدة للتأكد لمعرفة أيها قد يكون سببًا في زيادة الضغط (الحمل) على صفحتك. أداة PageSpeed Insights لتحليل الأداء والسرعة من غوغل هذه الأداة ليست الوحيدة بالطبع التي تقدمها جوجل لمساعدتك في اكتشاف المشكلات المتعلقة بطلبيات خادم HTTPS من الناحية المثالية، فإذا كنت من مستخدمي أدوات التطوير فمن الواجب عليك الاستفادة من الأداة PageSpeed Insights التي يجب أن تكون ضمن قائمتك. تحلل PageSpeed إحصاءات محتوى صفحة الويب ثم تقدم اقتراحات لتحسين سرعة تلك الصفحة. انتقل إلى صفحة PageSpeed Insights وضع رابط الصفحة التي تريد تحليلها وسوف تقدم لك نتائج تفصيلية تقيّم فيها أداء الصفحة على الجوال وكذلك على سطح المكتب. يقدم لك كل تقييم من هذه التقييمات درجة من 100 تبين مدى جودة الأداء ومن ثم يقدم لك نصائح حول كيفية تحسين موقعك لتحسين الأداء. أداة GTmetrix أداة GTmetrix هي أداة تقييم واختبار سرعة الموقع وستوفر لك درجة تقيِّم موقع الويب الخاص بك. وتتميز أداة GTmetrix أنها تتعامل في عملية شرح أداء موقعك بطريقة أكثر شمولًا وثقة من جوجل لذلك، بالرغم من ظهور العلامات الحمراء و الصفراء (وهي ليست جيدة)، إلا أنه يمكنك التمرير فوق كل نقطة من نقاط البيانات ومعرفة متوسط الدرجات وأوقات التحميل. وهذا سيعطي فكرة أكثر واقعية حول مستوى أداء صفحات موقعك. عند تقييمك من GTmatrix، تتلقى نصائح قياسية حول كيفية تحسين السرعة والأداء لصفحتك. كل تلميح يظهر بجانبه الدرجة المطابقة، وهذا يتيح لك معرفة المكان الذي أنجزت فيه الأمور بشكل جيد، وتعطي مقترحات للتحسين. وإذا كنت تريد المزيد من المساعدة في تلك المناطق الأضعف، فما عليك سوى النقر على السهم المتجه للأسفل وسيخبرك بالملفات التي يمكن أن تستخدم بعض الأعمال. أداة Pingdom الأداة Pingdom تتشابه إلى حد كبير مع أداة GTmetrix في عملها و كيفية تقديم المعلومات. وقد تجد أن الاختلاف الرئيسي بين الأداتين هو في السرعة التي توفر بها نتائجها وأيضًا الواجهة هذه أجمل قليلًا. و لكن من ناحية أخرى، ستتلقى نفس التقييم الدقيق تقريبًا من كلا الأداتين وهذا هو بالضبط ما تحتاجه إذا كنت تحاول توفير الوقت في تقييم مشاكل موقعك وتريد تضييق نطاق ما لا يعمل. الأداة WebPageTest لن يمر ذكر أدوات اختبار صفحات الويب دون ذكر الأداة WebPageTest هنا. مع أن الموقع قليل الشكوك والنتائج ليست سهلة القراءة مثل بعض الأدوات الأخرى، إلا أنني أحب الرسم البياني الشريطي المستخدم لعرض المدة التي يستغرقها كل ملف للتحميل. رغم أنه قد يكون هناك قدر هائل من البيانات في هذه الصفحة ولا توجد نصائح حول كيفية حل مشكلات التباطؤ المحددة، ما زلت أعتقد أن طريقة عرض العناصر الأثقل جيدة نوعًا ما. يمكنك دائمًا استخدام هذا بالاقتران مع أدوات المُطوِّر لتضييق نطاق العناصر ذات الإشكالية في موقعك. كيفية تقليل عدد طلبيات خادم HTTPS لموقع وورد الخاص بك وبعد أن تعرفت على كيفية تحديد المناطق المسببة لضعف أداء موقع الويب الخاص بك، دعنا نتحدث عن كيفية حل المشكلة كاملة من بدايتها وهي تقليل عدد طلبيات خادم HTTPS لموقع ووردبريس الخاص بك. أقدم إليك 9 خطوات يمكنك القيام بها وبذلك تحتفظ على عدد معقول من الطلبيات في موقعك. 1) حذف الصور غير الضرورية هذا ليس معناه أنه يتوجب عليك التضحية بالصور من أجل خفض طلبيات الخادم ولكن بدلًا من ذلك، أعتقد أنه يجب عليك التركيز والحفاظ على مكتبة الوسائط الخاصة بموقعك خالية من أي صور لا ضرورة لها أبدًا. لذا، إذا كانت هناك صور لا تستخدمها أو حتى لو كنت تفكر في استخدامها في المستقبل فيمكنك التخلص منها. في النهاية لن تضيف شيئًا لموقعك سوى إضافة وزن إضافي وطلبيات للخادم وموقعك ليس بحاجة إليها. 2) حذف الملفات الأخرى غير الضرورية وقد تُظهر لك أدوات تقييم سرعة صفحتك التي ذكرتها أن الصور ليست هي التي تسبب المشكلة، وتتفاجأ أن هناك إضافة لتغذية الوسائط الاجتماعية أو وجود فيديو مدمج في الصفحة. فأنصحك أنه إذا كان هناك أي شيء على موقعك ليس ضروريًا ويتسبب في الضغط، فقم بإلغائه. اشمل على ذلك الإضافات والقوالب التي قمت بتثبيتها، ولكن التي لا تستخدمها في الوقت الحالي. 3) ضغط وتقليص حجم الملف من الأشياء الأخرى التي يتوجب عليك فعلها هو تثبيت إضافة تدعى WP Smush التي تتولى عملية ضغط صور موقعك. فإذا كنت ترغب في الحفاظ على صور موقعك الجميلة وذات الدقة عالية على موقعك بجودة سليمة تحتاج إلى ضغطه. 4) إنشاء عفريت صور CSS باستخدام CSS، يمكنك إنشاء ما يعرف باسم عفاريت الصورة (Image Sprite وهي تقنية تقوم على مبدأ استعمال صورة واحدة تحتوي على مجموعة من الخلفيات واستعمالها في جميع أزرار الموقع ويرجع الهدف من استعمال هذه التقنية إلى تسريع تحميل الموقع والتقليل من استخدام موارد استضافة الموقع). فعليًا سوف يجمع ملف CSS هذا جميع ملفات الصور الخاصة بك ويضعها في ملف واحد. استعن بهذا الدليل من W3 Schools لإنشاء عفريت. 5) فعّل خاصية التحميل الكسول هل سمعت عن التحميل الكسول (lazy loading)؟ ربما تسمع به لأول مرة، وسأقرب لك فكرة عمله. هنالك إضافات خاصة ترسل طلبيات للخادم عندما يقوم المستخدم بالتمرير لأسفل إلى صورة على الصفحة، وهذا الإجراء يحفظ موقع الويب الخاص بك ويقلل من الاضطرار إلى إرسال طلبيات الخادم غير الضرورية إلى المتصفح التي لم يسبق لزوارك الوصول إليها من قبل. 6) تجاهل الأصول غير ذات الصلة عملية التجاهل هذه تقوم بها إضافة تسمى WP Asset Cleanup وهي خاصة بووردبريس وتعمل بشكل مشابه لكيفية عمل إضافات التحميل الكسول. فبدلًا من التركيز على تأخير طلبيات الخادم للصور التي لم تتم مشاهدتها، تستكشف هذه الإضافة ما إذا كان هناك إضافة أو ملف أو مادة عرض أخرى موجودة داخل القالب الخاص بك، ولكن ليس على تلك الصفحة المحددة وبعد ذلك تحفظ هذا الأصل من أن يتم تحميله والكشف عنه في تلك الصفحة. وبالتالي، يصبح هناك تقليل لعدد طلبيات الخادم التي تذهب إلى المتصفحات. 7) استخدام الإضافة Hummingbird استعمال إضافة التخزين المؤقت (caching) أمرًا ضروريًا لمواقع ووردبريس، وخصوصًا تكمن أهميته عندما يكون موقع ووردبريس الخاص بك يتعامل مع زوار دائمين للموقع. وبذلك ليست هناك حاجة فعلاً لمعالجة طلبيات الخادم نفسها إذا لم يتغير شيء، وبالتالي فإن إضافة التخزين المؤقت تعمل على ذلك وتزيل كل ما ليس له حاجة. ومن الإضافات المهمة في ووردبريس إضافة Hummingbird التي تؤدي دورها بشكل مثالي مع إدارة التخزين المؤقت للمتصفح، فهي تعتني أيضًا بضغط الملفات، وملفات CSS، وملفات JavaScript وتصغير ملفات html، كما يضيف CDN (أي اختصار شبكة توصيل المحتوى وهي عبارة عن مجموعة من الخوادم الموزعة بكل أنحاء العالم تعمل على إيصال المحتوى الثابت لمواقع الويب إلى المستخدمين حسب موقعهم الجغرافي بأقرب وقت وأقصر مسافة) وتعمل إضافة CDN على تسريع الأمور بشكل أكبر ومنح إمكانية الوصول إلى تقارير الأداء في حالة عدم رغبتك في استخدام أحد العناصر الثلاثة أعلاه لتقييم حالة سرعة موقعك. 8) دمج ملفات الجافا سكريبت و ال سي اس اس تحتوي مواقع ووردبريس على العديد من ملفات CSS وJavaScript فبدلًا من إرسال كل ملف كطلب خادم منفصل إلى متصفحات الزوار، يمكن دمجهم في ملف واحد منفرد لكل نوع. ضع باعتبارك أن ملف CSS المدمج الخاص بك يجب أن يكون داخل رأس موقع الويب الخاص بك، وملف جافاسكربت في التذييل. 9) الحد من الصور الخارجية يظهر هذا واضحًا وأكثر شيوعًا عند تعليقات المدونة. هل تعلم أنه إذا تركت نظام التعليق الافتراضي الخاص بووردبريس في مكانه فإنه سوف يستخدم تلقائيًا Gravatar (صورة تشخيصية ثابتة وهي عبارة عن خاصية أوتوماتيكية لسحب صور المعلقين وسيرهم) وبذلك تصبح هذه الصور طلبيات خادم إضافية يتعين عليك إرسالها إلى كل المتصفحات، فماذا لو كانت المدونة معروفة ومشهورة بالطبع سوف تصبح هناك فوضى. ولكن في ووردبريس يوجد هناك بعض الإضافات الخاصة بالتعليقات وتعمل على تجنب هذه المشكلة. الخلاصة أخيرًا مما يميز تطوير مواقع ووردبريس أن هناك الكثير من الأشياء التي تستطيع القيام بها داخل الموقع و تحسين أداءه، ولكن أحيانًا نغفل كيف يمكن لموقعنا الخاص بما يحتويه من قوالب وإضافات وصور رائعة تبرز جماله أنها قد تكون بشكل مفرط يفوق الحد في نظر المستعرض الذي يحاول ببساطة معالجة الموقع بالكامل. ومع ذلك، في وورد بريس عليك أن لا تخف أبدًا، فإذا استخدمت أداة مراقبة السرعة للصفحة وتابعت عليها دومًا وأيضًا التزمت بنصائح الحد من طلبيات الخادم التسعة التي ذكرتها في الأعلى، أعتقد أنك بذلك سوف تجعل أداء موقعك جيدًا. ترجمة -وبتصرف- للمقال How to Reduce HTTP/S Requests in WordPress لصاحبته Brenda Barron