ذاكرة الرجوع/التقدم (bfcache)

الخلاصة — ذاكرة الرجوع/التقدم (bfcache) ميزة في المتصفح تجمّد الصفحة كاملة في الذاكرة عند مغادرتها، بحيث يمكن لزرّي Back أو Forward إعادتها فورًا — بلا إعادة تحميل — ما لم يُخرج المتصفح تلك الصفحة المجمدة من الذاكرة أولًا. إنها ميزة متصفح وليست عامل ترتيب في Google. ولأن الصفحة المستعادة تُحمّل شبه فورًا، فإنها تحسّن بهدوء أرقام Core Web Vitals في تنقلات Back/Forward التي تُستعاد فعلًا، ولهذا قد يطلب منك تدقيق الأداء «إصلاح أهلية bfcache».

ما هي ذاكرة bfcache؟

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

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

تصف Google ذلك في سطر واحد بوضوح: bfcache هي “a browser optimization that enables instant back and forward navigation.” (الترجمة العربية) «تحسين في المتصفح يتيح تنقلًا فوريًا إلى الخلف وإلى الأمام».

لماذا ليست «ذاكرة التخزين المؤقت» التي تعرفها؟

هنا يختلط الأمر على الناس. عندما تسمع «cache» تفكر غالبًا في ذاكرة المتصفح أو HTTP cache — أي الملفات (الصور والبرامج النصية وملفات CSS) التي يحفظها المتصفح كي لا يعيد تنزيلها. لكن bfcache ليست ذلك؛ فهذه الذاكرات تخزن الملفات، بينما تخزن bfcache الصفحة الحية كاملةً، مع حالة JavaScript، في صورة لقطة. وتوضح وثائق Chrome: bfcache “differs from browser cache and HTTP cache.” (الترجمة العربية) «تختلف عن ذاكرة المتصفح وذاكرة HTTP».

وليست bfcache أيضًا شيئين آخرين يخلط الناس بينهما وبينها: ذاكرة الموارد داخل المتصفح (البرامج النصية المترجمة والصور المفكوكة التي يحتفظ بها للجلسة الحالية)، وCache Storage الخاصة بـservice worker (أزواج الطلب/الاستجابة التي يديرها الموقع صراحةً عبر caches.open()). يمكن أن تعمل الآليتان في الصفحة نفسها بالتزامن مع bfcache — لكنهما آليتان منفصلتان وليستا bfcache.

وليست كذلك ميزة «الصفحة المخزنة» أو «اللقطة المخزنة» القديمة التي كان Google وBing يعرضانها في نتائج البحث (القائمة الصغيرة التي تعرض نسخة الصفحة المحفوظة لديهما). كانت تلك ميزة بحث وقد أُحيلت إلى التقاعد. أما bfcache فهي ميزة حية في المتصفح لا علاقة لها بنتائج البحث.

هل تساعد bfcache في تحسين SEO لدي؟

ليس مباشرةً. فـbfcache ليست عامل ترتيب في Google — ووثائق Google الخاصة بترتيب Core Web Vitals لا تذكرها إطلاقًا. ما تفعله هو جعل تنقلات Back/Forward تُحمّل شبه فورًا للزوار الذين يحصلون فعلًا على استعادة، وتقيس المتصفحات ذلك بوصفه «تحميل صفحة» ممتازًا. فإذا كان كثير من زوارك يستخدمون Back وForward (التسوق، وتصفح نتائج البحث، وقراءة المقالات بالتتابع)، فقد تحسن bfcache أرقام Core Web Vitals الميدانية لموقعك — وهي واحدة من أشياء كثيرة تقول Google إنها تتماشى مع ما تكافئه أنظمة الترتيب. إنها خطوتان بعيدًا عن عبارة «bfcache ترفع الترتيب»، ولا تضمن معدل الاستعادة أو تقييم Core Web Vitals الإجمالي أو ترتيبك — لكنها فائدة حقيقية قابلة للقياس.

هل تريد الصورة الكاملة — ما الذي يمنع bfcache تحديدًا، وكيف تختبرها، وما العلاقة الدقيقة (غير المبالغ فيها) مع Core Web Vitals؟ انتقل إلى علامة التبويب Advanced.

الخلاصة — bfcache لقطة للصفحة كاملة في الذاكرة (DOM + JS heap + running state)، وليست استجابة HTTP قابلة لإعادة الجلب، ولا ذاكرة الموارد داخل المتصفح، ولا Cache Storage لـservice worker — وهذا هو الفرق المفاهيمي الأهم. عند مغادرة الصفحة يوقف المتصفح JS ويجمّد الصفحة؛ وعند Back/Forward، إذا بقيت اللقطة متاحة، يفك تجميدها ويعرضها فورًا بلا طلبات شبكة — لكن الإخلاء ممكن دائمًا، لذا اعتبر الاستعادة مرجحة لا مضمونة. وهي ليست عامل ترتيب موثقًا في Google Search (فوثائق Core Web Vitals في Search Central لا تذكرها)؛ صلتها غير مباشرة ومحددة بنسج قياس CWV الميداني (خصوصًا LCP وCLS) في التنقلات التي تُستعاد فقط — ولا تضمن معدل الاستعادة أو تقييم CWV الإجمالي أو الترتيب أو التحويل. أكبر عائق للأهلية هو معالج unload (نحو 18 نقطة مئوية من معدل الإصابة في Chrome)؛ أما العائق التاريخي الأكبر فكان Cache-Control: no-store (يمنع نحو 17% من تنقلات السجل على الهاتف و~7% على سطح المكتب)، مع أن Chrome يسمح الآن، بعد طرح 2025، بـbfcache لصفحات no-store كثيرة بشروط (تُخلى عند تغير المصادقة/ملفات تعريف الارتباط، وتظل APIs ذات الاتصالات المفتوحة مانعة). ينبغي إغلاق/إيقاف الاتصالات والمؤقتات والمراقبين عند pagehide/freeze وإعادتها عند pageshow/resume؛ وقد تمنعه أيضًا window.opener وسياسات الأذونات والإطارات — افحص السبب لكل إطار في DevTools أو notRestoredReasons بدل التخمين. اختبره مرة واحدة عبر Chrome DevTools؛ وشخّصه ميدانيًا عبر API notRestoredReasons الخاص بـChrome (النتيجة null ليست دليل استعادة، ونص السبب غير ثابت). لكل متصفح قواعد أهلية خاصة، والتنقلات اللينة في SPA لا تحصل على المعاملة نفسها.

ما هي bfcache فعلًا؟ (محور الدقة)

