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

Philip Walton

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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