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

Philip Walton

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

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

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

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

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

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

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

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

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

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

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

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

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

• دوريًا مع تغيّر الحالة
• عند ظهور علامة تبويب في الخلفية (حدث visibilitychange)

أسوأ أوقات لحالة التخزين هي:

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

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

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

في الواقع، عندما تكون الصفحة في حالة "مخفية"، ليس هناك ما يضمن تنشيط أي أحداث أخرى قبل أن يتجاهل المتصفّح تلك الصفحة أو يُنهيها المستخدم، لهذا السبب من المهم أن تحفظ دائمًا أي حالة لم يتم حفظها للمستخدم في حدث 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، يمكنك تحديد علامة التبويب التي تريد تجاهلها من القائمة، ثم النقر على التجاهل العاجل من عمود الإجراءات.

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

تجدر الإشارة إلى أنّه لا تتوفّر حاليًا طريقة لتنفيذ عمليات تجاهل علامات التبويب بشكل تلقائي عبر أدوات اختبار مثل webdriver أو محرك الدمى، ولكن بما أنّ عمليات تجاهل علامات التبويب واستعادتها تتماثل تقريبًا مع عمليات إعادة تحميل الصفحات، إذا اختبرت أنّ حالة المستخدم قد استعدت بعد إعادة تحميل في منتصف تدفق المستخدم، ستعمل على الأرجح على التجاهل/الاستعادة أيضًا. الفرق الأساسي بين الحدثَين هو أن الأحداث 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 هما ميزتان موجَّهتان للمستخدمين في المقام الأول، إلا أنّهما لكلتاهما تداعيات على المطوّرين، لأنّهما قد يؤثران سلبًا في تجربة زيارة موقعك الإلكتروني في حال عدم التعامل معهما بشكل صحيح.

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

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

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