البحث في الموقع

دخل إلى مجال الويب مؤخرًا العديد من الأفكار والتقنيات والإضافات لغاية خدمة تجربة المستخدم في تطبيقات الويب، مثل دعم الإشعارات وتوافر أيقونة على سطح المكتب وإتاحة التحكم بالـ API والعمل بشاشة كاملة وأهم عناصر وأركان هذه التقنيات والإضافات "عامل أو منجز خدمة" Service Worker وما يقدمه من عمل التطبيق بدون الاتصال في الشبكة والتخزين المؤقت وغيرها مما ساهم بإنجاح تجربة المستخدم لهذه التطبيقات. مفهوم Service Worker منجز خدمة هو سكريبت (script) ينفذ في خلفية مشروع الويب (موقع أو تطبيق)، غير مرتبط بصفحة معينة. مسؤول عن الأحداث التي تجري بالمشروع مثل طلبات الشبكة الصادرة من الصفحة المسؤول عنها والاستجابات لهذه الطلبات، له عدة غايات من أهمها اتاحة استخدام التطبيق مع الشبكة أو بانقطاعها أو ببطئها. فلو افترضنا شخصًا يستخدم موقعًا وكان متصلًا بالشبكة وأثناء تصفحه للموقع انقطع اتصاله بالشبكة ولكن أراد الرجوع للصفحة السابقة عند إذٍ لن تفتح الصفحة السابقة وستظهر له شاشة تعلمه بإنقطاعه عن الشبكة، لكن إن كان ذلك الموقع يملك Service Worker فلن يحدث هذا، بل ستظهر الصفحة السابقة أو على الأقل جزء منها. ومن اللطيف ذكره أن أي موقع ويب بإمكانه أن يمتلك Service Worker وأن يُفعله مستفيدًا من مزاياه الرائعة، لكن في حالة تطبيقات الويب التقدمية PWA يجب أن تمتلكه وأن يكون مسجلًا وفعالًا فهو من شروط عملها. أهم الميزات التي يضفيها على مشروعك سرعة كبيرة يركز ال Service Worker في فكرته بشكل كبير على السرعة والأداء المثالي في التحميل وذلك في حالة اتصال الشبكة أو بدونها أو ببطئها وتكون أطول فترة تحميل في المرة الأولى وأما في الزيارات المتكررة يتم تحميلها بشكل أسرع. انظر المثال في الصورة حيث كان وقت التحميل في المرة الأولى 2.5 ثانية وفي الزيارات الأخرى 0.8 ثانية أي انخفضت إلى أقل من الثلث وهذا مثال بسيط. (بإمكانك اختبار أداء فاعلية مشروعك من خلال هذه الأداة WEBPAGETSET). العمل بدون شبكة كانت تتميز التطبيقات (العادية) عن الويب إمكانية عملها من غير اتصال شبكة، لكن الآن مع الـ Service Worker يمكن لمواقع وتطبيقات الويب أن تعمل بدون اتصال شبكة والذي يقوم بتخزين الموارد والعناصر التي ترتبط بالأحداث والتفاعل لاستخدامها بدون اتصال شبكة أو ببطئها. التحديث المستمر للتطبيق يعتبر Service Worker المسؤول عن التحديثات في تطبيقات الويب، بل يتميز عن تحديثات أنواع البرامج والتطبيقات الأخرى بالسلاسة والاستمرارية والسهولة وذلك من خلال تخزين وتثبيت الموارد المحدثة فقط وبشكل تلقائي ويظهر شارة صغيرة للمستخدم عند فتح التطبيق بأن التطبيق تم تحديثه. سيطرة أعلى يمنح Service Worker لمطورين المواقع والتطبيقات سيطرة كاملة وأفضل على تجربة المستخدم للتطبيق. تجربة تطبيقات حقيقية يدعم Service Worker ويحسن تجربة المستخدم في التطبيقات ومحاكاتها من خلال ما يوفر من السرعة والعمل بدون اتصال الشبكة والتخزين المؤقت وهيكل التطبيق (الذي سنفصل فيه) وغيرها. وكذلك يمنح تجربة تطبيقات حقيقية ويحسنها للجوال حيث تكون منفصلة ومستقلة عن المتصفحات لا يشترط أن تكون مبنية عليها. بنية هيكل التطبيق application shell architecture عند تكرار زيارة الموقع أو عند تحميل التطبيق يتم تخزين حد معين من الشيفرات المصدرية HTML، و CSS، و JavaScript مؤقتًا ليتم استعمالها بدون اتصال الشبكة أو حتى مع اتصالها ولكن بشكل فوري وأسرع. وصلب الفكرة هنا أننا نملك هيكل يمثل جزءًا معينًا من التطبيق أو الموقع موجود على جهاز المستخدم يُحمل ويُبنى فورًا عند فتحه سواء مع اتصال شبكة أو بدون ثم يبدأ إضافة المحتوى غير المشمول فيها من الشبكة على هذا الهيكل إذ هو بمثابة الوعاء الفارغ الذي يوضع فيه شيء ما.(يعني نحافظ على واجهة المستخدم الأساسية على جهاز المستخدم ولا داعي لتحميلها كل مرة). وبهذا فإنها تخدم التجربة كثيرًا بغض النظر عن اتصال الشبكة أو سرعتها. وحتى إن كانت فكرة التطبيق/الموقع تعتمد بشكل كامل على اتصال الشبكة فإن المستخدم سيحصل على هيكل وشكل جذاب ومناسب بعدم اتصال الشبكة ويتوافق مع شكل التطبيق الأصلي ولن تظهر له شاشة عدم الاتصال، فهذا الهيكل يلعب دورًا عظيمًا في الأداء المثالي للموقع أو التطبيق من سرعة وخفة وتجربة مثالية. بعد فتح الموقع في المرة الأولى وتحميل الـ Service Worker لهذا الهيكل تظهر شارة أن البرنامج جاهز للعمل بدون اتصال شبكة. والمسؤول عن هذا الهيكل هو Service Worker وفي حال عدم دعم المتصفح لـ Service Worker لا داعي للقلق، فإن الهيكل والصفحة كاملة ستعتمد في تحميلها على استراتيجية الويب الشهيرة Progressive Enhancement بدون مشاكل. ومن الأمثلة الناجحة في استخدام فكرة هذا الهيكل: Google’s Inbox و offline Wikipedia app ومعظم مشاريع نقاية. آلية عمل الـ Service Worker وحدود إمكانياته عند الزيارة الأولى للموقع أو عند تثبيت التطبيق يتم بناء الـ Service Worker وأخذ المحتوى والهيكل وكل البيانات والموارد من الخادم، وفي المرات التالية يتم سحب بيانات وعناصر محددة من الخادم ولكن كيف يتم تنظيم هذا السحب؟ كيف يتم تحميل بعض العناصر من Service worker وأخرى من الخادم؟ يعترض Service Worker طلبات الشبكة الصادرة من الصفحة وهنا يقوم بالاستجابة لهذه الطلبات بواحدة مما يلي: جلب المطلوب من الخادم عبر الشبكة. جلب المطلوب من الذاكرة المؤقتة على جهاز المستخدم، يتم جلب من الذاكرة المؤقتة العناصر والموارد المحددة مسبقًا لتجلب منها (مثل الهيكل الذي تحدثنا عنه). بناء المطلوب برمجيًا. والرائع هنا أن هذا كله يحدث دون أن يظهر مصدر الإستجابة ولا حتى أن الـ Service Worker قد تدخل. فلو تتبعنا دورة حياة الـ Service Worker لوجدنا أنه يتم بناءه عند أول دخول ويُحمل بعض الموارد عليه، ثم يُفعل ويَستيقظ عند وجود أي حدث، ويستجيب لهذا الحدث إن لزم الأمر مؤديًا دوره، ثم يُحذف من الذاكرة بمحتواه عند مرور الزمن دون أن ينشط، وتم إنشائه هكذا محدود العمر عن قصد. ومن الجيد معرفته أن Service Worker يحتوي على API محدودة مقارنة بما تحتويه الـ JavaScript في الصفحة العادية، بإمكانك أن تعرف تفاصيل API له هنا. واعلم بأن Service worker لا يمكنه الوصول إلى الـ DOM ولكن يمكنه الوصول إلى ذاكرة التخزين. ويمكنه أيضًا ارسال طلبات الشبكة، كذلك يمكنه أن يتواصل وأن يتبادل البيانات مع الصفحة المسؤول عنها عن طريق IndexedDB API و postMessage. لا تفوت ميزاته مع مشاريعك القادمة لكن بحدود يتبين مما سبق البون الشاسع الذي يُحدِثه الـ Service Worker في أداء مشاريع الويب معه، لذا يُنصح وبشدة استخدامه في تطبيقات ومواقع الويب، لكن بشكل معقول، فليس من المنطق أن تضيفه إلى مواقع صغيرة الحجم أو لا تقدم خدمة وتفاعل وتميل للمحتوى الثابت الخفيف فلا فائدة أو معنى من إضافته لمثلها. تسهيل الحصول على Service Worker مع Workbox يعتبر Workbox مجموعة من المكتبات والأدوات المستخدمة لإنشاء Service Worker والتخزين المؤقت وغيرها وتسهيل ذلك. مراجع Instant Loading Web Apps With A Service Worker Application Shell Architecture Service Workers: an Introduction Using Web Workers Cache Fetch API IndexedDB API Client.postMessage() Application Shell Architecture workbox What Are Service Workers and How They Help Improve Performance