أهم نقطة ينبغي ضبطها: bfcache لقطة كاملة للصفحة في الذاكرة، وليست استجابة HTTP مخزنة. عند مغادرة الصفحة، لا يهدم المتصفح الصفحة؛ بل يوقف تنفيذ JavaScript ويجمّدها كاملة — DOM وJS heap والمؤقتات قيد التشغيل وكل شيء — ويحفظها في الذاكرة. إذا ضغطت Back أو Forward واللقطة المجمدة ما تزال متاحة، يفك المتصفح تجميدها ويعرض الصفحة نفسها التي تركتها، مع صفر طلبات شبكة وصفر إعادة تصيير. هذه استعادة ممكنة لا ضمان: قد يُخلي المتصفح اللقطة قبل عودتك (ضغط ذاكرة أو مهلة أو أحداث معينة)، أو تفرض قاعدة خاصة بالمتصفح تحميلًا جديدًا، وعندها تكون مجرد تنقل عادي في السجل. والصياغة المعتمدة لدى Google هي أن bfcache “a browser optimization that enables instant back and forward navigation.” (الترجمة العربية) «تحسين في المتصفح يتيح تنقلًا فوريًا إلى الخلف وإلى الأمام».

لهذا فإن الخلط بينها وبين ذاكرة HTTP/المتصفح هو خطأ المنافسين المتكرر. تخزن ذاكرة HTTP استجابات الطلبات السابقة — ملفات يمكن إعادة تقديمها. أما bfcache فتخزن الصفحة الحية قيد التشغيل. وتوضح وثائق Chrome DevTools الفرق صراحةً: bfcache “differs from browser cache and HTTP cache.” (الترجمة العربية) «تختلف عن ذاكرة المتصفح وذاكرة HTTP». ولا «تشغّل» bfcache عبر ترويسات التخزين بالطريقة التي تضبط بها التخزين المؤقت HTTP؛ فالموضع الوحيد الذي تدخل فيه الترويسات هو أن Cache-Control: no-store كانت تستبعد الصفحة من bfcache (وسنعود إلى ذلك أدناه).

ينطبق الفرق نفسه على ذاكرتين أخريين يخلط الناس بينهما وبين bfcache: ذاكرة الموارد داخل المتصفح (البرامج النصية المترجمة والصور المفكوكة المحفوظة للجلسة الحالية)، وCache Storage الخاصة بـservice worker (أزواج الطلب/الاستجابة التي يديرها الموقع بنفسه عبر caches.open()). يمكن أن تعمل كلتاهما في الصفحة نفسها وفي الوقت نفسه مع bfcache — لكن لا واحدة منهما هي bfcache، التي تعني نسخة الصفحة المجمدة لا الأصول المخزنة أو الاستجابات المعترضة.

وهناك توضيح آخر يستحق الذكر لأن الالتباس ما زال قائمًا: لا علاقة لـbfcache بميزة البحث القديمة «الصفحة المخزنة» التي كان Google (وBing) يعرضها في النتائج. كانت تلك لقطة محفوظة لصفحة داخل فهرس البحث وقد أُحيلت إلى التقاعد. أما bfcache فهي ميزة في محرك التصيير من جهة العميل.

ما مدى شيوع تنقلات Back/Forward فعلًا؟

هذه ليست حالة هامشية نادرة. فبحسب web.dev: “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward.” (الترجمة العربية) «واحد من كل عشرة تنقلات على سطح المكتب وواحد من كل خمسة على الهاتف يكون إلى الخلف أو إلى الأمام». وفي أي موقع يعتمد على تدفقات التكرار والرجوع — من فئة تجارة إلكترونية إلى منتج ثم عودة، أو نتائج بحث، أو محتوى مقسم إلى صفحات، أو قراءة مقال بعد مقال — فهذه حصة كبيرة من التنقلات الحقيقية التي يمكن جعلها فورية تقريبًا.

دعم المتصفحات

“All major browsers include a bfcache, including Chrome since version 96, Firefox and Safari.” (الترجمة العربية) «تتضمن جميع المتصفحات الرئيسية bfcache، بما فيها Chrome منذ الإصدار 96 وFirefox وSafari». ولدى Firefox وSafari تطبيقاتهما الخاصة الأقدم والأطول عمرًا؛ أما المتصفحات المبنية على Chromium (Edge وBrave وOpera وArc) فترث تطبيق Chrome. وتصف وثائق سياسة Edge من Microsoft الميزة نفسها: عند مغادرة الصفحة قد تُحفظ حالتها الحالية (شجرة المستند والبرنامج النصي وما إلى ذلك) في ذاكرة الرجوع/التقدم، وعند العودة قد يستعيدها المتصفح ويعرضها بالحالة التي كانت عليها قبل تخزينها. وهي مفعلة افتراضيًا في Edge؛ ومفتاح إيقافها الوحيد سياسة مؤسسية يتحكم فيها مسؤول تقنية المعلومات، لا مالك الموقع.

والتحفظ المهم هو أن لكل متصفح قواعد أهلية خاصة بـbfcache. فاجتياز الصفحة اختبار Chrome DevTools «Test back/forward cache» لا يضمن أهليتها في Firefox أو Safari. اعتبر نجاح Chrome ضروريًا لا كافيًا.

ما الذي يمنع أهلية bfcache؟

حدث unload — أكبر عائق على الإطلاق

إذا أخذت شيئًا واحدًا من هذا المقال، فليكن: توقف عن استخدام حدث unload. وتؤكد web.dev ذلك بتشديد نادر في وثيقة Google: “Never use the unload event. Ever!” (الترجمة العربية) «لا تستخدم حدث unload أبدًا!». وفي Chrome، يكلّف معالجو unload تقريبًا انخفاضًا قدره 18 نقطة مئوية في معدل إصابة bfcache — وهو أكبر عامل استبعاد تسببه بنفسك بفارق كبير.

هناك سببان لإنهاء Chrome استخدامه تدريجيًا. الأول أنه أكبر عائق أمام bfcache. والثاني أن unload غير موثوق أصلًا: فعلى الهاتف لا يُطلق كثيرًا على الإطلاق، لأن علامات التبويب تنتقل إلى الخلفية وتُقتل، ولأن المتصفح يعطي الأولوية لـbfcache على إطلاق unload. لذلك فإن الحدث الذي تعتمد عليه في «التنظيف» قد لا يعمل أصلًا، وفوق ذلك يحجب مكسب أداء حقيقيًا.

الإصلاحات:

• استبدل unload بـpagehide. يُطلق حدث pagehide في كل حالة يطلق فيها unload، إضافةً إلى حالة دخول الصفحة في bfcache — لذلك فهو ترقية صارمة. استخدم visibilitychange لتنظيف موثوق عند مغادرة المستخدم.
• اكتشف استعادة bfcache عبر pageshow. استمع إلى pageshow وافحص event.persisted — فإذا كانت true فقد استُعيدت الصفحة من bfcache، وهذه إشارة لتحديث البيانات القديمة أو إعادة عدّ مشاهدة الصفحة.
• احظر مستمعي unload استباقيًا عبر ترويسة الاستجابة Permissions-Policy: unload=()، التي تمنع تسجيل أي معالج unload أصلًا. وينقل Chrome السياسة الافتراضية تدريجيًا نحو المنع (وقد شُحنت Permissions-Policy الخاصة بـunload منذ Chrome 115).

