عند بناء وظيفة Copy Site Data أو تنظيف بروفايل، غالبًا تتركز القوائم على Cookies و LocalStorage و IndexedDB. لكن التطبيقات التي تستخدم Service Workers قد تعتمد على Cache Storage لموارد أو بيانات API. تجاهلها يمكن أن ينتج نسخة منقولة ناقصة، ونسخها بلا تمييز يزيد الحجم وينقل محتوى قديمًا.
اعرف طبيعة البيانات المخزنة
Cache Storage يخزن Request/Response pairs حسب origin. قد تكون static assets أو API responses. قبل النقل، افحص أسماء caches وحجمها ونوع الموارد. لا تفترض أن كل cache مؤقتة أو أن كلها ضرورية.
قرر سياسة export
لجلسة يمكن إعادة بناء مواردها، استبعاد cache يقلل الحجم والمخاطر. لتطبيق offline قد تحتاجها. اجعل الخيار صريحًا حسب use case بدل سلوك خفي.
خطوات عملية
- صنف static/API/offline.
- احسب الحجم.
- حدد include policy.
- وثق ما استُبعد.
اختبر الاتساق مع Service Worker
نقل cache بدون registration أو العكس قد يترك حالة غير مكتملة. إذا اخترت نقل الاثنين، اختبر version compatibility. إذا استبعدت caches، تأكد أن worker يستطيع إعادة بنائها.
احمِ البيانات الحساسة
API responses cached قد تحتوي تفاصيل حساب. عاملها مثل storage حساسة في backup والتشفير وال retention. لا تشارك archive للنقل بدون مراجعة ما بداخله.
قائمة مراجعة
- حساسية response.
- تشفير الحزمة.
- مدة الاحتفاظ.
- حذف النسخة المؤقتة.
استخدم cleanup targeted
احذف cache ل origin أو اسم محدد بدل wipe شامل إذا كان الهدف إصلاح تطبيق واحد. سجل قبل/بعد حتى تعرف هل الإصلاح جاء من cache فعلًا.
قِس أثر النقل
قارن startup وحجم الحزمة والوقت حتى usable state مع cache وبدونها. أحيانًا إعادة التنزيل أسرع من نقل مئات MB، خصوصًا عبر شبكة جيدة.
قِس الحجم حسب Origin واختبر بقايا ال ـCaches القديمة
قبل تنظيف Cache Storage، اعرض أكبر Origins من حيث الاستخدام بدل الاعتماد على حجم مجلد البروفايل كله. صنف الحجم إلى Cache Storage و IndexedDB وغيرها إن أمكن، ثم نظف origin واحدة وأعد القياس. اختبر أيضًا تطبيقًا يستخدم أسماء versioned مثل app-v12 ثم مر بعدة تحديثات تجريبية؛ بعد activate يجب أن تختفي caches التي خرجت من policy. إذا بقيت app-v8 و v9 و v10 بلا سبب، فالمشكلة cleanup لا corruption. عند النقل، قارن وقت وحجم export مع cache وبدونها، واختبر هل التطبيق يعيد بناء الموارد بصورة صحيحة. قد يكون تنزيل الموارد مرة أخرى أسرع وأقل حساسية من حمل مئات الميجابايت بين الأجهزة. اجعل القرار مبنيًا على نوع التطبيق لا على قاعدة حذف/نسخ عامة.
قائمة مراجعة
- Top origins حسب الحجم.
- تنظيف targeted.
- Versioned caches القديمة.
- مقارنة export مع/بدون cache.
ضع حدًا أعلى للحجم وتنبيهًا للنمو غير الطبيعي
حتى مع cleanup صحيح، تطبيق معين قد يبدأ تخزين responses كبيرة بعد تحديث. سجل usage per-origin دوريًا وحدد baseline ونسبة نمو. إذا تضاعف الحجم خلال فترة قصيرة، أظهر تنبيهًا قبل امتلاء القرص. لا تحذف تلقائيًا؛ اعرض نوع التخزين وأكبر caches ليقرر المستخدم أو policy. هذا يحول مشكلة المساحة من حادث مفاجئ إلى مؤشر يمكن مراقبته.
افصل الاتساق عن محاولة التقليد
عند تقييم «Cache Storage كطبقة منسية عند نقل أو تنظيف البروفايل» ركز على الاتساق بين القيم بدل السعي إلى جعل كل قيمة تبدو مختلفة. أنشئ جدولًا يربط الشبكة وال ـtimezone واللغة وال ـUA والخصائص التي يغيرها المنتج، ثم افحص هل توجد تناقضات لا يمكن تفسيرها. أعد القياس بعد restart وبعد تغيير الشبكة لأن بعض القيم قد تأتي من cache أو من طبقة مختلفة. لا تعتبر اختلافًا واحدًا دليلًا على تتبع أو كشف؛ المطلوب مجموعة إشارات متوافقة وسيناريو يمكن تكراره. هذا يقلل القرارات المبنية على مواقع فحص واحدة أو نتائج لحظية.
قائمة مراجعة
- تسجيل القيم في نفس اللحظة.
- مقارنة بعد restart.
- تغيير متغير واحد فقط.
- تجنب الاستنتاج من أداة فحص واحدة.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…