أشعر أن استخدام ETags سيكون له تأثير إيجابي كبير على أداء تحميل الصفحات، حيث إن معظم صفحات HTML غير مخزنة مؤقتًا. وهذا سيتجنب حاجة الخادم لتقديم الصفحة إذا كان العميل قد قام بتنزيلها بالفعل.
هل تم التفكير في هذا الأمر من قبل؟
قد أكون مخطئًا، لكن Discourse يعتمد بالفعل بشكل كبير على JavaScript من جانب العميل، لذا فإن ما يقوم العميل بتحميله هو بيانات ضئيلة. يتم تحميل كل شيء تقريبًا في الزيارة الأولى، ثم يتم تخزينه مؤقتًا. لا أعرف حقًا إلى أي حد قد تحسّن وسوم الكيانات (ETags) عملية التخزين المؤقت هذه.
على سبيل المثال، حجم التحميل الأول لصفحتي هو حوالي 800 كيلوبايت، بينما التحميل الثاني هو حوالي 40 كيلوبايت.
إعجابَين (2)
تم تصميم Discourse وإعداده بشكل جيد بالفعل للذاكرة المؤقتة.
تحتوي معظم أصول الموقع (JS، CSS) على عناوين URL فريدة يتم إنشاؤها في كل مرة تقوم فيها بتحديث الموقع باستخدام تجزئة للأصل، مما يسمح لها بفترات تخزين مؤقت طويلة.
أعتقد أن تحميلات الموقع (الصور، الصور الرمزية، إلخ) تستخدم أيضًا عناوين URL فريدة.
معظم الصفحات الكاملة التي يمكنك رؤيتها ديناميكية ولا ينبغي تخزينها مؤقتًا بشكل مفرط. قد يكون من الممكن، على ما أظن، استخدام نوع من التخزين المؤقت باستخدام ETag يتحقق في كل تحميل للصفحة مما إذا كانت هناك مشاركات جديدة أو معدلة. لست متأكدًا من سبب قرار الفريق بعدم القيام بذلك.
3 إعجابات
كان يجب أن أوضح: الأصول مخزنة بالفعل بشكل جيد — ما أتحدث عنه هو مستند HTML (الطلب الأول).
معظم الصفحات الكاملة التي يمكنك رؤيتها ديناميكية ولا ينبغي تخزينها مؤقتًا بشكل مفرط. ربما يكون من الممكن، على ما أظن، استخدام نوع من التخزين المؤقت القائم على ETag يتحقق في كل تحميل للصفحة مما إذا كانت هناك مشاركات جديدة أو معدّلة. لست متأكدًا من سبب قرار الفريق بعدم القيام بذلك.
نعم، هذا هو بالضبط ما أتحدث عنه، لكنني لا أعتقد أن رموز ETag تُنشأ يدويًا بهذه الطريقة — يمكن أن تعتمد على ملف HTML الخام الذي يُقدَّم، ويمكنها إخبار العميل: “انظر، هذا هو تمامًا ما رأيته من قبل، فقط استخدمه”.
المسألة هي أنه، حسب فهمي، يحدث هذا بالفعل مع جافا سكريبت على جانب العميل. لذا، لا يوجد تنقل لـ HTML ذهابًا وإيابًا.
إعجاب واحد (1)
يحمّل HTML بيانات JSON من الخادم، ويمكن أن تستخدم طلبات JSON هذه وسوم الكيان (ETags). ومع ذلك، لا يتم ذلك حاليًا، رغم أنني لست متأكدًا من حجة الفريق وراء ذلك.
إعجاب واحد (1)
الطلب الأول إلى الصفحة يحتوي بالتأكيد على محتوى تم تصييره قبل تحميل JSON من الخادم عبر XHR، وهو ما أنت محق في أنه يحدث أيضًا.
يمكنك التحقق من ذلك بالنظر إلى طلب الشبكة من نوع “Document” في أداة تصحيح أخطاء Chrome، ويجب أن يحتوي (على الأقل في حالتي) على الفئات التي تم تصييرها بالفعل.
إليك مثال على ما تم تصييره من طلب المستند:
طلبك غير منطقي لأن Discourse هو تطبيق JavaScript لا يسترجع HTML، حيث يتم بناء جميع “الصفحات” عبر كود JavaScript قابل للتنفيذ في الوقت الفعلي.
إعجاب واحد (1)
طلبك غير منطقي لأن Discourse هو تطبيق JavaScript لا يسترجع HTML.
أحترم تمامًا خبرتك وخبرتك هنا، لكنني قمت بتشغيل عشرات تطبيقات الويب التي يتم عرضها بواسطة JavaScript وتستخدم ETags في الاستجابة الجذرية (إذا كان المحتوى قابلاً لإعادة الاستخدام).
جميع “الصفحات” يتم بناؤها عبر كود JavaScript قابل للتنفيذ في الوقت الفعلي.
لقطة الشاشة التي شاركتها أعلاه هي HTML الذي يتم إرجاعه قبل تشغيل أي كود على جانب العميل، لذا فهناك بالتأكيد شيء ما في الخلفية (أفترض أنه Rails) يخدم هذا المسار.
كل مجتمع Discourse راجعته (باستثناء هذا المجتمع) يعيد في البداية نسخة من الموقع خالية من JavaScript مع جميع المحتويات المعروضة، على ما يبدو من أجل الزوار.
أعتذر إذا كنت مخطئًا تمامًا، لكنني لا أعتقد أنني “غير منطقي”، ربما أنا فقط مخطئ.
إعجاب واحد (1)
فقط لوكلاء مستخدمين من نوع الروبوتات، لذا فإن هذه الملاحظة ليست مفيدة.
فقط لوكلاء مستخدمين من نوع الزوار
هذا ليس ما أراه عند تشغيل الأمر التالي:
curl -H "User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36" https://community.midi.city/
هذا ليس وكيل مستخدم من نوع الزوار، ومع ذلك فإنه يُرجع الحمولة المذكورة أعلاه.
بغض النظر، أعتقد أن الإجابة على طلبي للحصول على ETag هي “لا”، لذا شكرًا لك على ملاحظاتك، وربما يتم إعادة النظر في الأمر في وقت ما.
صحيح، الإجابة هي «لا» حازمة وقاطعة في كل من الجانبين الفلسفي والتقني.
(الأصول مسألة مختلفة، لكن استخدام أسماء ملفات فريدة مع معرف فريد عالميًا (GUID) هو نهج متفوق إلى حد كبير، لذا فإن وسوم الكيان (ETags) أصبحت نوعًا ما قديمة بشكل عام.)
حتى بالنسبة لواجهة برمجة التطبيقات (API)؟ يمكنني أن أفهم أنه بالنسبة للطلبات الأصغر، قد لا يستحق الأمر، لكن مشاهدات الموضوعات قد تصل إلى 20 كيلوبايت، مما سيؤدي إلى تراكم كبير. ولكن بعد ذلك، لا يراقب الكثير من الأشخاص الموضوعات بشكل متكرر ما لم تكن هناك منشورات جديدة..
هذه هي النقطة. بالنسبة للمشاهدات المتكررة لنفس المحتوى تمامًا، إذا كنت غير متصل، فإننا نقوم بالفعل بعرض كل المحتوى من ذاكرة التخزين المؤقت للمتصفح دون الحاجة إلى الاتصال بالخادم.
ترقية هذا النظام ليتم التحميل حتى عندما تكون متصلًا يتطلب إبطال ذاكرة التخزين المؤقت، وبالتالي فمن الطبيعي أن يكون الأمر صعبًا.
إعجابَين (2)
أوه، جيد سماع أن هذا يعمل. كنت لأظن أن رأسية cache-control: no-cache, no-store تعني أن استجابات واجهة برمجة التطبيقات لن تدخل مطلقًا إلى ذاكرة التخزين المؤقت للمتصفح.
لا، ليس الأمر كذلك. حسنًا، الأمر معقد. هناك عدة ذاكرات تخزين (Caches) تعمل في الخلفية 
لا يتم تخزينه في ذاكرة التخزين المؤقت التقليدية للمتصفح التي يعرفها الجميع ويحبها. ولكن هناك Cache واجهة برمجة تطبيقات الويب متاحة للمتصفحات عبر JavaScript، وتُستخدم لتخزين الاستجابات بهدف توفير التنقل دون اتصال بالإنترنت للمحتوى الذي تم قراءته سابقًا.
5 إعجابات