Cache-Control: no-store — كان الأكبر تاريخيًا، لكنه أصبح أدق

هذه هي نقطة الحداثة التي تخطئ فيها معظم مقالات المنافسين. تاريخيًا كانت Cache-Control: no-store أكبر سبب منفرد لاستبعاد الصفحات من bfcache — وتضع أرقام Chrome الخاصة بها ذلك عند نحو 17% من تنقلات السجل على الهاتف و7% على سطح المكتب. تضبط مواقع كثيرة no-store دفاعيًا لتجنب تقديم صفحة قديمة، لكن حجة Google هي أن هذا السبب يضعف مع bfcache: فالاستعادة لا تحمّل استجابة مخزنة قديمة، بل تعيد عرض الصفحة الحية نفسها تقريبًا كما لو أن علامة التبويب ظلت مفتوحة.

غيّر Chrome السلوك — لكن بشروط لا على نحو شامل. بدأت التجارب في Chrome 116، واكتمل الطرح إلى 100% من المستخدمين خلال مارس وأبريل 2025: يسمح Chrome الآن بـbfcache لصفحات no-store كثيرة، وفق شروط أمان محددة لا استثناء عام. ووفق وثائق Chrome، هناك قيود حقيقية — تُخلى الصفحة من bfcache إذا تغيرت حالة المصادقة أو ملفات تعريف الارتباط أثناء تجميدها (حتى لا يرى زائر سجّل الخروج أو مسح ملفات الارتباط لقطة قديمة لتسجيل الدخول)، كما أن قائمة ثابتة من APIs — وهي APIs الاتصالات المفتوحة نفسها المذكورة أدناه (IndexedDB وWebSocket وWebRTC وغيرها) — ما زالت تستبعد صفحة no-store من bfcache كما تستبعد أي صفحة أخرى. هذا سلوك خاص بـChrome في نطاق إصدارات محدد، وليس قاعدة تفترضها في متصفحات أخرى أو إصدارات Chrome الأقدم — اجلب تقرير DevTools/notRestoredReasons الحالي للمتصفح والإصدار اللذين تختبرهما بدل الثقة بقاعدة ثابتة. الخلاصة العملية: أي دليل (بما فيه الإصدارات الأقدم من هذا المقال) يسرد no-store كعائق دائم وغير مشروط لـbfcache أصبح قديمًا — وكذلك التعامل معه كأنه حُلّ بالكامل. وإذا كانت الحداثة مهمة فعلًا، تقترح وثائق Chrome استخدام no-cache أو max-age قصير (مثل max-age=60) بدل no-store.

الاتصالات المفتوحة والمراقبون والعوائق الأخرى

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

• طلبات fetch() / XMLHttpRequest الجارية.
• معاملات IndexedDB المفتوحة.
• اتصالات WebSocket / WebRTC المفتوحة، والمؤقتات، والمراقبون (MutationObserver وIntersectionObserver وما شابه). هذا مجال يتحسن بنشاط — فتوضح ملاحظات إصدارات Microsoft Edge الحديثة أن WebSocket المفتوح يُغلق الآن عند دخول الصفحة bfcache (بدل منع التخزين المؤقت كليًا)، مع التوصية بإعادة الاتصال عبر حدث pageshow وفحص event.persisted. وهذا يطابق اتجاه Chrome الأوسع إلى تقليل العوائق بدل استبعاد الصفحات فحسب.

النمط العام الذي ينبغي بناؤه، بدل حفظ قائمة ثابتة، هو إغلاق أو إيقاف الاتصالات والمؤقتات والمراقبين المفتوحة في معالجة pagehide/freeze، ثم إعادتها في معالجة pageshow/resume عندما تكون event.persisted مساوية لـtrue. ويظل هذا النمط صالحًا حتى يغير المتصفح بالضبط أي APIs تمنع الأهلية صراحةً وأيها يعلّقها فقط ويسمح لك بإعادة الاتصال.

window.opener وسياسات الأذونات والإطارات. قد يؤثر مرجع window.opener وسياسات أذونات معينة وإطارات iframe المضمنة (من المصدر نفسه أو من مصدر مختلف) في الأهلية أيضًا — وهذه عناصر في القائمة التي استخلصتها من دليل CLS لدى Ahrefs ومن وثائق Chrome. لكن لا تفترض السبب الفعلي من قائمة عامة: تعرض لوحة Chrome DevTools وAPI notRestoredReasons أسباب المنع لكل إطار — الإطار الأعلى وكل iframe على حدة — لأن الإطار المسؤول عن المنع ليس دائمًا الصفحة العليا. اجلب السبب الحقيقي من تقرير ذلك الإطار للمتصفح الذي تختبره بدل التخمين من قائمة عامة.

ضبط تسلسل أحداث/حالة دورة الحياة

الخلط بين ما يثبته كل حدث من أحداث دورة الحياة وما يوحي به فقط هو ثاني أكثر أخطاء الصحة شيوعًا هنا، بعد أخطاء الأهلية المذكورة أعلاه:

القاعدة العملية: تعامل مع pagehide.persisted بوصفه نية لا دليلًا — فقد تُخلى الصفحة قبل أن ترى استعادة. وpageshow.persisted === true وحده دليل على حدوث الاستعادة. نفّذ التنظيف بلا شروط عند pagehide/freeze (فهو رخيص وآمن حتى في تنقل عادي)، ونفّذ العمل الخاص بالاستعادة فقط عند pageshow/resume وبعد تقييده بـevent.persisted، حتى لا تحدّث البيانات أو تعدّ مشاهدة تحليلية مرتين عند تحميل جديد عادي.

كيف تختبر bfcache وتشخّصها؟

المختبر / الفحص الواحد: Chrome DevTools

افتح DevTools → Application → Background services → Back/forward cache، ثم انقر “Test back/forward cache.” سينتقل Chrome تلقائيًا إلى chrome://terms/ ثم يعود، ويعرض إما نجاحًا أو قائمة محددة بأسباب المنع. وهذا مناسب لفحص عنوان URL واحد في كل مرة.

الميدان / الإنتاج: API notRestoredReasons

في السابق كانت الطريقة الوحيدة لفحص الأهلية هي اختبار DevTools اليدوي لعنوان URL واحد في كل مرة — ولم تكن هناك طريقة لمعرفة سبب منع تنقلات المستخدمين الحقيقيين. وتسُد خاصية notRestoredReasons في PerformanceNavigationTiming (المتاحة منذ Chrome 123+) هذه الفجوة؛ فهي تعرض أسباب المنع المحددة للإطار الأعلى والإطارات ذات المصدر نفسه في بيانات الميدان الحقيقية.

const nav = performance.getEntriesByType('navigation')[0];
console.log(nav.notRestoredReasons);

هناك أمور قليلة ينبغي ضبطها عند استخدامها، وفق إرشادات API الخاصة بـChrome:

• تعمل في Chrome فقط (123+). لا يعرض Firefox وSafari API ميدانيًا مكافئًا، لذا لا تزال تحتاج إلى فحوص يدوية موضعية فيهما لمعرفة معدل الاستعادة هناك.
• نتيجة null ملتبسة وليست ضوءًا أخضر. قد تعني أن الصفحة استُعيدت، أو أن المتصفح لم يجمع سببًا ببساطة — وتقول وثائق Chrome نفسها لا تتعامل مع null كدليل على استعادة ناجحة.
• نص السبب ليس عقدًا ثابتًا. لا تبرمج مطابقات نصية ثابتة له؛ بل اجمع الأسباب وتتبع اتجاهاتها، لأن الصياغة الدقيقة قد تتغير عبر إصدارات Chrome.

عمليًا: اجلب notRestoredReasons إلى جانب معدلات الاستعادة pageshow.persisted قبل إطلاق الإصلاح وبعده، وقارن الاتجاه لا لقطة واحدة، واجمع ذلك مع فحص يدوي عبر DevTools/المختبر في Firefox وSafari، حيث لا يصل API. هذه هي الأداة المناسبة لتشخيص bfcache على نطاق واسع في RUM/الإنتاج، لا لفحص العناوين واحدًا واحدًا — لكن لا تتعامل معها بوصفها الصورة كلها.

bfcache وCore Web Vitals — العلاقة الدقيقة

هذه هي الدقة التي تطمسها معظم مقالات المنافسين، وهي الزاوية التي تستحق امتلاكها.

كيف تُقاس استعادة bfcache؟ تعد المتصفحات (وبالتالي بيانات CrUX الميدانية) التنقل المستعاد من bfcache «تحميل صفحة» سريعًا جدًا — مع LCP شبه فوري، وعندما تُنفذ الصفحة صحيحًا (ولا تضطر إلى إعادة التخطيط)، صفرًا إضافيًا تقريبًا في CLS، لأنه لا توجد إعادة تصيير. وفي مقارنة DebugBear الواقعية، حققت صفحة مستعادة من bfcache قيمة LCP تقارب 100ms مقابل ~427ms لتحميل غير مخزن. ولهذا بالضبط تظهر bfcache كرافعة لـCLS وLCP في قائمة CLS لدى Ahrefs، حيث أقولها ببساطة: “Make sure your pages are eligible for bfcache. The back/forward cache keeps pages in the browser cache. It allows for instant loading of a page that was already loaded, meaning no layout shifts will happen.” (الترجمة العربية) «تأكد من أن صفحاتك مؤهلة لـbfcache. تحتفظ ذاكرة الرجوع/التقدم بالصفحات في ذاكرة المتصفح، وتتيح تحميل الصفحة المحملة مسبقًا فورًا، ما يعني عدم حدوث تحولات في التخطيط».

هناك تحفظان على النطاق ينبغي صياغتهما بدقة، لأن محتوى المنافسين يبالغ هنا عادةً. أولًا، يؤثر ذلك فقط في التنقلات التي تصنفها CrUX على أنها رجوع/تقدم (بُعد navigation-type) — ولا يقول شيئًا عن زياراتك الأولى أو عمليات إعادة التحميل، وهي أغلبية الزيارات في معظم المواقع. ثانيًا، تحسين الاستعادة للتجربة المقاسة لدى المستخدمين الذين يحصلون عليها ليس ضمانًا: فالمستخدم الذي أُخليت صفحته من bfcache (راجع جدول دورة الحياة أعلاه) سيحصل على تحميل عادي غير محسّن؛ لذلك تحرك أعمال أهلية bfcache معدل الاستعادة بين تنقلات Back/Forward، لا حصة ثابتة من إجمالي الزيارات — ولا تضمن تقييم Core Web Vitals الميداني الإجمالي أو الترتيب أو معدل التحويل. إنها رافعة حقيقية قابلة للقياس بنطاق محدد، وليست إصلاح أداء أو SEO عامًا.

هل bfcache عامل ترتيب؟ لا. هذا هو الادعاء القابل للدفاع والمميز. لا تذكر وثائق Google الخاصة بترتيب Core Web Vitals bfcache إطلاقًا. وسلسلة التأثير الصادقة هي: أهلية bfcache ← أرقام CWV ميدانية أفضل (خصوصًا LCP/CLS) في تنقلات الرجوع/التقدم ← Core Web Vitals إشارة واحدة بين إشارات «تجربة الصفحة» الكثيرة التي تقول Google إنها تتماشى مع ما تكافئه أنظمة الترتيب. وهذا ادعاء أضعف وأكثر دقة بكثير من «bfcache ترفع الترتيب» — وهو الادعاء الذي ينبغي أن تقوله مقالات المنافسين عادةً لكنها لا تتوخى الدقة فيه. كما أن bfcache، على نحو صحيح، ميزة في محرك التصيير وليست ميزة للزاحف — لا علاقة لها بكيفية زحف Googlebot أو Bingbot إلى صفحاتك، ولهذا لا توجد «وجهة نظر Bing حول bfcache لأغراض SEO» مثلما توجد حول robots.txt أو خرائط المواقع.

تطبيقات SPA والتنقلات اللينة. تعمل bfcache مع تنقل المتصفح الحقيقي وأحداث السجل. أما تغير المسار «اللين» من جهة العميل في تطبيق أحادي الصفحة (تبديل عرض يقوده JS ولا يطلق تنقلًا حقيقيًا للمتصفح) فليس حدث bfcache ولا يحصل على المعاملة نفسها. وقد تؤدي محاولات بعض أدوات RUM لنسب Core Web Vitals إلى التنقلات اللينة إلى اختلافات في القياس بين CrUX وRUM — وهي نقطة ينبغي ذكرها عند تدقيق موقع مبني على إطار JS.

ما مدى شيوع عوائق bfcache في الواقع؟

يتابع Web Almanac التابع لـHTTP Archive ذلك، وهو مجال حي متغير لا خبر قديم محسوم. في إصدار 2022، لم تكن أهلية نحو ~22% من صفحات الهاتف ممكنة استنادًا إلى معياري unload وno-store وحدهما. ومنذ ذلك الحين انخفض استخدام معالجات unload عبر شرائح المواقع والأجهزة، لكن استخدام Cache-Control: no-store ارتفع (إذ يضعه فصل 2025 عند نحو 23% من المواقع، مقابل ~21% في 2024، ويربط ذلك جزئيًا بتجارب أكثر اعتمادًا على المصادقة والتخصيص وبمتطلبات امتثال أشد).

والنتيجة غير البديهية الجديرة بالاقتباس هي أن المواقع الأكبر والأعلى حركة أكثر عرضة بصورة غير متناسبة لحجب bfcache عن نفسها. فما زال نحو 28% من صفحات سطح المكتب و20% من صفحات الهاتف ضمن أكبر 1 000 موقع يستخدم معالجات unload، مقابل 11% لسطح المكتب و10% للهاتف عبر كل المواقع — غالبًا لأن المواقع الأكبر تحمل تحليلات قديمة وكودًا يعتمد على unload. والمواقع التي لديها أكثر حركة رجوع/تقدم يمكن خسارتها هي غالبًا المواقع التي تعرقل نفسها حتى الآن.