إنّ التخزين المؤقّت Caching للمحتوى بشكل ذكي هو واحد من أكثر الطرق فعاليّة لتحسين التجربة لزوّار أي موقع. إنّ التخزين المؤقّت Caching، أو تخزين المحتوى بشكل مؤقّت من الطلبات السّابقة، هو جزء من لُب استراتيجيّة توصيل المحتوى المُنفَّذة ضمن ميفاق HTTP protocol، تستطيع المُكوِّنات عبر مسار توصيل المحتوى أن تقوم بالتخزين المؤقّت للعناصر لتسريع الطلبات اللاحقة، والتي تكون خاضعة لسياسات التخزين المؤقّت المُصرَّح عنها بالنسبة للمحتوى. سنناقش في هذا الدّرس بعض المفاهيم الأساسيّة للتخزين المؤقّت لمحتوى الويب، وسنتحدّث عن الفوائد التي يتيح لنا التخزين المؤقّت الحصول عليها والأماكن التي يتم فيها هذا التخزين. ما هو التخزين المؤقت Caching؟التخزين المؤقّت Caching هو مصطلح يُعبِّر عن تخزين الاستجابات القابلة لإعادة استخدامها لجعل الطلبات اللاحقة تتم بشكل أسرع، تُوجد العديد من الأنواع المختلفة المُتاحة للتخزين المؤقّت، وكل منها له خصائصه الفريدة، فالتخزين المؤقّت للتطبيقات والتخزين المؤقّت للذاكرة شائعان لقدرتهما على تسريع بعض الاستجابات. إنّ التخزين المؤقّت للويب Web Caching -وهو محور درسنا هذا- هو نوع مختلف من التخزين المؤقّت، وهو ميزة التصميم الأساسيّة في ميفاق HTTP protocol والتي تهدف لتصغير حركة مرور البيانات عبر الشبكة network traffic مع تحسين الاستجابة التي يتلقّاها النظام ككل، تُوجد التخزينات المؤقّتة Caches في كل مستوى من مستويات رحلتنا مع المحتوى، ابتداءً من الخادوم الأصلي وحتى المتصفّح. يعمل التخزين المؤقّت للويب عن طريق التخزين المؤقّت لاستجابات HTTP للطلبات وفق قواعد معيّنة، ويتم بعدها تلبية الطلبات اللاحقة للمحتوى المُخزّن بشكل مؤقّت من التخزين المؤقّت القريب من المستخدم بدلًا من إعادة إرسال الطلبات إلى خادوم الويب. الفوائديُساعد التخزين المؤقّت الفعّال مستهلكي المحتوى ومزوّدي المحتوى، ومن الفوائد التي يقدّمها لتوصيل المحتوى نجد: تقليل تكاليف الشبكة: يُمكن التخزين المؤقّت للمحتوى في عدّة نقاط على مسار الشبكة بين مُستهلِك المحتوى ومصدر المحتوى، وعندما يتم تخزين المحتوى بشكل مؤقّت في مكان أقرب للمستهلك فلن تُحدِث الطلبات نشاطًا إضافيًّا للشبكة ما وراء نقطة التخزين المؤقّت.تحسين الاستجابة: يُمكِّننا التخزين المؤقّت من استرجاع المحتوى بشكل أسرع لأنّه ليس من الضروري القيام بدورة كاملة عبر الشبكة من أجل استرجاعه، يستطيع التخزين المؤقّت القريب من المستخدم، مثل التخزين المؤقّت للمتصفّح browser cache، أن يجعل هذا الاسترجاع للمحتوى لحظيًّا.تحسين الأداء على نفس العتاد: بالنسبة للخادوم الذي هو منشأ المحتوى فبإمكاننا الحصول على المزيد من الأداء من نفس العتاد عن طريق السماح بالتخزين المؤقّت العنيف aggressive caching، فيتمكّن مالك المحتوى من الاستفادة من الخواديم القويّة على مسار التوصيل لتتحمّل شدّة بعض تحميلات المحتوى.توافر المحتوى أثناء انقطاعات الشبكة: يُمكِن استخدام التخزين المؤقّت ضمن سياسات مُحدّدة لتخديم المحتوى للمستخدمين النهائيين عندما لا يكون هذا المحتوى متوفّرًا لفترة قصيرة من الوقت من الخواديم الأصل.مصطلحاتقد نصادف عند التعامل مع التخزين المؤقّت بعض المصطلحات غير المألوفة، ومن أشيعها ما يلي: الخادوم الأصل Origin server: إنّ الخادوم الأصل هو المكان الأصلي للمحتوى، فإن كنت تلعب دور مُدير خادوم الويب فهو الجهاز الذي تتحكّم به، وهو مسؤول عن تخديم أي محتوى لم نتمكّن من استرجاعه من التخزين المؤقّت على طول مسار الطلب، وإعداد سياسة التخزين المؤقّت لكافّة المحتويات.نسبة استخدام التخزين المؤقّت Cache hit ratio: تُقاس فعاليّة التخزين المؤقّت وفق نسبة استخدام التخزين المؤقّت cache hit ratio أو معدل الاستخدام hit rate، وهي نسبة الطلبات التي يُمكن استرجاعها من التخزين المؤقّت على العدد الكلّي للطلبات، وعندما تكون مرتفعة تدل على أنّنا استطعنا استرجاع نسبة عالية من الطلبات من التخزين المؤقّت، وهو عادةً النتيجة المرجوّة لمعظم مُديري النُظُم.الحداثة Freshness: وهو مصطلح يُستخدم ليصف إذا ما كان العنصر في التخزين المؤقّت لا يزال يُعد مُرشَّحًا لتخديمه إلى العميل، يُستخدَم المحتوى الموجود في التخزين المؤقّت كاستجابة فقط إذا كان ضمن الإطار الزمني للحداثة freshness المُحدَّد من قبل سياسة التخزين المؤقّت.المحتوى القديم Stale content: تنتهي صلاحيّة العناصر الموجودة في التخزين المؤقّت وفق إعدادات freshness المُحدَّدة من قبل سياسته الخاصة، يُوصف المحتوى مُنتهي الصلاحيّة بأنّه قديم "stale"، وبشكل عام لا يُمكن استخدام هذا المحتوى للإجابة على طلبات العملاء، ويجب هنا إعادة الاتصال مع الخادوم الأصل لاسترجاع المحتوى الجديد أو للتحقّق على الأقل من أنّ المحتوى المُخزَّن مؤقّتًا لا يزال دقيقًا.التحقّق Validation: يُمكِن التحقّق من العناصر الموجودة في التخزين المؤقّت من أجل تحديث مُدّة صلاحيتها، ويتضمّن هذا التواصل مع الخادوم الأصل لنعرف إذا ما كان المحتوى المُخزَّن مؤقّتًا لا يزال يُمثِّل أحدث إصدار من هذه العناصر.الإبطال Invalidation: الإبطال هو عمليّة إزالة المحتوى من التخزين المؤقّت قبل الوقت المُحدّد لانتهاء صلاحيّته، وهو ضروري إن تمّ تغيير المحتوى على الخادوم الأصل، فامتلاك محتوى قديم في التخزين المؤقّت سيسبب مشاكل هامّة للعميل.يُوجد المزيد من مصطلحات التخزين المؤقّت، ولكن ينبغي أن تُساعدك المصطلحات السّابقة في البدء. ما هو المحتوى الذي يمكن تخزينه بشكل مؤقت؟يجعل بعض المحتوى من نفسه أكثر سهولة للتخزين المؤقّت من محتوى آخر، فمن المحتوى القابل بشدّة للتخزين المؤقّت لمعظم المواقع نجد: صور الشعارات والعلامات التجاريّةالصور غير المتناوبة Non-rotating images (مثل أيقونات التصفّح navigation)ملفّات التنسيق Style sheetsملفّات Javascript العامّةالمحتوى القابل للتنزيلملفّات الوسائط Media Filesتميل هذه المحتويات إلى عدم تغيّرها بشكل متكرّر، لذا نستفيد من تخزينها بشكل مؤقّت لفترات طويلة. ومن بعض العناصر التي يجب أن نحذر عند تخزينها بشكل مؤقّت نجد: صفحات HTMLالصور المتناوبة Rotating imagesملفّات CSS و Javascript المُعدَّلة بشكل متكرّرالمحتوى الذي يتم طلبه من خلال كعكات الاستيثاق authentication cookiesومن العناصر التي لا ينبغي إطلاقًا تخزينها بشكل مؤقّت تقريبًا: البيانات الحسّاسة (معلومات البنك، إلخ ..)المحتوى المرتبط بالمستخدم والمتغيّر بشكل متكرّروبالإضافة للقواعد العامّة السّابقة من الممكن تحديد سياسات تسمح لنا بالتخزين المؤقّت لأنواع مختلفة من المحتوى بشكل مناسب، على سبيل المثال إن كانت تظهر نفس شاشة العرض من موقعنا للمستخدمين الذين قاموا بالاستيثاق فمن الممكن التخزين المؤقّت لها في أي مكان، وإن كانت تظهر شاشة تعرض معلومات حسّاسة عن المستخدم في موقعنا فمن الممكن أن تكون صالحة للتخزين المؤقّت لبعض الوقت، وربّما نخبر متصفّح المستخدم أن يقوم بالتخزين المؤقّت ولكن من دون إخبار أي أماكن وسيطة أخرى للتخزين المؤقّت أن تقوم بتخزين شاشة العرض هذه. أماكن التخزين المؤقت لمحتوى الويبيُمكِن التخزين المؤقّت للمحتوى في العديد من النقاط المختلفة على طول سلسلة التوصيل: التخزين المؤقّت للمتصفّح Browser cache: تحتفظ متصفّحات الإنترنت لنفسها بمكان صغير للتخزين المؤقّت، يقوم المتصفّح نموذجيًّا بتعيين سياسة تنص على أهم العناصر التي يجب تخزينها مؤقّتًا، والتي قد تكون محتوى خاص بالمستخدم أو محتوى يُعتبَر من المُكلِف تنزيله ومن المرجّح أن يُطلَب مرّة أخرى.وسطاء التخزين المؤقّت البيني Intermediary caching proxies: يستطيع أي خادوم بين العميل وبنيتنا التحتيّة أن يقوم بالتخزين المؤقّت كما يرغب، يتم الحفاظ على هذه التخزينات المؤقّتة من قبل مزوّدات خدمة الإنترنت ISPs أو أطراف مستقلّة أخرى.التخزين المؤقّت العكسي Reverse Cache: بإمكان البنية التحتيّة لخادومنا تنفيذ التخزين المؤقّت الخاص بها لخدمات المنتهى الخلفي backend services، وبهذه الطريقة يُمكِن تخديم المحتوى من نقطة الاتصال بدلًا من الوصول لخواديم المنتهى الخلفي backend عند كل طلب.تقوم هذه المواقع عادةً بعمل تخزين مؤقّت للعناصر وفق سياسات التخزين المؤقّت لديها والسياسات المُحدَّدة على الخادوم الأصل. الخاتمةتحدّثنا في هذا الدّرس عن مفهوم التخزين المؤقّت وشرحنا بعض المصطلحات الأساسيّة فيه، وشاهدنا الفوائد التي نحصل عليها من استخدامه، والأماكن التي يتم فيها هذا التخزين. تكلمنا أيضًا عن أنواع المحتوى التي يُمكِن تخزينها بشكل مؤقّت والأنواع التي لا يجب إطلاقًا تخزينها. ترجمة -وبتصرّف- لـ Web Caching Basics: Terminology, HTTP Headers, and Caching Strategies لصاحبه Justin Ellingwood. حقوق الصورة البارزة: Designed by Freepik.

