ماهو No-Vary-Search في عالم الـcaching؟

كما هو متعارف عليه ان التعامل السليم في اي موقع الكتروني هو وجود caching للبيانات -بغض النظر عن النوعية او الاهمية لأنه ليس كل البيانات يصح ان تكون "مكيشة"- وتخزين هذا الكاش يكون مبني على تقسيمة الرابط المؤدي لهذه البيانات (الـ URL) وبنفس الوقت ليس منطقي ان يتم "تكييش" نفس البيانات كل مرة بسبب انك اضفت متغير معين للرابط قد يكون هدفه مجرد تتبع جهة قدوم المستخدم مثلا، وهنا يأتي دور No-Vary-Search حيث انها تخبر سيرفر الـCaching ان الرابط المطلوب منك من قبل المستخدم لا تقوم بانشاء نسخة له اذا تغيرت بعض القيم فيه (القيم المحددة بشكل مسبق من قبلك كمطور).

تتكون الروابط (URLs) من عدة أجزاء، من أهمها المسار (Path) -يكون بهذا الشكل /dashboard/article/- ومتغيرات الاستعلام (Query Parameters) -تكون بهذا الشكل dashboard/article?query1=123&query2=456-. يمثل الـPath وجهة الطلب، بينما تُستخدم Query Parameters لإرفاق بيانات إضافية بالرابط، قد تُستخدم لتحديد المحتوى المطلوب أو لتوفير معلومات إضافية مثل مصدر الزيارة وطريقة الوصول إلى الصفحة. لكن ليست جميع هذه الـQuery Parameters مؤثرة في المحتوى الذي يعيده الخادم، وهنا تظهر أهمية No-Vary-Search، إذ تسمح بتحديد المتغيرات التي يمكن تجاهل اختلافها عند مطابقة الاستجابات المخزنة في الـ Cache لنسخة سابقة موجودة اصلا.

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

تكمن اهمية No-Vary-Search في انها تساعدك على الاستفادة من الـCaching بشكل افضل، فبدل ما يتعامل المتصفح مع كل رابط يحتوي على Query مختلفة باعتباره طلبا مستقلا، يمكنك تحديد الـQuery التي لا تؤثر على محتوى الاستجابة وتجاهل اختلافها عند البحث عن نسخة مخزنة. وهذا يعني تقليل عمليات الجلب المتكررة والاستفادة من البيانات المخزنة مسبقا، وبالتالي تقليل الطلبات التي تصل إلى السيرفر وتخفيف الضغط على موارده. وقد يكون هذا التأثير محدودا في المشاريع الصغيرة، لكنه يصبح اكثر وضوحا في المشاريع التي تتعامل مع عدد كبير من الزيارات والطلبات، خصوصا عندما تتكرر الروابط مع اختلاف معاملات التتبع فقط.

اعتقد غالباً انك شفت Query اسمها `utm_source`، وهي تستخدم لمعرفة مصدر الزيارات للموقع، مثلاً هل جاء المستخدم من LinkedIn أو Telegram أو غيرها. لكن هل من المنطقي ان نتعامل مع كل رابط على انه مورد مختلف لمجرد ان قيمة `utm_source` تغيرت؟ بمعنى ان المستخدم الأول دخل من LinkedIn والثاني دخل من Telegram، بينما الاثنين يطلبون نفس الصفحة ونفس المحتوى! هنا تظهر فائدة No-Vary-Search، فهي تسمح لنا بتحديد الـ Query Parameters التي لا نريد ان يؤثر اختلافها على مطابقة الـ Cache. وفي الكود التالي رح نشوف كيف نستخدمها بشكل عملي، وبإمكانك تجربتها بنفسك حتى تفهم الفكرة بشكل أوضح، لأن قراءة الكود وحدها لا تكفي دائماً لفهم طريقة عملها.

اول شيء كود السيرفر ورح يكون باستخدام Nextjs وطبعا انت غير مقيد بتقنية معينة وبامكانك تجرب باستخدام اي تقنية تسمحلك بانشاء سيرفر تجريبي

let requestCount = 0;

export async function GET() {
  requestCount++;

  return Response.json(
    {
      requestCount,
      generatedAt: new Date().toISOString(),
    },
    {
      headers: {
        "Cache-Control": "public, max-age=3600",
        "No-Vary-Search": 'params=("utm_source")',
      },
    }
  );
}

جرب تستدعي الرابطين وشوف كيف ان قيمة requestCount ما رح تتغير بعد استدعاء اول واحد منهما

GET /api/test?utm_source=linkedin
GET /api/test?utm_source=telegram

بينما لو استدعيت بعدهم الرابط التالي رح تصبح قيمة requestCount بـ 2 وهذا يعيني انه تجاهل تغير utm_source بعد ما تكيشت في اول مرة بينما لم يتجاهل بقية الـQuery Parameters مهما تغيرت وتكيشت

GET /api/test?utm_source=telegram&t=1
GET /api/test?utm_source=telegram&t=2

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

Harry Roberts MDN Web Docs