أين تقع هذه الميزة؟

bfcache رافعة أداء واحدة بين عدة رافعات في هذه المجموعة. يظهر مردودها في بيانات Core Web Vitals الميدانية — وتحديدًا Cumulative Layout Shift وLargest Contentful Paint — لأن الصفحة المستعادة تُعرض فورًا بلا إعادة تخطيط. وهي مختلفة عن التخزين المؤقت الذي يخزن الملفات لا لقطة الصفحة الحية، رغم اشتراكهما في ترويسة Cache-Control كنقطة تماس. ولا توجد صلة مباشرة بـInteraction to Next Paint، لذلك لن أفرض صلة غير موجودة.

ملخص الذكاء الاصطناعي

خلاصة مركزة للنسخة المتقدمة:

• bfcache = لقطة كاملة للصفحة في الذاكرة (DOM + JS heap + running state)، وليست استجابة HTTP قابلة لإعادة الجلب ولا ذاكرة موارد المتصفح ولا Cache Storage الخاصة بـservice worker. عند المغادرة يوقف المتصفح JS ويجمّد الصفحة؛ وعند Back/Forward، إذا بقيت اللقطة متاحة، يفك تجميدها ويعرضها فورًا بلا طلبات شبكة — والإخلاء ممكن دائمًا، لذا فالاستعادة مرجحة لا مضمونة. تقول وثائق Chrome: “differs from browser cache and HTTP cache.” (الترجمة العربية) «تختلف عن ذاكرة المتصفح وذاكرة HTTP». وهي أيضًا ليست ميزة البحث القديمة «الصفحة المخزنة» التي أُحيلت إلى التقاعد.
• ليست عامل ترتيب ونطاقها محدد. لا تذكر وثائق Google لترتيب Core Web Vitals bfcache إطلاقًا. والسلسلة الحقيقية غير مباشرة: أهلية bfcache ← أرقام CWV ميدانية أفضل (خصوصًا LCP/CLS) في تنقلات Back/Forward التي تُستعاد ← CWV إشارة من إشارات تجربة الصفحة التي تقول Google إنها تتماشى مع أنظمة ترتيبها. ولا تضمن معدل الاستعادة أو CWV الإجمالي أو الترتيب أو التحويل، ولا تمس إلا التنقلات التي تصنفها CrUX رجوعًا/تقدمًا.
• الحجم: “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward.” (الترجمة العربية) «واحد من كل عشرة تنقلات على سطح المكتب وواحد من كل خمسة على الهاتف يكون إلى الخلف أو إلى الأمام». الدعم: Chrome منذ v96، إضافة إلى Firefox وSafari، ولكل متصفح قواعد أهلية خاصة.
• أكبر عائق: حدث unload (“Never use the unload event. Ever!” (الترجمة العربية) «لا تستخدم حدث unload أبدًا!») — نحو 18 نقطة مئوية من معدل الإصابة في Chrome. استبدله بـpagehide وvisibilitychange، واكتشف الاستعادة عبر pageshow/event.persisted، واحظر unload عبر Permissions-Policy: unload=().
• Cache-Control: no-store كان العائق التاريخي الأكبر (~17% للهاتف / ~7% لسطح المكتب في تنقلات السجل). يسمح Chrome الآن بصفحات no-store كثيرة بشروط بعد طرح مارس–أبريل 2025 — تُخلى عند تغير المصادقة/ملفات الارتباط، وتظل APIs الاتصالات المفتوحة نفسها مانعة — وذلك في Chrome فقط؛ الأدلة القديمة التي تسمي no-store عائقًا مطلقًا أصبحت قديمة، كما أن اعتباره محلولًا بالكامل خطأ.
• عوائق أخرى: fetch/XHR الجارية، والمؤقتات، والمراقبون، وIndexedDB المفتوحة، وWebSocket/WebRTC (أغلق/أوقف عند pagehide/freeze وأعد الاتصال عند pageshow/resume)، وwindow.opener، وسياسات الأذونات، والإطارات — اسحب السبب لكل إطار من DevTools/notRestoredReasons بدل الافتراض.
• صحة دورة الحياة: pagehide.persisted نية لا دليل؛ وpageshow.persisted === true وحدها تؤكد الاستعادة. نظّف بلا شروط عند pagehide/freeze، ونفّذ عمل الاستعادة (تحديث الحالة الحساسة، وإعادة الاتصال، وعد مشاهدة تحليلية واحدة) فقط عند pageshow/resume.
• الاختبار: Chrome DevTools عبر «Test back/forward cache» لفحص المختبر؛ وAPI notRestoredReasons الخاص بـChrome (Chrome 123+) لبيانات الميدان — null ليس دليل استعادة، ونص السبب غير ثابت، ويحتاج Firefox وSafari فحصًا يدويًا. قارن معدلات notRestoredReasons وpageshow.persisted قبل الإصلاح وبعده.
• SPAs: التنقلات اللينة من جهة العميل ليست أحداث bfcache ولا تحصل على المعاملة نفسها، وقد تسبب اختلاف CrUX وRUM.
• التبني (Web Almanac): استخدام no-store يرتفع (~21%→23%)، واستخدام unload أعلى في المواقع الأكبر (~28% لسطح المكتب ضمن أكبر 1 000) — وهي مواقع تحجب bfcache عن نفسها كثيرًا.

الوثائق الرسمية

وثائق أولية عن bfcache. لاحظ انقسام المصدر: تعيش bfcache في وثائق Chrome / محرك التصيير (الصوت المؤسسي لـGoogle هنا)، لا في Google Search Central — وهذا الفصل هو لب الموضوع.

Google / Chrome

• ذاكرة الرجوع/التقدم — الوثيقة المرجعية: التعريف والآلية وإحصاء 1 من 10 / 1 من 5 وإرشادات unload.
• اختبار ذاكرة الرجوع/التقدم — خطوات اختبار DevTools وأكبر العوائق والعبارة الصريحة “differs from browser cache and HTTP cache.” (الترجمة العربية) «تختلف عن ذاكرة المتصفح وذاكرة HTTP».
• تمكين bfcache مع Cache-Control: no-store — تغيير السياسة في 2025 وأرقام 17% / 7% والجدول الزمني للطرح.
• إيقاف حدث unload تدريجيًا — سبب التخلص التدريجي من unload وانتقال Permissions-Policy.
• API ‏notRestoredReasons لذاكرة الرجوع/التقدم — التشخيص الميداني عبر PerformanceNavigationTiming (Chrome 123+).
• فهم Core Web Vitals ونتائج بحث Google — وثيقة ترتيب Google Search Central؛ ويُستشهد بها هنا دليلًا على أنها لا تذكر bfcache إطلاقًا.

Microsoft / Edge

• سياسة Microsoft Edge: BackForwardCacheEnabled — تعريف Edge، وتحفظ unload نفسه، ومفتاح الإيقاف عبر سياسة المؤسسة.

