المعلومات التي يحتاج المطوّرون إلى معرفتها حول وضعَي "الذاكرة" و"توفير الطاقة" في Chrome

طرَح Chrome 108 وضعَين جديدَين، وهما توفير الذاكرة وميزة "توفير البطارية" لمنح المستخدمين المزيد من التحكّم في كيفية استخدام Chrome لموارد النظام.

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

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

وضع "توفير الذاكرة"

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

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

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

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

وبدءًا من الإصدار 108 من Chrome، سيصبح تجاهل علامات التبويب أكثر شيوعًا، لذلك من الضروري أن تتمكّن المواقع الإلكترونية من التعامل مع هذه الحالات بسلاسة.

أفضل الممارسات للتعامل مع عمليات تجاهل علامات التبويب

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

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

أفضل أوقات لتخزين حالة المستخدِم هي:

  • بشكل دوري مع تغيير الحالة.
  • كلما تم استخدام علامة تبويب في الخلفية (الحدث visibilitychange).

في ما يلي أسوء الأوقات لتخزين الحالة:

  • في معاودة الاتصال بحدث beforeunload.
  • في معاودة الاتصال بحدث unload.

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

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

حالة وتدفق الأحداث في Page Lifecycle API تمثيل مرئي لتدفق الحالة والحدث موصوف في هذا المستند.

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

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

let state = {};
let hasUnstoredState = false;

function storeState() {
  if (hasUnstoredState) {
    // Store `state` to localStorage or IndexedDB...
  }
  hasUnstoredState = false;
}

export function updateState(newState) {
  state = newState;
  hasUnstoredState = true;
  requestIdleCallback(storeState);
}

document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') {
    storeState();
  }
});

اكتشاف أنه تم تجاهل علامة تبويب

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

if (document.wasDiscarded) {
  // The page was reloaded after a discard.
} else {
  // The page was not reloaded after a discard.
}

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

على سبيل المثال، في "إحصاءات Google"، يمكنك ضبط مَعلمة حدث مخصّصة تسمح لك بتحديد النسبة المئوية لمرات مشاهدة الصفحة على الويب الواردة من عمليات تجاهل علامات التبويب:

gtag('config', 'G-XXXXXXXXXX', {
  was_discarded: document.wasDiscarded,
});

إذا كنت مزوِّدًا للإحصاءات، ننصحك بإضافة هذه السمة إلى منتجك بشكلٍ تلقائي.

اختبار موقعك الإلكتروني في وضع "توفير الذاكرة"

يمكنك اختبار الطريقة التي يتم بها تجاهل الصفحة من خلال تحميل الصفحة ثم الانتقال إلى chrome://discards في علامة تبويب أو نافذة منفصلة.

من واجهة مستخدم chrome://discards، يمكنك تحديد علامة التبويب التي تريد تجاهلها من القائمة، ثم النقر على التجاهل العاجل من عمود الإجراءات.

لقطة شاشة لواجهة مستخدم chrome://discards تعرض موقع الرابط المؤدي إلى تجاهل علامات التبويب

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

تجدر الإشارة إلى عدم توفُّر طريقة حاليًا لأتمتة عمليات تجاهل علامات التبويب من خلال أدوات الاختبار مثل webdriver أو puppeteer. ومع ذلك، ونظرًا لأن عمليات تجاهل علامات التبويب واستعادتها مماثلة تقريبًا لعمليات إعادة تحميل الصفحات، إذا اختبرت استعادة حالة المستخدم بعد إعادة التحميل في منتصف مسار المستخدم، فستعمل على الأرجح مع عمليات التجاهل أو الاستعادة أيضًا. الفرق الأساسي بين الأحداث هو beforeunload وpagehide وunload، بحيث لا يتم تنشيطها عند تجاهل علامة تبويب. ما دمت لا تعتمد على هذه الأحداث للحفاظ على حالة المستخدم، يمكنك استخدام عمليات إعادة التحميل لاختبار سلوك التجاهل/الاستعادة.

وضع "توفير البطارية"

عند تفعيل وضع "توفير البطارية"، يحافظ Chrome على طاقة البطارية عن طريق تقليل معدّل تحديث الشاشة، ما يؤثر في دقّة الصور المتحركة ودقتها وعدد لقطات الفيديو.

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

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

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

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

جارٍ قياس معدّل تحديث الشاشة

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

إنّ أفضل ما يمكن للمطوّرين الاستفادة منه باستخدام واجهات برمجة التطبيقات الحالية هو مقارنة الطوابع الزمنية بين استدعاءات requestAnimationFrame() المتتالية. على الرغم من أنّ هذا الخيار يعمل في معظم الحالات على تقريب معدّل التحديث في وقت معيّن، لا يُعلِمك عند تغيُّر معدّل التحديث. لإجراء ذلك، عليك إجراء استطلاع باستخدام requestAnimationFrame() باستمرار، ما سيؤدي إلى إلغاء هدف الحفاظ على الطاقة أو عمر البطارية للمستخدمين.

اختبار موقعك الإلكتروني في وضع "توفير البطارية"

يمكنك اختبار موقعك الإلكتروني في وضع "توفير البطارية" من خلال تفعيل هذا الوضع في إعدادات Chrome وضبطه ليعمل عندما يكون جهازك غير متصل بمصدر طاقة.

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

  1. تفعيل العلامة chrome://flags/#battery-saver-mode-available
  2. انتقِل إلى chrome://discards وانقر على رابط إيقاف/تفعيل وضع توفير شحن البطارية (ملاحظة مهمة: يجب تفعيل علامة #battery-saver-mode-available حتى يعمل الرابط).

لقطة شاشة لواجهة مستخدم chrome://discards تعرض موقع الرابط لتفعيل وضع "توفير البطارية"

وبعد تفعيلها، يمكنك التفاعل مع موقعك الإلكتروني والتأكّد من أنّ كل شيء يظهر كما يجب: على سبيل المثال، تعمل الرسوم المتحركة والانتقالات بالسرعة المطلوبة.

ملخّص

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

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

ومع ذلك، إذا كان موقعك الإلكتروني يحتوي على أيٍّ من الممارسات الموضّحة في هذه المشاركة، يُحتمل أن يواجه المستخدمون مشاكل لن تزداد إلا عند تفعيل هذين الوضعَين.

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