تحديث ذاكرة JavaScript و CSS: عناوين بإصدارات ونشر آمن

افصل وثيقة HTML عن موارد الإصدارات

تعامل مع HTML كبيان صغير للإصدار. يشير A إلى app.4c21.js و site.19ab.css. يغير B التطبيق ويشير إلى app.9d80.js ، لكن CSS غير المتغير يحتفظ باسم site.19ab.css. البصمات هنا أسماء توضيحية، وليست نتائج حساب لملفات حقيقية.

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

اختر ترويسات تناسب هذا العقد

يلائم max-age الطويل مع immutable مورداً عاماً ذا عنوان محتوى لن تتغير بايتاته أبداً في ذلك العنوان. بالنسبة إلى HTML تسمح no-cache بالتخزين لكنها تشترط التحقق قبل إعادة الاستخدام؛ تختلف عن no-store التي تطلب عدم التخزين. اختر السياسة لكل نوع مورد.

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

Versioned public asset: /assets/app.9d80.js
Cache-Control: public, max-age=31536000, immutable

HTML document: /index.html
Cache-Control: no-cache

The URL /assets/app.9d80.js must continue to serve the same bytes.

قد يعمل إصدار الاستعلام إذا دخل مفتاح التخزين

يمكن أن يمثل /app.js?v=release-b هوية مختلفة عن /app.js?v=release-a ، بشرط أن تتضمن طبقات التخزين المعنية معامل الاستعلام. إذا تجاهلت قاعدة CDN الاستعلامات فقد يرجع العنوانان الجسم المخزن نفسه، فتفشل فكرة الإصدار.

تجنب القيمة العشوائية عند كل تحميل؛ العناوين الفريدة لكل زائر تضيع إعادة الاستخدام المفيدة. غيّر البصمة أو الإصدار الثابت فقط عند تغير المورد. ولا تستعمل جزءالعنوان مثل /app.js#release-b ؛ ما بعد# لا يرسل في طلب HTTP فلا يحقق الغرض.

شخّص الطبقة التي تقدم بايتات قديمة

قارن رد HTML والعنوان الذي يشير إليه وبايتات المورد عند الزائر المتأثر. إذا بقيت البصمة القديمة فافحص حداثة HTML. إذا ظهرت الجديدة وأتت بايتات قديمة فافحص النشر ومفتاح التخزين والأصل. إذا صح النقل وبقي السلوك، افحص الصفحة الجارية و service worker.

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

• سجّل عنوان HTML النهائي وعنوان السكربت أو الأنماط المشار إليه.
• افحص الحالة و Content-Type و Cache-Control و ETag وترويسات حالة التخزين المتاحة.
• تحقق أن المورد يرجع بايتاته المقصودة لا صفحة HTML احتياطية.
• افحص قواعد service worker منفصلة إذا كان التطبيق يثبته.
• اختبر زيارة نظيفة وصفحة تُترك مفتوحة عبر التحديث.

أبق الصفحات السابقة صالحة أثناء النشر والتراجع

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

انشر B مع موارد A و B ، وافحص B واترك إمكانية إعادة HTML إلى A. حذف app.4c21.js فوراً قد يكسر زائراً ما زال يحمل وثيقة A. واستعمال الاسم نفسه لبايتات جديدة يكسر عقد عنوان المحتوى ويجعل الرجوع غير موثوق. قِس فترة التوافق حسب سلوك تطبيقك.

قِس إعادة الاستخدام بعد إثبات الصحة

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

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