MDN / معايير الويب

• bfcache — مسرد MDN — تعريف عام محايد للمحرك والفرق عن ذاكرة HTTP.
• مراقبة أسباب منع bfcache — MDN — استخدام notRestoredReasons عمليًا.

اقتباسات من المصدر

عبارات مسجلة في وثائق المصدر. كل رابط هو رابط عميق يقفز إلى المقطع المقتبس في صفحة المصدر.

Google / Chrome — ما هي bfcache ولماذا تهم؟

• “Back/forward cache (or bfcache) is a browser optimization that enables instant back and forward navigation.” (الترجمة العربية) «ذاكرة الرجوع/التقدم (أو bfcache) تحسين في المتصفح يتيح تنقلًا فوريًا إلى الخلف وإلى الأمام» — web.dev. الانتقال إلى الاقتباس
• “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward. With bfcache enabled, browsers could eliminate the data transfer and time spent loading for billions of web pages every single day!” (الترجمة العربية) «واحد من كل عشرة تنقلات على سطح المكتب وواحد من كل خمسة على الهاتف يكون إلى الخلف أو إلى الأمام. ومع تفعيل bfcache يمكن للمتصفحات إلغاء نقل البيانات ووقت التحميل لمليارات صفحات الويب كل يوم!» الانتقال إلى الاقتباس
• “All major browsers include a bfcache, including Chrome since version 96, Firefox and Safari.” (الترجمة العربية) «تتضمن جميع المتصفحات الرئيسية bfcache، بما فيها Chrome منذ الإصدار 96 وFirefox وSafari» الانتقال إلى الاقتباس

Google / Chrome — قاعدة التحسين رقم 1

• “Never use the unload event. Ever!” (الترجمة العربية) «لا تستخدم حدث unload أبدًا!» — web.dev. الانتقال إلى الاقتباس

Chrome DevTools — bfcache ليست ذاكرة HTTP

• “Back/forward cache differs from browser cache and HTTP cache.” (الترجمة العربية) «تختلف ذاكرة الرجوع/التقدم عن ذاكرة المتصفح وذاكرة HTTP» — وثائق Chrome DevTools. الانتقال إلى الاقتباس

Microsoft Edge — الميزة نفسها والتحفظ نفسه

• “When navigating away from a page, its current state (document tree, script, and so on) may be preserved in the back-forward cache. If the browser navigates back to the page, the page may be restored from the back-forward cache and displayed in the state it was in before being cached.” (الترجمة العربية) «عند مغادرة الصفحة قد تُحفظ حالتها الحالية (شجرة المستند والبرنامج النصي وما إلى ذلك) في ذاكرة الرجوع/التقدم. وإذا عاد المتصفح إلى الصفحة فقد يستعيدها من الذاكرة ويعرضها بالحالة التي كانت عليها قبل التخزين» — وثائق سياسة Microsoft Edge. الانتقال إلى الاقتباس

Patrick Stox (أنا) — bfcache كرافعة لـCLS

• “Make sure your pages are eligible for bfcache. The back/forward cache keeps pages in the browser cache. It allows for instant loading of a page that was already loaded, meaning no layout shifts will happen.” (الترجمة العربية) «احرص على أهلية صفحاتك لـbfcache. فهي تحفظ الصفحة التي حُمّلت سابقًا لتظهر فورًا، ولذلك لا تحدث تحولات في التخطيط» — دليلي لدى Ahrefs عن CLS. قراءة الدليل

قائمة التحقق من أهلية bfcache

فحص للتأكد من أن صفحاتك يمكنها دخول ذاكرة الرجوع/التقدم:

• لا توجد مستمعات لحدث unload في أي مكان من الصفحة (في كودك أو كود طرف ثالث). فهذا أكبر عائق.
• نُقلت أكواد التنظيف/التحليلات من unload إلى pagehide و visibilitychange.
• يتحقق مستمع pageshow من event.persisted لتحديث البيانات القديمة وإعادة عد مشاهدات الصفحة بصورة صحيحة بعد استعادة bfcache.
• فكّر في ترويسة الاستجابة Permissions-Policy: unload=() لمنع تسجيل أي مستمعي unload.
• راجع Cache-Control: no-store — إذا ضبطتها دفاعيًا، فتأكد أنك ما زلت تحتاجها (يسمح Chrome 2025+ بصفحات no-store كثيرة بشروط — تُخلى عند تغير المصادقة/ملفات الارتباط، وتظل APIs الاتصالات المفتوحة نفسها مانعة؛ لا تفترض تطابق المتصفحات أو الإصدارات الأخرى)؛ وإذا كانت الحداثة مهمة ففضّل no-cache أو max-age قصيرًا.
• لا تترك اتصالات أو مؤقتات أو مراقبين مفتوحين عند وقت التنقل — طلبات fetch/XHR الجارية، ومعاملات IndexedDB المفتوحة، وWebSocket/WebRTC، وMutationObserver/IntersectionObserver (أغلق/أوقف عند pagehide/freeze وأعد الإنشاء عند pageshow/resume عندما تكون event.persisted صحيحة).
• لا توجد مراجع window.opener أو سياسات أذونات تقييدية أو إطارات محجوبة تجعل الصفحة غير مؤهلة — افحص السبب لكل إطار في DevTools/notRestoredReasons بدل افتراض ما ينطبق.
• اختبر الصفحة في المختبر عبر Chrome DevTools → Application → Back/forward cache → “Test back/forward cache.”
• شخّص ميدانيًا على نطاق واسع باستخدام notRestoredReasons في RUM (في Chrome فقط؛ النتيجة null ليست دليل استعادة، ونص السبب ليس عقدًا ثابتًا — تتبع السبب بدل مطابقة النصوص).
• لا تفترض أن نجاح Chrome يعني الأهلية في كل مكان — افحص Firefox وSafari يدويًا، فلكل منهما قواعده.

ورقة غش bfcache

ما الذي يمنعها — وما الإصلاح؟

أحداث ينبغي معرفتها

اختبرها

حقائق سريعة

• bfcache = صفحة حية كاملة في الذاكرة، وليست ملفات ولا ذاكرة الموارد ولا Cache Storage الخاصة بـservice worker. وتقول Chrome: “differs from browser cache and HTTP cache.” (الترجمة العربية) «تختلف عن ذاكرة المتصفح وذاكرة HTTP».
• ليست عامل ترتيب في Google — لا تذكر وثائق CWV في Search Central ذلك. تحسن الاستعادة LCP/CLS المقاسين لدى من يحصل عليها، لكنها لا تضمن معدل الاستعادة أو CWV الإجمالي أو الترتيب أو التحويل.
• الدعم: Chrome 96+ وFirefox وSafari — ولكل متصفح قواعده.
• واحد من كل 10 على سطح المكتب / واحد من كل 5 على الهاتف من التنقلات هو Back/Forward.

مضادات نمط bfcache (والخرافات خلفها)