إنّ التخزين المؤقّت Caching للمحتوى بشكل ذكي هو واحد من أكثر الطرق فعاليّة لتحسين التجربة لزوّار موقعنا، إنّ التخزين المؤقّت Caching، أو تخزين المحتوى بشكل مؤقّت من الطلبات السّابقة، هو جزء من لُب استراتيجيّة توصيل المحتوى المُنفَّذة ضمن ميفاق HTTP protocol، تستطيع المُكوِّنات عبر مسار توصيل المحتوى أن تقوم بالتخزين المؤقّت للعناصر لتسريع الطلبات اللاحقة، والتي تكون خاضعة لسياسات التخزين المؤقّت المُصرَّح عنها بالنسبة للمحتوى. سنناقش في هذا الدّرس كيفيّة اختيار سياسات التخزين المؤقّت لنضمن أن يتمكّن التخزين المؤقّت في جميع أنحاء شبكة الإنترنت من معالجة محتوانا بشكل صحيح، وسنتحدّث عن استخدام ترويسات التخزين المؤقّت، وتوظيف الاستراتيجيات المختلفة للحصول على أفضل مزيج من الأداء والمرونة. ترويسات التخزين المؤقت Caching Headersتعتمد سياسة التخزين المؤقّت على عاملين مختلفين، كيان التخزين المؤقّت والذي يُقرِّر بنفسه أن يقوم بالتخزين المؤقّت للمحتوى المقبول أم لا، فيستطيع أن يُقرِّر أن يُخزِّن بشكل مؤقّت أقل مما هو مسموح له ولا أكثر من ذلك. يتم تحديد مُعظم سلوك التخزين المؤقّت عن طريق سياسة التخزين المؤقّت، والتي تُوضَع من قبل مالك المحتوى. تتمحور هذه السياسات بشكل أساسي حول استخدام ترويسات HTTP مُحدّدة. ومع تحديثات ميفاق HTTP protocol ظهرت بعض الترويسات المختلفة التي تُركِّز على التخزين المؤقّت مع مستويات مختلفة من التعقيد، ولكنّ الترويسات التالية هي التي لا نزال بحاجة إلى الانتباه لها: Expires: إنّ الترويسة Expires واضحة جدًّا، على الرغم من أنّها محدودة المجال، فتقوم بشكل أساسي بتعيين وقت في المستقبل تنتهي فيه صلاحيّة المحتوى، وعند هذه النقطة يجب على أي طلب لهذا المحتوى أن يعود إلى الخادوم الأصل، تُستخدَم هذه الترويسة أفضل ما يُمكن كاحتياط فقط.Cache-Control: وهي البديل الأكثر حداثة للترويسة Expires ومدعومة بشكل جيّد وتقوم بتطبيق تصميم أكثر مرونة، وهي مُفضّلة تقريبًا في كل الحالات على Expires، ولكن لن يضرّنا تعيين قيمة لهما معًا، سنناقش تفاصيل الخيارات التي بإمكاننا تعيينها مع Cache-Control لاحقًا.Etag: تُستخدَم الترويسة Etag في التحقّق من التخزين المؤقّت، حيث يُزوّدنا الخادوم الأصل بترويسة Etag فريدة لأجل العناصر حينما يقوم بتخديم المحتوى في البداية، فعندما يُريد التخزين المؤقّت التحقق من المحتوى الذي يملكه عند انتهاء الصلاحيّة يستطيع إرسال الترويسة Etag التي يملكها من أجل المحتوى إلى الخادوم الأصل والذي إمّا أن يُخبر التخزين المؤقّت بأنّه يملك نفس المحتوى أو يقوم بإرسال المحتوى الجديد (مع ترويسة Etag جديدة).Last-Modified: تُحدِّد هذه الترويسة المرّة الأخيرة التي تمّ فيها تعديل العنصر، ويُمكن استخدامها كجزء من استراتيجيّة التحقّق لضمان محتوى حديث.Content-Length: بالرغم من أنّها لا تُشارِك تحديدًا في التخزين المؤقّت فإنّه من الهام تعيين قيمة لهذه الترويسة عند تعريف سياسات التخزين المؤقّت، حيث ترفض بعض البرمجيّات التخزين المؤقّت للمحتوى إن لم تكن تعلم مُسبقًا حجم هذا المحتوى الذي تحتاج لحجز مساحة له.Vary: يستخدم التخزين المؤقّت بشكل نموذجي المُضيف host المطلوب والمسار إلى الموارد كمفتاح يُخزَّن بواسطته العنصر المطلوب، يُمكِن استخدام الترويسة Vary لنخبر التخزين المؤقّت أن ينتبه إلى ترويسة إضافيّة عندما يُقرّر إذا ما كان الطلب لنفس هذا العنصر، وهي أكثر ما تستخدم لإخبار التخزين الاحتياطي أن تستخدم الترويسة Accept-Encoding كمفتاح أيضًا، بحيث يعلم التخزين المؤقّت كيف يُفرِّق بين المحتوى المضغوط compressed وغير المضغوط.نظرة جانبية على الترويسة Varyتزوّدنا الترويسة Vary بالقدرة على تخزين إصدارات مختلفة من نفس المحتوى على حساب تمييع diluting المُدخلات في التخزين المؤقّت. ففي حالة Accept-Encoding يسمح لنا إعداد الترويسة Vary بالتمييز بشكل قاطع بين المحتوى المضغوط وغير المضغوط، حيث نحتاج لهذا لتخديم هذه العناصر بشكل صحيح للمتصفّحات التي لا تستطيع التعامل مع المحتوى المضغوط، وهو ضروري من أجل توفير سهولة الاستخدام الأساسيّة، ومن إحدى السمات التي تُخبرنا بأنّ الترويسة Accept-Encoding قد تكون مُرشّحًا جيّدًا من أجل الترويسة Vary هي أنّها تمتلك فقط قيمتان أو ثلاث قيم ممكنة. يبدو عنصر مثل User-Agent للوهلة الأولى طريقة جيّدة للتمييز بين متصفّحات الحواسيب ومتصفّحات الهواتف النقّالة لتخديم إصدارات مختلفة لموقعنا، ومع ذلك وبما أنّ السلاسل النصيّة لـ User-Agent ليست معياريّة فستكون النتيجة غالبًا عدّة إصدارات من نفس المحتوى في التخزينات المؤقّتة الوسيطة مع نسبة استخدام تخزين مؤقّت Cache hit ratio ضئيلة، ينبغي استخدام الترويسة Vary باعتدال، خاصّة إن لم نكن نملك القدرة على تقليل تكرار الطلبات في التخزينات المؤقّتة الوسيطة التي نتحكّم بها (والذي قد يكون ممكنًا إن استفدنا من شبكة توصيل محتوى content delivery network على سبيل المثال). كيف تؤثر أعلام الترويسة Cache-Control على التخزين المؤقتأشرنا سابقًا إلى كيفيّة استخدام الترويسة Cache-Control من أجل مواصفات سياسة التخزين المؤقّت الحديثة، يُمكن تعيين عدد من التعليمات المختلفة لهذه السياسة باستخدام هذه الترويسة، مع فصل التعليمات المتعدّدة بواسطة الفواصل. ومن بعض خيارات Cache-Control التي نستطيع استخدامها للنص على سياسة التخزين المؤقّت للمحتوى لدينا نجد: no-cache: تُحدِّد هذه التعليمة أنّه يجب التحقّق من أي محتوى مُخزَّن مؤقّتًا عند كل طلب قبل تخديمه إلى العميل، وتقوم فعليًّا بتحديد المحتوى بأنّه قديم stale فورًا، ولكن تتيح له استخدام تقنيات إعادة التحقّق لتجنّب إعادة تنزيل كامل العنصر مرّة أخرى.no-store: تشير هذه التعليمة إلى أنّه لا يُمكن التخزين المؤقّت للمحتوى بأي طريقة، وهي ملائمة لتعيينها إن كانت الاستجابة تمثّل بيانات حسّاسة.public: تقوم بتحديد المحتوى بأنّه عام ممّا يعني أنّه يمكن التخزين المؤقّت له من قبل المتصفّح أو من قبل أي تخزينات مؤقّتة وسيطة، يتم تحديد الاستجابات بالنسبة للطلبات التي تستخدم استيثاق HTTP بأنّها خاصّة private افتراضيًّا، وتستطيع هذه الترويسة تجاوز ذلك الإعداد.private: تقوم بتحديد المحتوى بأنّه خاص private، والذي يُمكن تخزينه من قبل متصفّح المستخدم ويُمنَع تخزينه بشكل مؤقّت من قبل أي أطراف وسيطة، تستخدم هذه التعليمة غالبًا للبيانات الخاصّة بالمستخدم.max-age: يضبط هذا الإعداد الفترة العظمى التي يُمكن خلالها تخزين المحتوى بشكل مؤقّت قبل أن تجب إعادة التحقّق منه أو إعادة تحميله من الخادوم الأصل، وهو يستبدل الترويسة Expires من أجل المتصفّحات الحديثة وهو الأساس لتحديد حداثة جزء من المحتوى، تُحدَّد قيمة هذا الخيار بالثواني ووقت الحداثة الأعظمي المقبول هو سنة واحدة (31536000 ثانية).s-maxage: وهو مشابه كثيرًا للإعداد max-age بأنّه يشير للفترة الزمنيّة التي يُمكِن خلالها التخزين المؤقّت للمحتوى، ويكمن الفرق في أنّ هذا الخيار يُطبَّق فقط على التخزينات المؤقّتة الوسيطة، يسمح جمعه مع الخيار السابق ببناء سياسة أكثر مرونة.must-revalidate: يُشير هذا الخيار إلى أنّه يجب إطاعة معلومات الحداثة المنصوص عليها من خلال max-age، s-maxage، أو الترويسة Expires بشكل صارم، فلا يُمكِن تخديم المحتوى القديم تحت أي ظروف، ويمنع هذا استخدام المحتوى المُخزَّن مؤقّتًا في حالة انقطاعات الشبكة والسيناريوهات المشابهة لها.proxy-revalidate: يقوم هذا الإعداد بنفس ما يقوم به الإعداد السابق ولكن ينطبق فقط على وسطاء التخزين المؤقّت البيني intermediary proxies، ويبقى متصفّح المستخدم في هذه الحالة قادرًا على تخديم المحتوى القديم في حالة انقطاعات الشبكة، ولكن لا يُمكن استخدام التخزينات المؤقّتة الوسيطة لهذا الغرض.no-transform: يمنع هذا الخيار التخزينات المؤقّتة من تعديل المحتوى الذي تلقّته لأسباب تتعلّق بالأداء تحت أي ظروف، يعني هذا على سبيل المثال أنّ التخزين المؤقّت غير قادر على إرسال إصدارات مضغوطة من محتوى لم يتلقّاه بشكل مضغوط وغير مسموح له بهذا أصلًا.نستطيع الجمع بين كل ما سبق بطرق مختلفة للحصول على سلوك متعدّد للتخزين المؤقّت، بعض القيم التبادليّة هي: no-cache ،no-store، وسلوك التخزين المؤقّت الطبيعي الذي نشير إليه بغياب أحدهماpublic و privateيحل الخيار no-store محل no-cache إن كان كلاهما موجودًا، ومن أجل الاستجابة على الطلبات التي لا تتعلق بالاستيثاق يتم تطبيق الخيار public، ومن أجل الاستجابة على الطلبات التي تحتوي استيثاق يتم تطبيق الخيار private، ويُمكِن تجاوزها بتضمين الخيار المعاكس في الترويسة Cache-Control. تطوير سياسة تخزين مؤقتيُمكِن في العالم المثالي التخزين المؤقّت لكل شيء بقوّة والتواصل مع الخواديم فقط للتحقّق من المحتوى بين حين وآخر، ولكن على الرغم من ذلك لا يحدث هذا في الممارسة العمليّة، لذا ينبغي أن نحاول تعيين سياسات تخزين مؤقّت عاقلة تطمح إلى الموازنة بين تنفيذ تخزين مؤقّت طويل المدى والاستجابة لاحتياجات الموقع المتغيّر. مشاكل شائعةهنالك العديد من الحالات التي لا يُمكِن أو لا ينبغي فيها تنفيذ التخزين المؤقّت نظرًا لكيفيّة إنتاج هذا المحتوى (توليده بشكل مُتغيّر بحسب المستخدم) أو طبيعة هذا المحتوى (معلومات بنكيّة حساسة على سبيل المثال)، ومن المشاكل الأخرى التي تُواجِه العديد من مديري النّظم عند إعداد التخزين المؤقّت هي الحالة التي تكون فيها إصدارات أقدم ومنتشرة من محتوانا ليست قديمة بعد على الرغم من نشر إصدارات أجدد منها. تتم مصادفة هاتين المشكلتين بشكل متكرّر وتمتلكان أثرًا هامًّا على أداء التخزين المؤقّت ودقّة المحتوى الذي نقوم بتخديمه، ومع ذلك نستطيع الحد من هذه المشاكل عن طريق تطوير سياسات تخزين مؤقّت تتوقّع هذه المشاكل. توصيات عامةعلى الرغم من أنّ الحالة هي التي تُملي علينا استراتيجيّة التخزين المؤقّت المُلائِمة، تستطيع التوصيات التالية إرشادنا نحو بعض القرارات المنطقيّة. هناك بعض الخطوات التي نستطيع اتخاذها لزيادة نسبة استخدام التخزين المؤقّت Cache hit ratio قبل الانتقال لاستخدام ترويسات محدّدة، ومن بعض الأفكار نجد: إنشاء أدلّة directories مُخصّصة للصور، ملفات css، والمحتوى المُشترَك: يسمح وضع المحتوى في أدلّة مُخصّصة بالرجوع بسهولة إليها من أي صفحة على موقعنا.استخدام نفس الرابط URL للإشارة إلى نفس العناصر: بما أنّ التخزينات المؤقّتة تستخدم مفتاح مُكوَّن من المُضيف والمسار للمحتوى المطلوب فيجب أن نتأكّد من أن نشير إلى محتوانا بنفس الطريقة على كافّة صفحات موقعنا، وتجعل النصيحة السابقة من هذا أسهل.استخدام الأشكال الشبحية sprites لصور CSS حيثما أمكن ذلك: تُقلِّل الأشكال الشبحية لصور CSS من أجل عناصر مثل الأيقونات والتصفّح navigation من عدد الجولات المطلوبة لتصيير render موقعنا وتسمح لنا بالتخزين المؤقّت لذلك الشكل الشبحي لوقت طويل.استضافة الـ scripts والموارد الخارجيّة بشكل محلّي بقدر الإمكان: إن كُنّا نستخدم scripts خاصة بلغة javascript وموارد خارجيّة أخرى فيجب أن نأخذ بعين الاعتبار استضافة هذه الموارد على خواديمنا الخاصّة، نلاحظ أنّه يجب علينا الانتباه لأي تحديثات جديدة لهذه الموارد لكي نقوم بتحديث نسختنا المحليّة منها.وضع بصمة خاصّة لعناصر التخزين المؤقّت: من المناسب أن نقوم بوضع بصمة خاصّة بالنسبة للمحتوى الثابت مثل ملفّات CSS وJavascript، ويعني هذا إضافة مُعرِّف فريد unique identifier إلى اسم الملف (عادةً تلبيد hash للملف) بحيث إن تمّ تعديل المورد يُمكِن طلب الاسم الجديد للمورد مما يجعل الطلبات تجتاز التخزين المؤقّت بشكل صحيح، توجد العديد من الأدوات التي تساعد في إنشاء بصمات وتعديل المراجع إليها في ملفّات HTML.ومن ناحية اختيار الترويسات الصحيحة للعناصر المختلفة، فيمكن اعتبار ما يلي كمرجع عام: السماح لكافّة التخزينات المؤقتة بتخزين الممتلكات العامّة general assets: ينبغي أن يتم التخزين المؤقّت للمحتوى الثابت وغير المتعلّق بالمستخدم في كافّة النقاط على سلسلة التوصيل، ممّا يسمح للتخزينات المؤقّتة الوسيطة بالاستجابة بالمحتوى للعديد من المستخدمين.السماح للمتصفّحات بالتخزين المؤقّت للممتلكات الخاصّة بالمستخدم: من المقبول والمفيد بالنسبة للمحتوى الخاص بالمستخدم أن نسمح بالتخزين المؤقّت داخل متصفّح المستخدم، وبينما يكون من غير الملائم فعل هذا على التخزينات المؤقّتة الوسيطة يسمح التخزين المؤقّت في المتصفّح بالاستعادة الآنيّة للمحتوى من أجل المستخدمين خلال الزيارات اللاحقة.عمل استثناءات للمحتوى الأساسي الحساس بالنسبة للوقت: إن كنّا نملك محتوى حساس بالنسبة للوقت نقوم بعمل استثناء للقواعد السابقة بحيث لا يتم تخديم المحتوى القديم في الحالات الحرجة، على سبيل المثال إن كان موقعنا يمتلك عربة تسوّق shopping cart فينبغي أن تعكس العناصر الموجودة فيها فورًا، واعتمادًا على طبيعة المحتوى يُمكِن تعيين الخيار no-cache أو no-store في الترويسة Cache-Control لتحقيق هذا.توفير خيارات للتحقّق دومًا: تسمح لنا خيارات التحقّق بتحديث المحتوى القديم بدون أن يتوجّب علينا تنزيل كامل الموارد مرّة أخرى، يسمح تعيين الترويسات Etag وLast-Modified للتخزينات المؤقّتة بأن تتحقّق من محتواها وتعيد تخديمه إن لم يتم تعديله على الخادوم الأصل، مما يؤدي إلى إنقاص الحمل load.تعيين أوقات حداثة freshness times طويلة للمحتوى الداعم: من أجل الاستفادة من التخزين المؤقّت بشكل فعّال فإنّ العناصر المطلوبة كمحتوى داعم لملء الطلب ينبغي عادة أن تملك وقت حداثة طويل، وهو مناسب بشكل عام من أجل لعناصر مثل الصور وملفّات CSS والتي يتم سحبها لتصيير صفحة HTML المطلوبة من قبل المستخدم، يسمح تعيين وقت حداثة طويل مع جمعه بوضع بصمة بأن تقوم التخزينات المؤقّتة بتخزين هذه الموارد لفترات طويلة، فإن تمّ تغيير الممتلكات فستقوم البصمة المُعدّلة بإبطال العنصر المُخزَّن مؤقّتًا وستقوم بتحفيز تنزيل المحتوى الجديد، وحتى ذلك الحين يُمكِن أن يتم تخزين العناصر الداعمة بشكل مؤقّت لوقت طويل في المستقبل.تعيين أوقات حداثة freshness times قصيرة للمحتوى الأب: يجب أن يملك عنصر الاحتواء وقت حداثة قصير نسبيًّا أو حتى لا يتم تخزينه بشكل مؤقّت نهائيًّا وذلك من أجل تطبيق المخطّط السّابق، وهو بشكل نموذجي صفحة HTML التي تستدعي العناصر المساعدة الأخرى، فيتم تنزيل ملفّات HTML بشكل متكرّر ممّا يسمح لها بالاستجابة للتغيرات بسرعة، ومن ثمّ بعدها يُمكِن التخزين المؤقّت للمحتوى الداعم بشدّة.المفتاح الأساسي لتحقيق هذا هو خلق موازنة تُفضِّل التخزين المؤقّت بشدّة حيثما أمكن مع ترك فُرَص لإبطال المُدخلات مُستقبلًا عندما يتم حدوث تغييرات، من المرجّح أن يملك موقعنا تركيبة من: عناصر مُخزَّنة مؤقّتًا بشدّةعناصر مُخزّنة مؤقّتًا مع وقت حداثة قصير والقدرة على إعادة التحقّقعناصر لا ينبغي تخزينها بشكل مؤقّت إطلاقًاوالهدف هو نقل المحتوى إلى الفئة الأولى إن أمكن مع الحفاظ على مستوى مقبول من الدقة. الخاتمةإنّ أخذ الوقت للتأكّد من أنّ موقعنا يملك سياسات تخزين مؤقّت مناسبة في مكانها له تأثير هام عليه، حيث يسمح التخزين المؤقّت بالتقليل من نفقات عرض النطاق bandwidth المترافقة مع تخديم نفس المحتوى بشكل متكرّر، سيكون خادومنا أيضًا قادر على التعامل مع كميّة كبيرة من حركة مرور البيانات traffic باستخدام نفس العتاد، وربّما الأهم من كل ذلك أنّ العملاء سيملكون تجربة أسرع على موقعنا ممّا يقود بهم إلى العودة إليه بشكل متكرّر، وفي حين أنّ التخزين المؤقّت بشكل فعّال ليس حلًّا سحريًّا فإنّ إعداد سياسات تخزين مؤقّت مناسبة يعطينا مكاسب ملموسة بجهد قليل. ترجمة -وبتصرّف- لـ Web Caching Basics: Terminology, HTTP Headers, and Caching Strategies لصاحبه Justin Ellingwood.