«bfcache مجرد ذاكرة HTTP/المتصفح — أضبطها عبر Cache-Control.» لا. bfcache لقطة مستقلة كاملة للصفحة في الذاكرة؛ تقول وثائق Chrome إنها “differs from browser cache and HTTP cache.” (الترجمة العربية) «تختلف عن ذاكرة المتصفح وذاكرة HTTP». ولا تهم ترويسات التخزين إلا بقدر أن no-store كانت تستبعد الصفحة. لا «تشغّل bfcache» عبر ترويسات التخزين.

«bfcache عامل ترتيب في Google، لذلك إصلاحها يرفع الترتيب.» لا يثبت ذلك أي مصدر رسمي من Google Search. ووثيقة ترتيب Core Web Vitals لا تذكر bfcache. العلاقة الحقيقية غير مباشرة (LCP/CLS ميدانيان أفضل في تنقلات Back/Forward)، وهو ادعاء أضعف وأكثر دقة.

«Cache-Control: no-store يمنع bfcache دائمًا وبصورة نهائية.» كان ذلك صحيحًا تاريخيًا — وما زال السبب التاريخي الأكبر — لكنه لم يعد صحيحًا على نحو قاطع بعد طرح Chrome الكامل في 2025 لصفحات no-store الآمنة مع bfcache. الأدلة السابقة للتغيير قديمة في هذه النقطة — لكن اعتباره محلولًا بالكامل قديم أيضًا: استثناء Chrome مشروط (إخلاء عند تغير المصادقة/ملفات الارتباط، وما زالت APIs الاتصالات المفتوحة نفسها مانعة) وخاص بـChrome، وليس ضوءًا أخضر عالميًا.

«الصفحة التي تطلق pagehide مع persisted: true مخزنة بالتأكيد.» لا — هذه نية لا دليل. قد يُخلي المتصفح الصفحة قبل أن ترى استعادة. وحدها pageshow.persisted === true تؤكد حدوث استعادة فعلية.

«إذا اجتازت الصفحة اختبار bfcache في Chrome DevTools فهي مؤهلة في كل مكان.» خطأ. يطبق Chrome وFirefox وSafari قيودًا خاصة بكل منهم؛ والنجاح في أحدها لا يضمن الأهلية في الآخر.

«unload طريقة مناسبة لتشغيل كود الخروج/التنظيف، لذا سأبقيها.» لا — تسميها Chrome غير موثوقة جدًا (وغالبًا لا تُطلق على الهاتف أصلًا)، وتُنهيها تدريجيًا عبر Permissions-Policy تحديدًا لأنها أكبر عائق لـbfcache. استخدم pagehide + visibilitychange.

«تساعد bfcache تطبيق SPA بالطريقة نفسها التي تساعد بها موقعًا متعدد الصفحات.» ليس بلا تحفظ. ترتبط bfcache بتنقل المتصفح الحقيقي؛ وتغير المسار «اللين» من جهة العميل ليس الحدث نفسه ولا يحصل على المعاملة نفسها — وهو ما يسبب أيضًا اختلافات CrUX وRUM في المواقع الكثيفة بـSPA.

«حُلّت bfcache / صارت خبرًا قديمًا، ولا تستحق التدقيق.» تناقض ذلك بيانات Web Almanac نفسها: استخدام no-store يرتفع، واستخدام unload لا يزال أعلى بوضوح في أكبر المواقع وأكثرها حركة — وهي المواقع التي لديها أكثر حركة Back/Forward يمكن خسارتها.

أدوات اختبار وتشخيص bfcache

• لوحة Back/forward cache في Chrome DevTools. Application → Background services → Back/forward cache → “Test back/forward cache.” تنتقل تلقائيًا إلى chrome://terms/ ثم تعود، وتعرض النجاح أو أسباب المنع الدقيقة. الأفضل لفحص مختبري واحد لعنوان URL واحد.
• API notRestoredReasons (Chrome 123+). اقرأ performance.getEntriesByType('navigation')[0].notRestoredReasons في RUM لرؤية أسباب المنع لدى المستخدمين الحقيقيين — بما فيها الإطارات ذات المصدر نفسه — على نطاق واسع، لا في اختبار مختبري يدوي فقط.
• PageSpeed Insights / Lighthouse / CrUX. حيث تظهر عادةً توصية أو علامة «ذاكرة الرجوع/التقدم» أولًا في التدقيق، وحيث تظهر فائدة CWV الميدانية لموقع مؤهل لـbfcache.
• ترويسة Permissions-Policy: unload=(). ليست أداة اختبار، لكنها ذراع إنفاذ: اضبطها لمنع تسجيل أي مستمعي unload (بما في ذلك مستمعي الطرف الثالث).
• فصل Performance في Web Almanac (HTTP Archive). لقياس مدى شيوع عوائق bfcache عبر الويب بحسب الجهاز وطبقة ترتيب الموقع.

يقول DevTools إن معالج unload منع الاستعادة

العَرَض: يسمي اختبار ذاكرة الرجوع/التقدم unload. السبب المرجح: سجّل كود الطرف الأول أو الطرف الثالث مستمع unload. الإصلاح: استبدل التنظيف بـpagehide/visibilitychange، وأضف Permissions-Policy: unload=() عند ملاءمته، ثم أعد الاختبار بعد كل تغيير في البرامج المتأثرة.

الصفحة المستعادة تعرض بيانات مستخدم قديمة

العَرَض: يعود Back فورًا، لكن حالة الحساب أو المخزون أو قيمة ديناميكية أخرى قديمة. السبب المرجح: استؤنفت الصفحة من حالتها المجمدة دون تحديث البيانات الحساسة للوقت. الإصلاح: استمع إلى pageshow، وافحص event.persisted، وحدّث البيانات المطلوبة فقط. وتأكد من أن التحميلات العادية والاستعادات يتصرفان على نحو صحيح.

التحليلات تفوّت مشاهدات Back/Forward أو تكررها

العَرَض: تختلف مشاهدات الصفحة عن تنقلات السجل الفعلية. السبب المرجح: تعمل التحليلات عند التحميل الأصلي فقط، أو تعمل مرتين دون التمييز بين الاستعادة. الإصلاح: عالج pageshow صراحةً واستخدم event.persisted لعد التنقل المستعاد مرة واحدة.

ينجح المختبر لكن تبقى الاستعادة الميدانية منخفضة

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

إثبات وصول إصلاح bfcache

اختبار الأهلية

الاختبار: DevTools → Application → Back/forward cache → Test back/forward cache. النتيجة المتوقعة: تستعيد الصفحة نفسها بنجاح دون سبب منع. تفسير الفشل: ما زال عائق أهلية واحد على الأقل موجودًا. نافذة المراقبة: فورية في Chrome للحالة المختبرة. محفز التراجع: يفسد الإصلاح التنظيف أو الأمان أو سلوك التطبيق المطلوب.

اختبار سلوك الاستعادة

الاختبار: غادر الصفحة واضغط Back، ثم تحقق من أن pageshow يتلقى event.persisted === true وأن البيانات الحساسة للوقت تُحدّث. النتيجة المتوقعة: استعادة فورية واحدة، وبيانات صحيحة، ومشاهدة تحليلية واحدة. تفسير الفشل: لم تُخزّن الصفحة أو أن معالجة الاستعادة ناقصة. نافذة المراقبة: فورية عبر حالات تسجيل الدخول والخروج التمثيلية. محفز التراجع: بيانات حساسة قديمة أو إجراءات مكررة بعد الاستعادة.

اختبار سبب ميداني

الاختبار: راقب PerformanceNavigationTiming.notRestoredReasons في RUM. النتيجة المتوقعة: ينخفض العائق المستهدف في القوالب المتأثرة دون أن يحل محله عائق مهيمن جديد. تفسير الفشل: لم تمثل عينة المختبر الإنتاج أو أن تبعية أخرى تملك المشكلة. نافذة المراقبة: حركة Back/Forward حقيقية كافية لمقارنة مزيج القوالب نفسه. محفز التراجع: تراجع مادي في التطبيق أو سلامة البيانات مرتبط بالتغيير.

مقاييس bfcache التي تستحق المتابعة

معدل الإصابة بالاستعادة

المقياس: تنقلات Back/Forward المؤهلة التي استُعيدت من bfcache. ما الذي يخبرك به: كم مرة يحصل المستخدمون على فائدة التنقل الفوري. كيفية استخراجه: إدخالات التنقل في RUM وpageshow.persisted، مقسمة حسب المتصفح والقالب. النطاق المرجعي الواقعي: أنشئ خط أساسك الخاص لأن قواعد المتصفح وحالة الصفحة ومزيج التنقل تختلف. الوتيرة: أسبوعيًا وبعد تغييرات دورة الحياة.

أسباب عدم الاستعادة

المقياس: تنقلات السجل مجمعة حسب notRestoredReasons. ما الذي يخبرك به: أي العوائق تكلفك أكثر من الاستعادات الحقيقية. كيفية استخراجه: API PerformanceNavigationTiming في المتصفحات الداعمة. النطاق المرجعي الواقعي: استهدف صفرًا للعوائق التي يتحكم فيها كودك، مع وسم تغطية المتصفح/API. الوتيرة: فرز أسبوعي.

صحة التنقل المستعاد

المقياس: الأخطاء وحوادث البيانات القديمة والتحليلات/الإجراءات المكررة بعد الاستعادة. ما الذي يخبرك به: هل تحافظ الأهلية الأعلى على صحة التطبيق. كيفية استخراجه: أحداث أخطاء RUM ومراقبة التطبيق وفحص التحليلات المرتبط بـpageshow.persisted. النطاق المرجعي الواقعي: صفر من إخفاقات الصحة أو الخصوصية المعروفة. الوتيرة: تنبيهات مستمرة وفحص جودة عند الإصدارات.

موارد تستحق وقتك

كتاباتي ذات الصلة

• ما هو Cumulative Layout Shift (CLS) وكيف تحسّنه — حيث أدرج أهلية bfcache كتكتيك لتحسين CLS مع قائمة عوائق مختصرة.
• ما هي Core Web Vitals (CWV) وكيف تحسنها — المقاييس الأم، مع bfcache كرافعة واحدة لـCLS بين عدة رافعات.
• دليل المبتدئين إلى Technical SEO — موضع أداء الويب في الصورة الأكبر.

حديثي

• How Search Works (SlideShare) — جولتي في الزحف والتصيير والفهرسة والترتيب، لفهم سبب بقاء ميزة مثل bfcache في محرك التصيير خارج إشارات ترتيب Search. (إخلائي الدائم: “This is my understanding of systems… not going to be 100% complete or accurate.” (الترجمة العربية) «هذا فهمي للأنظمة… ولن يكون كاملًا أو دقيقًا بنسبة 100%».)

رسمي

• ذاكرة الرجوع/التقدم (web.dev) — الوثيقة المرجعية.
• تمكين bfcache مع Cache-Control: no-store وإيقاف حدث unload تدريجيًا (Chrome for Developers) — التغييران اللذان يجعلان الأدلة القديمة قديمة.
• فهم Core Web Vitals ونتائج بحث Google (Google Search Central) — وثيقة الترتيب التي، على نحو دال، لا تذكر bfcache.

من أنحاء المجال

• bfcache — مسرد MDN — تعريف دقيق محايد للمحرك والفرق عن ذاكرة HTTP.
• ماذا تعني ذاكرة الرجوع/التقدم لسرعة الموقع؟ (DebugBear) — أكثر قطعة مبنية على البيانات في هذا المجال، مع سجل موقع حقيقي ومقارنة LCP ملموسة (~100ms للمخزن مقابل ~427ms لغير المخزن).
• شرح Back Forward Cache (SpeedVitals) — الآلية والأهلية والاختبار وتأثير CWV.
• Back/Forward Cache: ما هي وكيف تنفذها (NitroPack) — موجهة للتنفيذ ولجمهور CMS/الاستضافة.
• قفزة أداء: ذاكرة الرجوع/التقدم في المتصفح (Smashing Magazine) — تعمق تقني جيد، لكن لاحظ أنه يسبق تغيير no-store في 2025.
• Web Almanac — فصل الأداء (2025) (HTTP Archive) — بيانات التبني الواقعية عن انتشار unload وno-store بحسب الجهاز وطبقة ترتيب الموقع.

إحصاءات تستحق الاقتباس

• تنقلات Back/Forward شائعة: “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward” (الترجمة العربية) «واحد من كل عشرة تنقلات على سطح المكتب وواحد من كل خمسة على الهاتف يكون إلى الخلف أو إلى الأمام» — هذا حجم الفرصة لا حالة هامشية. المصدر
• يكلف unload نحو 18 نقطة مئوية من معدل إصابة bfcache في Chrome — ولهذا هو العائق رقم 1 ويجري التخلص منه تدريجيًا. المصدر
• كان Cache-Control: no-store أكبر عائق تاريخيًا — نحو 17% من تنقلات السجل على الهاتف و7% على سطح المكتب — قبل طرح Chrome في مارس–أبريل 2025 الذي سمح بصفحات no-store كثيرة في bfcache. المصدر
• استعادة bfcache شبه فورية: قاس DebugBear قيمة LCP عند نحو 100ms للصفحة المستعادة مقابل ~427ms لتحميل غير مخزن. المصدر
• المواقع الكبيرة تعرقل نفسها أكثر: في أكبر 1 000 موقع، ما زال نحو 28% من صفحات سطح المكتب و~20% من صفحات الهاتف يستخدم معالجات unload، مقابل ~11% / ~10% عبر جميع المواقع — كما أن استخدام no-store يرتفع (~21%→23%). المصدر

اختبر نفسك: ذاكرة الرجوع/التقدم (bfcache)

خمسة أسئلة سريعة عن ماهية bfcache وما الذي يمنعها وعلاقتها بـSEO. اختر إجابة لكل سؤال، ثم تحقق منها.

سجل التغييرات